cookies - name - exploit csrf

¿Por qué la política del mismo origen no es suficiente para evitar los ataques de CSRF?

Question

En primer lugar, supongo que un back-end que controla las entradas para evitar vulnerabilidades XSS.

En esta respuesta, @Les Hazlewood explica cómo proteger el JWT en el lado del cliente.

Asumiendo 100% de TLS para todas las comunicaciones, tanto durante como en todo momento después del inicio de sesión, la autenticación con nombre de usuario / contraseña a través de la autenticación básica y la recepción de un JWT a cambio es un caso de uso válido. Esto es casi exactamente cómo funciona uno de los flujos de OAuth 2 (''contraseña de concesión''). [...]

Usted acaba de configurar el encabezado de Autorización:

Authorization: Bearer <JWT value here>

Pero, dicho esto, si su cliente REST no es de confianza (por ejemplo, un navegador habilitado para JavaScript), ni siquiera haría eso: cualquier valor en la respuesta HTTP al que se pueda acceder mediante JavaScript, básicamente cualquier valor de encabezado o cuerpo de respuesta - podría ser olido e interceptado a través de ataques MITM XSS.

Es mejor almacenar el valor JWT en una cookie única y segura solo para HTTP (configuración de cookie: setSecure (true), setHttpOnly (true)). Esto garantiza que el navegador:

1. solo transmita la cookie a través de una conexión TLS y,
2. nunca haga que el valor de la cookie esté disponible para el código JavaScript.

Este enfoque es casi todo lo que necesita hacer para la seguridad de las mejores prácticas. Lo último es asegurarse de tener protección CSRF en cada solicitud HTTP para garantizar que los dominios externos que inician solicitudes en su sitio no puedan funcionar.

La forma más sencilla de hacerlo es establecer una cookie segura (pero no solo http) con un valor aleatorio, por ejemplo, un UUID.

No entiendo por qué necesitamos la cookie con el valor aleatorio para garantizar que los dominios externos que inician solicitudes a su sitio no puedan funcionar. Esto no es gratis con la misma política de origen?

De OWASP :

Comprobando el encabezado de origen

El estándar de encabezado HTTP de origen se introdujo como un método de defensa contra CSRF y otros ataques entre dominios. A diferencia del referer, el origen estará presente en la solicitud HTTP que se origina a partir de una url HTTPS.

Si el encabezado de origen está presente, entonces se debe verificar la coherencia.

Sé que la recomendación general de OWASP en sí es el Patrón del Token del Sincronizador, pero no puedo ver cuáles son las vulnerabilidades que quedan en:

• TLS + JWT en una cookie httpOnly segura + Política del mismo origen + Sin vulnerabilidades XSS.

ACTUALIZACIÓN 1: la política del mismo origen solo se aplica a XMLHTTPRequest , por lo que un sitio malvado puede hacer una solicitud POST de formulario fácilmente y esto romperá mi seguridad. Se necesita una verificación de encabezado de origen explícito. La ecuación sería:

• TLS + JWT en cookies seguras httpOnly + comprobación de encabezado de origen + vulnerabilidades XSS.

Answer 1

¿Por qué la política del mismo origen no es suficiente para evitar los ataques de CSRF?

Porque la Política de origen idéntico solo se aplica a la lectura de datos y no a la escritura.

Desea evitar que http://compromised.com realice una solicitud como esta (desde el navegador del usuario):

POST http://example.com/transfer-funds
fromAccountId:1
toAccountId:666

Una solicitud legítima se vería así:

POST https://example.com/transfer-funds
fromAccountId: 1
toAccountId: 666
csrfToken: 249f3c20-649b-44de-9866-4ed72170d985

Para ello, exige un valor (el token CSRF) que no se puede leer desde un sitio externo, es decir, en un encabezado de entrada o respuesta de formulario HTML.

Con respecto al encabezado Origen, los navegadores antiguos no lo admiten y Flash tiene algunas vulnerabilidades que permiten que el cliente lo modifique. Básicamente, confiarías en Adobe para no arruinar nada en el futuro.

asegúrese de tener protección CSRF en cada solicitud HTTP

Solo necesita protección CSRF en solicitudes con efectos secundarios, como cambio de estado o envío de un mensaje.

Answer 2

Resumen

Tenía un concepto incomprendido sobre la política de Same Same y CORS que @Bergi, @Neil McGuigan y @SilverlightFox me ayudaron a aclarar.

Antes que nada, lo que @Bergi dice sobre

SOP no impide el envío de solicitudes. Evita que una página acceda a los resultados de solicitudes entre dominios.

es un concepto importante Pensé que un navegador no realiza la solicitud al dominio cruzado de acuerdo con la restricción de SOP, pero esto solo es cierto para lo que Monsur Hossain llama "solicitudes no tan simples" en this excelente tutorial.

Las solicitudes de origen cruzado vienen en dos formas:

• solicitudes simples
• "solicitudes no tan simples" (un término que acabo de inventar)

Las solicitudes simples son solicitudes que cumplen los siguientes criterios:

