¿Cómo evitar la fijación de sesión (CSRF de inicio de sesión) por el ataque MitM sin HSTS?

Navega tus respuestas
2

Estoy escribiendo una aplicación web que ya usa conexiones cifradas TLS (HTTPS), cookie de sesión Secure; HttpOnly , token CSRF HMAC-SHA1, requiere el encabezado Referer correcto para evitar el inicio de sesión CSRF y cambia la identificación de la sesión durante el inicio de sesión para evitar Ataques básicos de fijación de sesión.

Sin embargo, no puedo usar HSTS porque el mismo dominio debe servir contenido HTTP por razones históricas.

No logro comprender cómo evitar el ataque MitM que realiza la reparación de la sesión en la práctica:

  1. El atacante navega a https://example.com/login y recibe una nueva cookie anónima session-id y el HMAC-SHA1 csrf-token incorporado en el formulario de inicio de sesión.
  2. El atacante completa el inicio de sesión y el servidor sobrescribe la cookie session-id para la nueva identificación de usuario.
  3. El atacante guarda el valor de session-id cookie.
  4. La víctima navega a example.com usando HTTP y el atacante inicia un ataque MitM que modifica la respuesta para que tenga Set-Cookie: session-id=<value-from-attacker-session> y Location: https://example.com/whatever .
  5. El navegador de la víctima ahora completa el protocolo de enlace TLS completo con example.com y hace GET /whatever con Cookie: session-id=<value-from-attacker-session> . En la práctica, esto es una finalización del ataque de reparación de la sesión porque la víctima ahora está ejecutando la sesión compartida con el atacante.

Por supuesto, este no es un ataque fácil porque requiere un ataque MitM activo y la víctima necesita usar una conexión HTTP inicial para example.com . Además, esto solo permite la fijación de sesiones, no el secuestro de sesiones.

  1. ¿Es HSTS la única forma de evitar este ataque?
  2. ¿Hay alguna manera de evitar que las cookies configuradas a través de la conexión HTTP sean visibles en la conexión HTTPS y se vean idénticas a las cookies Secure; HttpOnly ?

Actualización 2014-09-04

Supongo que las siguientes afirmaciones son ciertas:

  1. La conexión TLS es segura y la UA tiene una lista sensata de CA confiables.
  2. El usuario final puede evitar sslstrip -como los ataques cuando el navegador Chrome contiene una URL incorrecta.
  3. example.com no está en la lista HSTS precargada.

La cookie de protección sugerida por Steffen Ullrich solucionaría el problema, excepto por el hecho de que no puede detectar si se realiza un ataque durante la conexión inicial. La implementación de la cookie de protección aún evitaría el ataque al cambiar la sesión sobre la marcha. Actualmente, MitM Attacker podría sobrescribir la cookie original Secure; HttpOnly llamada session-id con una cookie HTTP regular en cualquier momento en el futuro, puede obtener la UA para acceder a cualquier URL HTTP para el mismo dominio. (Esto puede ser bastante fácil porque el atacante puede redireccionar cualquier conexión HTTP desde la misma sesión del navegador).

Todavía no consigo ver ninguna manera de solucionar este problema sin la ayuda de UA. Si los UAs solo tuvieran una manera de saber qué cookies se han configurado a través de la conexión TLS en lugar del HTTP simple y sin formato ...

(Como parte, no tengo que decir que todos los sugerencias para detectar sslstrip -como ataques por parte del servidor como se describe en la respuesta vinculada por Steffern Ullrich porque todas las sugerencias requieren el envío de JavaScript los archivos que detectan y sslstrip se refieren estrictamente a un atacante MitM capaz de modificar archivos sobre la marcha. Como tal, el atacante puede hacer fácilmente cualquier detección de JavaScript para devolver siempre "ok".)

Enlaces relacionados:  1. Forzado de cookies  2. CSRF de inicio de sesión

    
pregunta Mikko Rantalainen 03.09.2014 - 10:36
fuente

2 respuestas

3
  

¿Cómo evitar la fijación de sesión (CSRF de inicio de sesión) por un ataque MitM sin HSTS?

No puedes. Debe tener su sitio en las listas de HSTS precargadas para evitar este tipo de ataque MITM, de lo contrario, el atacante podría MITM establecer la primera conexión y configurar las cookies de sesión para fijarlo a la sesión del atacante.

  

Sin embargo, no puedo usar HSTS porque el mismo dominio necesita servir algo de contenido HTTP por razones históricas. ... el contenido HTTP histórico contiene IFRAME incrustados de dominios que no admiten HTTPS

Esto no debería impedirle establecer una política de HSTS.

