¿Contra qué ataques CSRF protegerán las cookies de "Sólo primera persona"?

Navega tus respuestas
4

El nuevo atributo de cookie "Solo para uso exclusivo" :

  

... permite a los servidores afirmar que una cookie debería estar      Enviado solo en un contexto de "primera parte". Esta afirmación permite al usuario      agentes para mitigar el riesgo de ataques de falsificación de solicitudes entre sitios ,      y otras rutas relacionadas con la fuga de información de origen cruzado.

Chrome planea implementar la función en Chrome # 50 .

La especificación define First-Party :

  

... como una solicitud HTTP para un recurso cuyo origen de URL coincide con el origen de la URL que el usuario ve en la barra de direcciones.

Indicar específicamente:

  

  • Las nuevas ventanas crean nuevos contextos de primera persona.

    •   

  • Las navegaciones de página completa crean nuevos contextos de primera persona. En particular, esto incluye tanto HTTP como <meta> -driven redirects.

    •   

  • <iframe> 's no crean nuevos contextos de primera persona; sus peticiones     DEBE ser considerado en el contexto del origen de la URL la     el usuario realmente ve en la barra de direcciones del agente de usuario.

    •   

Entonces, la función parece proteger contra el caso cuando CSRF se usa para enviar una solicitud POST a un <iframe> en la página del atacante. Pero ¿qué hay de los siguientes vectores CSRF:

  1. El CSRF es un enlace o un javascript navigation a una solicitud GET ? El usuario verá una navegación completa, supongo que no somos " t ayudó aquí.
  2. ¿El CSRF es un javascript enviado POST pero el objetivo del formulario provoca una navegación completa al sitio de la víctima? Es más probable que sea poco fiable ya que el POST proviene de otro lugar, pero sigue siendo un total navegación.

Estoy entusiasmado con esta nueva función de Cookie, pero ¿en qué medida protege exactamente contra los ataques CSRF?

    
pregunta George Powell 03.02.2016 - 15:08
fuente

3 respuestas

2

Además de su propia respuesta , Las defensas CSRF todavía se recomiendan y son útiles :

  

Las cookies "SameSite" ofrecen una defensa sólida contra el ataque CSRF cuando
  implementado en modo estricto, y cuando el cliente lo admite. Lo es,
  sin embargo, es prudente asegurarse de que esta designación no sea el alcance de   la defensa de un sitio contra CSRF, como navegación en el mismo sitio y
  Las presentaciones pueden ser ejecutadas en conjunto con otros usuarios.   Vectores de ataque como los scripts entre sitios.

     

Se recomienda encarecidamente a los desarrolladores que implementen el servidor habitual   de defensa (tokens CSRF, asegurando que los métodos HTTP "seguros" sean
  idempotente, etc.) para mitigar el riesgo de manera más completa.

     

Además, las técnicas del lado del cliente, como las descritas en
  [el aislamiento de la aplicación] también puede ser efectivo contra CSRF, y es posible   Sin duda vale la pena explorar en combinación con las cookies "SameSite".

Aunque no estoy de acuerdo con el vector de ataque XSS, ya que XSS siempre supera una vulnerabilidad CSRF: si un atacante puede inyectar HTML y secuencias de comandos, puede eludir la mayoría de las defensas (o todas las defensas con un poco de "ingeniería social" para engañar al usuario para ingresar contraseñas o CAPTCHAs cuando sea necesario).

    
respondido por el SilverlightFox 04.02.2016 - 13:01
fuente
2

Estos escenarios se tratan en Versión 6 de la especificación .

Define los modos Strict (predeterminado) y Lax , donde estricto no enviaría cookies incluso para las navegaciones de nivel superior, y Lax enviaría cookies para las navegaciones de nivel superior, pero < em> would para "métodos HTTP no seguros", incluido POST .

Las respuestas para los dos escenarios son por lo tanto:

  1. Las navegaciones JS y los clics de enlace se estarían protegidos con First-Party-Only cookies, a menos que se use el modo Lax .
  2. La forma POST s siempre estará protegida, ya que POST se considera inseguro.

Entonces, cuando esto se implementa en todos los navegadores, ¿están obsoletos los tokens CSRF?

Los

tokens CSRF siguen siendo útiles porque pueden garantizar que los puntos finales solo puedan ser llamados desde páginas específicas en su dominio. Donde como First-Party-Only las cookies solo pueden garantizar que proviene del mismo dominio. Esto significa que las vulnerabilidades de XSS en una página diferente a su punto final no pueden llegar a ese punto final.

    
respondido por el George Powell 04.02.2016 - 11:30
fuente
0

Después de leer sección 7.1 "Limitaciones" I supondría que el autor de la RFC es consciente de la limitación que describe. Las cookies de uso exclusivo no se consideran una protección integral contra CSRF.

Las cookies exclusivas solo están sangradas para proteger contra CSRF que son invisibles para el usuario final. Esto significa que no tiene la intención de proteger contra CSRF, lo que resultará en el cambio de la URL visible, como sucede cuando se sigue un enlace, se envía un formulario o se obtiene un redireccionamiento utilizando la etiqueta meta o una respuesta HTTP. Pero deben protegerse contra CSRF invisible que no cambia la URL visible y que se puede hacer con la etiqueta de imagen, desde un iframe o similar.

    
respondido por el Steffen Ullrich 03.02.2016 - 15:45
fuente

Lea otras preguntas en las etiquetas

¿Riesgos de prestar / pedir prestada una tarjeta SIM temporalmente? ¿Puedo evitar que todos los empleados accedan a los datos del cliente sin ser registrados (especialmente TI)?