Protección CSRF con encabezado CORS Origin frente a token CSRF

103

Esta pregunta solo trata sobre la protección contra ataques de falsificación de solicitudes entre sitios.

Se trata específicamente de: ¿Es la protección a través del encabezado de origen (CORS) tan buena como la protección a través de un token CSRF?

Ejemplo:

Alice inició sesión (usando una cookie) con su navegador en " https://example.com ". Supongo que usa un navegador moderno.
Alice visita " https://evil.com " y el código del lado del cliente de evil.com realiza algún tipo de solicitud a " https://example.com " (escenario clásico de CSRF).

Entonces:

Si no verificamos el encabezado de origen (del lado del servidor) y no hay un token CSRF, tenemos un agujero de seguridad CSRF.
Si revisamos un token CSRF, estamos a salvo (pero es un poco tedioso).
Si verificamos el encabezado Origin, la solicitud del código del lado del cliente de evil.com debería bloquearse tan bien como lo haría cuando se usa un token CSRF, excepto, si es posible de alguna manera que el código de evil.com configure el encabezado Origin.

Sé que esto no debería ser posible con XHR (ver, por ejemplo, Seguridad para compartir recursos de origen cruzado ), al menos no, si confiamos en que la especificación W3C se implementará correctamente en todos los navegadores modernos (¿podemos?)

Pero, ¿qué pasa con otros tipos de solicitudes, por ejemplo, envío de formularios? ¿Cargando una etiqueta script / img / ...? ¿O de cualquier otra forma que una página pueda utilizar para crear (legalmente) una solicitud? ¿O quizás algún truco de JS conocido?

Nota: no estoy hablando de

aplicaciones nativas,
navegadores manipulados,
errores de secuencias de comandos entre sitios en la página de example.com,
...

— Chris Lercher
fuente

Creo que muchos proxies eliminan el encabezado de origen.

— thefourtheye

Y para el envío de formularios y las etiquetas img / script, debemos confiar en los CSP, aunque no estamos seguros de los navegadores antiguos.

— thefourtheye

@thefourtheye: Dado que la conexión se inicia a través de TLS, el usuario tiene un problema mucho más urgente que CSRF si un proxy puede actuar como intermediario.

— Perseidas

@thefourtheye, ¿por qué se desnudarían Origin? Eso negaría la protección de CORS.

— Paul Draper

Me gusta esta pregunta y sus respuestas porque son sobre algo específico, pero también me recuerdan la diferencia entre CSRF y CORS. (Admito que esos conceptos no son fáciles de confundir ... pero todavía me las arreglo para confundirlos.)

— The Red Pea

Respuestas:

sabemos, que esto no debería ser posible con XHR (ver, por ejemplo, Seguridad para compartir recursos de origen cruzado), al menos no, si confiamos en que la especificación W3C se implementará correctamente en todos los navegadores modernos (¿podemos?)

Al final del día, debe "confiar" en el navegador del cliente para almacenar de forma segura los datos del usuario y proteger el lado del cliente de la sesión. Si no confía en el navegador del cliente, debe dejar de usar la web para cualquier otra cosa que no sea contenido estático. Incluso con el uso de tokens CSRF, está confiando en que el navegador del cliente obedecerá correctamente la Política del mismo origen .

Si bien ha habido vulnerabilidades de navegador anteriores, como las de IE 5.5 / 6.0, en las que los atacantes podían eludir la Política del mismo origen y ejecutar ataques, normalmente se puede esperar que se reparen tan pronto como se descubran y que la mayoría de los navegadores se actualicen automáticamente. , este riesgo se mitigará en su mayor parte.

Pero, ¿qué pasa con otros tipos de solicitudes, por ejemplo, envío de formularios? ¿Cargando una etiqueta script / img / ...? ¿O de cualquier otra forma que una página pueda utilizar para crear (legalmente) una solicitud? ¿O quizás algún truco de JS conocido?

La Origincabecera es normalmente sólo se envió para XHR solicitudes entre dominios. Las solicitudes de imágenes no contienen el encabezado.

Nota: no estoy hablando de

aplicaciones nativas,

navegadores manipulados,

errores de secuencias de comandos entre sitios en la página de example.com,

No estoy seguro de si esto cae dentro de los navegadores manipulados o no, pero las versiones antiguas de Flash permitían que se establecieran encabezados arbitrarios que permitirían a un atacante enviar una solicitud con un refererencabezado falso desde la máquina de la víctima para ejecutar un ataque.

— SilverlightFox
fuente

El ejemplo de Flash es bueno, y tal vez otros complementos pueden tener una vulnerabilidad similar. Solo puedo (desafortunadamente) proteger a Alice de CSRF, si usa un navegador moderno, etc., eso está claro. Pero no es descabellado que, incluso como usuario consciente de la seguridad, haya instalado complementos de terceros, especialmente cuando son de empresas grandes (confiables). A pesar de que pueden escribir complementos seguros, no estoy 100% convencido, ¡si también piensan en CSRF! Entonces, a menos que las cajas de arena del navegador impidan que los complementos violen los SOP (¿tal vez lo hagan?), Prefiero recomendar seguir con el token CSRF.

— Chris Lercher

@ChrisLercher: Sí, los complementos de hoy en día parecen ser un poco más robustos. Sin embargo, en cualquier momento podría lanzarse una nueva versión que permita a un atacante aprovecharla de tal manera que eluda las protecciones del navegador. La mejor manera de manejarlo (por ejemplo, token / encabezado) dependerá de la sensibilidad de sus datos y de si dicho riesgo es aceptable. Flash obedece a un SOP, pero el origen de un complemento Flash es el sitio desde el que se cargó (en lugar del sitio que llama como JavaScript). Hay una crossdomain.xmlque puede habilitar la comunicación entre dominios.

— SilverlightFox

El contenido web no puede alterar el encabezado de Origin. Además, bajo la misma política de origen, un origen ni siquiera puede enviar encabezados personalizados a otros orígenes. [1]

Por lo tanto, verificar el encabezado de Origin es tan bueno para bloquear ataques como usar un token CSRF.

La principal preocupación de confiar en esto es si permite que funcionen todas las solicitudes legítimas. El autor de la pregunta conoce este problema y ha configurado la pregunta para descartar los casos principales (sin navegadores antiguos, solo HTTPS).

Los proveedores de navegadores siguen estas reglas, pero ¿qué pasa con los complementos? Puede que no, pero la pregunta ignora los "navegadores manipulados". ¿Qué pasa con los errores en el navegador que permiten a un atacante falsificar el encabezado de Origin? Puede haber errores que permitan que el token CSRF también se filtre a través de los orígenes, por lo que sería necesario más trabajo argumentar que uno es mejor que el otro.

— invitado
fuente

Acabo de probar Firefox 47 y no envía un encabezado de origen para una publicación de formulario de origen cruzado (una forma común de atacar los servicios REST que no habilitan CORS para XHR), por lo que no creo que sea una verificación de encabezado de origen sería efectivo si el usuario usa Firefox.

— Andy

Como referencia, el problema de que Firefox no envíe un encabezado "Origen" se rastrea en Bugzilla: bugzilla.mozilla.org/show_bug.cgi?id=446344 Puede recurrir a verificar el encabezado "Referer" en este caso, pero en mi experiencia algunos Los usuarios de Firefox bloquean el encabezado "Referer" debido a problemas de privacidad (aunque en mi humilde opinión, sería suficiente para eliminar la ruta y la consulta).

— Steffen