Por ejemplo, aloje su contenido histórico en legacy.example.net . Tenga en cuenta que este debe ser un dominio diferente de su contenido seguro ( www.example.com ), no un subdominio para enviarlo a Lista precargada de Chrome como el indicador includeSubDomains debe establecerse en el encabezado. Si su página histórica era http://www.example.com/iframe.htm , reemplace esto con un redireccionamiento a http://legacy.example.net/iframe.htm . Esto le permitirá servir el contenido HTTP histórico e incrustar un iFrame en un dominio HTTP sin advertencias de seguridad del navegador.

Por lo tanto, un usuario que navegue a algún contenido histórico con HSTS precargado obtendrá el siguiente proceso.

  1. El usuario ingresa la URL normal del contenido en la barra de dirección de su navegador: http://www.example.com/iframe.htm .
  2. El navegador comprueba su propia lista precargada de HSTS y encuentra www.example.com .
  3. El navegador actualiza la conexión a TLS cambiando la URL a https://www.example.com/iframe.htm
  4. El servidor recibe la solicitud y emite un redireccionamiento 301 a http://legacy.example.net/iframe.htm
  5. El servidor en legacy.example.net muestra IFrame que contiene contenido HTTP de terceros, y todos están contentos.

Esto le permitirá utilizar HSTS para su aplicación y, al mismo tiempo, permitir que el contenido histórico de alojamiento IFrame funcione sin problemas. Además, puede encontrar mi otra respuesta en proteger contra CSRF de inicio de sesión , ya que también cubre los ataques MITM.

    
respondido por el SilverlightFox 05.09.2014 - 12:18
fuente
2

Pregunta interesante. Lo que estás describiendo es un entorno, donde el atacante monta un ataque de hombre en el medio, donde puede leer y modificar el tráfico HTTP de los usuarios pero no el tráfico HTTPS. Esto excluye los ataques tipo SSLStrip y el administrador SSL de modo que puede ver aquí para obtener ideas sobre cómo detectar este tipo de ataques en el servidor.

En el entorno que describe, las siguientes suposiciones deberían ser válidas:

  • El atacante no puede leer la cookie de sesión original ni ninguna otra cookie que tenga activadas las banderas de Seguridad y HttpOnly. Además, ni siquiera puede ver qué cookies están en uso dentro de una conexión HTTPS.
  • Pero puede leer, modificar y crear cookies dentro de HTTP inseguro. Esto también permitirá que el atacante cree o modifique las cookies que tienen la marca de seguridad, incluso si no puede leerlas.

En base a esto, podría funcionar lo siguiente:

  • El servidor envía una cookie de sesión con un valor de identificación de sesión con indicadores seguros y de HTTP.
  • El servidor también envía una cookie de "guarda" con un nombre que se basa de alguna manera en el id de sesión y el valor "GuardCookie", también con la marca Segura y HttpOnly y con la misma duración que la cookie de sesión.
  • Cada vez que el servidor actualiza la cookie de sesión hace que la cookie de guarda refleje la nueva sesión, es decir, si el nombre de la cookie de guardia necesita ser cambiado, la cookie de guarda anterior debe ser invalidada y una nueva. O un nombre específico del usuario de la cookie de protección podría ser elegido al azar al iniciar sesión e incluido el hash dentro de la identificación de sesión.

El atacante puede anular la cookie de sesión por su propia cuenta y también puede agregar la cookie de protección desde su propia sesión. Pero, no puede eliminar la cookie de protección de la sesión de los usuarios porque no sabe su nombre. Por lo tanto, si el servidor recibe una solicitud del cliente a través de HTTPS, debe verificar:

  1. Se incluye un id de sesión válido. Si no, la sesión se reinicia.
  2. ¿Se incluye la cookie de guarda derivada del identificador de sesión? Si no, la sesión se reinicia.
  3. ¿Hay más cookies con el valor "GuardCookie"? Si es así, la sesión se restablece y todas las cookies de protección existentes se eliminan.

Con el último paso, el servidor puede detectar el ataque de reparación de la sesión, ya que el atacante no puede eliminar la cookie de protección de la sesión original.

No estoy completamente seguro de si esto funcionará, pero suena como un enfoque que vale la pena discutir :)

Editar: como notó el usuario SilverlightFox, el atacante aún puede arreglar a un usuario nuevo sin sesión previa a la sesión de atacantes. Esta idea solo ayuda a detectar el reemplazo de una sesión existente.

    
respondido por el Steffen Ullrich 03.09.2014 - 14:48
fuente

Lea otras preguntas en las etiquetas

¿Debería cada solicitud de publicación incluir el token csrf? Flujo de recuperación de contraseña: ¿Enviar la recuperación de contraseña a cualquier correo electrónico?