• El método HTTP coincide (distingue entre mayúsculas y minúsculas) con uno de los siguientes:
  • CABEZA
  • OBTENER
  • ENVIAR
• Encabezados HTTP coincidencias (no distingue entre mayúsculas y minúsculas):
  • Aceptar
  • Aceptar Idioma
  • Contenido-Lenguaje
  • ID del último evento
  • Content-Type, pero solo si el valor es uno de:
    • application / x-www-form-urlencoded
    • multipart / form-data
    • Texto sin formato

Entonces, un POST con tipo de contenido application / x-www-form-urlencoded llegará al servidor (esto significa una vulnerabilidad CSRF) pero el navegador no hará accesibles los resultados de esa solicitud. Un POST con tipo de contenido application / json es una "solicitud no tan simple", por lo que el navegador realizará una solicitud de preligth como esta

OPCIONES / punto final HTTP / 1.1
Host: https://server.com
Conexión: keep-alive
Access-Control-Request-Method: POST
Origen: https://evilsite.com
Access-Control-Request-Headers: tipo de contenido
Aceptar: * / *
Aceptar-Codificación: gzip, desinflar, sdch
Accept-Language: es-ES, es; q = 0.8

Si el servidor responde con, por ejemplo:

Access-Control-Allow-Origin: http://trustedsite.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: tipo de contenido
Content-Type: text / html; charset = utf-8

el navegador no hará la solicitud en absoluto, porque

XMLHttpRequest no puede cargar http://server.com/endpoint . La respuesta a la solicitud de verificación previa no pasa la comprobación de control de acceso: el encabezado ''Access-Control-Allow-Origin'' contiene el valor no válido ''trustedsite.com''. El origen ''evilsite.com'' no está, por lo tanto, permitido.

Entonces creo que Neil estaba hablando de esto cuando señaló que:

La política de mismo origen solo se aplica a la lectura de datos y no a la escritura.

Sin embargo, con el control explícito del encabezado de origen que propuse a Bergi, creo que es suficiente con respecto a este tema.

Con respecto a mi respuesta a Neil, no quise decir que esa fue la respuesta a mi pregunta, pero me recordó otro tema importante sobre el SOP y fue que la política solo se aplica a XMLHTTPRequest.

En conclusión, creo que la ecuación

• TLS + JWT en cookies seguras httpOnly + comprobación de encabezado de origen + vulnerabilidades XSS.

es una buena alternativa si la API está en otro dominio como dice SilverlightFox. Si el cliente está en el mismo dominio que el cliente, tendré problemas con las solicitudes que no incluyen el encabezado de origen. Nuevamente desde el this :

La presencia del encabezado Origen no significa necesariamente que la solicitud sea una solicitud de origen cruzado. Si bien todas las solicitudes de origen cruzado contendrán un encabezado de origen, algunas solicitudes de origen idéntico también pueden tener una. Por ejemplo, Firefox no incluye un encabezado de origen en las solicitudes de origen idéntico. Pero Chrome y Safari incluyen un encabezado de origen en las solicitudes POST / PUT / DELETE de origen idéntico (las solicitudes GET de origen idéntico no tendrán un encabezado Origin).

Silverlight señaló this .

El único riesgo que queda es que un cliente puede falsificar el encabezado de origen para que coincida con el origen permitido, por lo que la respuesta que estaba buscando era en realidad this

ACTUALIZACIÓN: para aquellos que miran esta publicación, tengo doubts sobre si el encabezado de origen es necesario usando JWT.

La ecuación sería:

• TLS + JWT almacenado en cookie segura + JWT en encabezado de solicitud + sin vulnerabilidades XSS.

Además, la ecuación anterior tiene una cookie httpOnly, pero esto no funcionará si tiene el cliente y el servidor en diferentes dominios (como muchas aplicaciones de SPA actuales) porque la cookie no se enviará con cada solicitud al servidor. Por lo tanto, necesita acceder al token JWT almacenado en la cookie y enviarlo en un encabezado.

Answer 3

Solo quiero resumir las respuestas.

1. Como otros SOP mencionados se aplican solo a XmlHttpRequests. Esto significa que los navegadores de especificación deben enviar el encabezado ORIGIN junto con las solicitudes que se hicieron mediante XmlHttpRequests.
2. Si comprueba que Chromium envía el origin al enviar el formulario también. Sin embargo, esto no significa que otros navegadores lo hagan. La imagen a continuación ilustra dos solicitudes de publicaciones realizadas en Firefox. Una se hace submitting un formulario y una segunda usando XHR . Ambas solicitudes se realizaron desde http://hack:3002/changePassword a http://bank:3001/chanePassword .
3. El navegador no puede enviar el encabezado de origin si la solicitud se realizó desde el mismo dominio. Entonces, el servidor debe verificar la política de origen solo cuando se establece el encabezado de origen.

La conclusión es: si utiliza cookies y una solicitud llega al servidor sin encabezado de origin , no puede diferenciar si se realizó mediante el envío de un formulario de otro dominio o por XHR dentro del mismo dominio. Es por eso que necesita verificación adicional con CSRF.