Es el Double Submit Cookies mecanismo vulnerable a cualquier cosa que no sea XSS y subdominio ataques ?
Todos los mecanismos de protección CSRF son vulnerables a XSS, por lo que no es nada nuevo. Me pregunto si puedo confiar en este mecanismo de forma segura siempre y cuando me asegure de controlar todos los subdominios.
NOTA: esta pregunta es una consecuencia de ¿Cómo protegerse contra el inicio de sesión CSRF?
Según un documento publicado en Blackhat 2013, no es suficiente para que usted implemente Double-Submit Cookies en su propio subdominio (por ejemplo, secure.host.com ). Realmente debes controlar todos subdominios:
2.1.1 Doble presentación ingenua
Las mitigaciones de CSRF de la cookie de envío doble son comunes y las implementaciones pueden variar mucho. La solucion es Es tentador porque es escalable y fácil de implementar. Una de las variaciones más comunes es la ingenua:
if (cookievalue != postvalue)
throw CSRFCheckError
Con un doble envío ingenuo, si un atacante puede escribir una cookie, obviamente puede anular la protección. Y de nuevo, escribir cookies es mucho más fácil que leerlas.
El hecho de que se puedan escribir cookies es difícil de entender para muchas personas. Después de todo, no es lo mismo ¿La política de origen especifica que un dominio no puede acceder a las cookies de otro dominio? Sin embargo, hay dos escenarios comunes donde es posible escribir cookies en dominios:
1) Si bien es cierto que hellokitty.marketing.example.com no puede leer las cookies ni acceder a DOM desde secure.example.com debido a la misma política de origen, hellokitty.marketing.example.com puede escribir cookies en el dominio principal (example.com), y estas cookies son consumidas por secure.example.com (secure.example.com no tiene una buena manera de distinguir qué sitio configuró la cookie).
Además, existen métodos para forzar a secure.example.com a que siempre acepte su cookie primero. Lo que esto significa es que XSS en hellokitty.marketing.example.com puede sobrescribir las cookies en secure.example.com.
En segundo lugar, este enfoque es vulnerable a los ataques de intermediarios:
2) Si un atacante está en el medio, generalmente pueden forzar una solicitud al mismo dominio a través de HTTP. Si una aplicación está alojada en enlace , incluso si las cookies están configuradas con la marca de seguridad, un hombre en el medio puede forzar las conexiones a enlace y configura (sobrescribe) cualquier cookie arbitraria (aunque la marca de seguridad impide que el atacante lea esas cookies).
Incluso si el encabezado HSTS está configurado en el servidor y el navegador que visita el sitio es compatible con HSTS (esto evitaría que un hombre en el medio fuerce las solicitudes HTTP de texto plano) a menos que el encabezado HSTS esté configurado de manera que incluya todos los subdominios, un hombre en el medio simplemente puede forzar una solicitud a un subdominio separado y sobrescribir las cookies similares a 1. En otras palabras, siempre que enlace no fuerza a https, entonces un atacante puede sobrescribir las cookies en cualquier subdominio example.com.
En resumen:
Secure para garantizar que las cookies solo se envíen a través de HTTPS. Vea enlace para una discusión de la longitud del token y el tipo de RNG necesario para generar valores.
Aunque todos los ataques XSS superan a las protecciones CSRF, requieren un esfuerzo diferente del atacante. Una protección simple como un token es fácil de obtener para un atacante a través de un ataque XSS, ya que simplemente pueden leer el valor del token desde el DOM y usarlo en cualquier envío posterior. Una forma confidencial que requiere una contraseña o una reautenticación de OTP es más difícil de atacar, ya que tendrían que diseñar su ataque para capturar las credenciales del usuario o OTP de alguna manera. Sin embargo, con el control total del DOM, podrían imitar la página de inicio de sesión para engañar al usuario y hacerle creer que se desconectó y esperar a que el usuario ingrese sus credenciales ... en este caso, probablemente podrían iniciar sesión directamente como víctima. En lugar de solo ejecutar un ataque CSRF. Este ataque también causa interrupciones visibles en el sitio, lo que significa que un usuario experto puede sospechar que algo está mal y se niega a iniciar sesión en el formulario del atacante.
Con los subdominios hay dos riesgos con las cookies de doble envío. Un atacante en un subdominio que lee el valor de la cookie. p.ej. si una cookie cookie solo para el host se establece en el nivel example.com , un atacante que controle foo.example.com podrá leer El valor de la cookie. La configuración de cookies solo de host puede contrarrestar este ataque.
El otro riesgo en un atacante es escribir cookies. La Same Origin Policy es más laxa para las cookies que para el resto del DOM. Esto significa que un atacante que controla foo.example.com puede configurar una cookie que se leerá cuando la víctima visite example.com o bar.example.com . Simplemente configuran un no host solo en el nivel example.com . Incluso si el sitio está bajo ataque, digamos que bar.example.com establece cookies de solo host a través de HTTPS, y establece el marca segura para evitar que se filtre a través de HTTP simple, un atacante que configure una cookie HTTP simple podrá configurar la cookie para que se lea para bar.example.com . El motivo es que el servidor no puede indicar el dominio real que lo configuró, ni puede consultar el indicador de seguridad en sí mismo.
Las cookies de doble envío también son vulnerables a un atacante de Man-In-The-Middle que puede interceptar y cambiar todo aparte de Tráfico HTTPS . Incluso si el sitio de destino, example.com no escucha a través de http sin formato (es decir, el puerto 443 solo abre para TLS), el atacante podría redirigir cualquier solicitud de http con HTTP 3xx (por ejemplo, a http://example.com ) y luego intercepte esa solicitud, envíe una respuesta con el conjunto de cookies CSRF envenenado para example.com . El servidor tomará ese valor, ya que de nuevo no tiene forma de determinar que no es una cookie con el indicador de seguridad. Esto se debe nuevamente a la laxa política de origen de las cookies.
La solución a todo esto es implementar HTTP Strict Transport Security y controlar todos los subdominios. En los navegadores compatibles, esto evitará que el navegador realice cualquier conexión http simple durante el tiempo de vida del registro HSTS (quizás años), y protegerá las cookies de un atacante. Las entradas de HSTS también pueden enviarse a proveedores de navegadores para que se incluyan en la compilación, lo que significa que los usuarios no tienen que visitar el sitio al menos una vez para establecer el registro de HSTS. Consulte Precarga de HSTS .
Lea otras preguntas en las etiquetas cookies csrf sub-domain