Te sugerimos que pruebes esta respuesta en un ambiente controlado antes de pasarlo a producción, saludos.
Solución:
Según un artículo publicado en Blackhat 2013, no es suficiente que implemente cookies de doble envío en su propio subdominio (p. Ej. secure.host.com). Realmente debes controlar todos subdominios:
2.1.1 Doble presentación ingenua
Las mitigaciones de CSRF de cookies de doble envío son comunes y las implementaciones pueden variar mucho. La solución es tentadora porque es escalable y fácil de implementar. Una de las variaciones más comunes es la ingenua:
if (cookievalue != postvalue)
throw CSRFCheckError
Con doble envío ingenuo, si un atacante puede escribir una cookie, obviamente puede anular la protección. Y nuevamente, escribir cookies es significativamente más fácil que leerlas.
El hecho de que las cookies se puedan escribir es difícil de entender para muchas personas. Después de todo, ¿no especifica la misma política de origen que un dominio no puede acceder a las cookies de otro dominio? Sin embargo, existen dos escenarios comunes en los que es posible escribir cookies en todos los dominios:
1) Mientras es true que hellokitty.marketing.example.com no puede leer cookies o acceder al 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 estos las cookies son luego consumidas por secure.example.com (secure.example.com no tiene una buena forma de distinguir qué sitio colocó la cookie).
Además, existen métodos para forzar a secure.example.com a que siempre acepte primero su cookie. 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 man-in-the-middle:
2) Si un atacante está en el medio, generalmente puede forzar una solicitud al mismo dominio a través de HTTP. Si una aplicación está alojada en https://secure.example.com, incluso si las cookies están configuradas con la bandera segura, un hombre en el medio puede forzar conexiones a http://secure.example.com y configurar (sobrescribir) cualquier cookie arbitraria (aunque la bandera de seguridad evita 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 intermediario forzará solicitudes HTTP de texto plano) a menos que el encabezado HSTS esté configurado de una manera que incluya todos los subdominios, un hombre en el medio puede simplemente forzar una solicitud a un subdominio separado y sobrescribir las cookies similares a 1. En otras palabras, siempre que http://hellokitty.marketing.example.com no fuerce https, un atacante puede sobrescribir las cookies en cualquier subdominio example.com.
En resumen:
- Debe controlar todos los subdominios.
- Debes configurar el
Securepara garantizar que las cookies solo se envíen a través de HTTPS. - Si le preocupan los ataques MiTM, debe realizar la transición de todo su sitio web a HTTPS, configurar el encabezado HSTS y asegurarse de que incluya todos los subdominios. En este momento, solo el 58% de los navegadores son compatibles con HSTS (Internet Explorer es una excepción notable). Se espera que esto cambie durante el próximo año.
Consulte https://security.stackexchange.com/a/61041/5002 para obtener una discusión sobre la longitud del token y el tipo de RNG necesarios para generar valores.
Aunque todos los ataques XSS superan las protecciones CSRF, estos requieren un esfuerzo diferente por parte 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 puede leer el valor del token del DOM y usarlo en cualquier formulario posterior enviado. Un formulario confidencial que requiere la reautenticación de la contraseña o la OTP es más complicado de atacar, ya que necesitarían diseñar su ataque para capturar las credenciales del usuario o la 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 haciéndole creer que se ha cerrado la sesión y esperar a que el usuario ingrese sus credenciales … en este caso, probablemente podrían iniciar sesión directamente como la víctima. en lugar de solo ejecutar un ataque CSRF. Este ataque también causa una interrupción visible en el sitio, lo que significa que un usuario experto puede sospechar que algo está mal y negarse a iniciar sesión en el formulario del atacante.
Con los subdominios existen dos riesgos con las cookies de doble envío. Un atacante en un subdominio que lee el valor de la cookie. por ejemplo, si una cookie que no es solo de host está configurada en example.com nivel, un atacante controlando 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 de que un atacante escriba cookies. La Política de Mismo Origen 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 establecen un no host solo en example.com nivel. Incluso si el sitio está siendo atacado, digamos bar.example.com establece cookies solo de host a través de HTTPS y establece la bandera de seguridad para evitar que se filtre a través de HTTP simple, un atacante que configure una cookie HTTP simple por sí mismo aún podrá configurar la cookie para que se lea bar.example.com. La razón es que el servidor no puede decirle al dominio real que lo configuró, ni tampoco puede consultar el indicador de seguridad en sí.
Las cookies de doble envío también son vulnerables a un atacante Man-In-The-Middle que puede interceptar y cambiar todo, excepto el tráfico HTTPS. Incluso si el sitio de destino, example.com no escucha a través de http simple (es decir, el puerto 443 solo está abierto para TLS), el atacante podría redirigir alguna solicitud http simple con HTTP 3xx (por ejemplo, para http://example.com) y luego interceptar esa solicitud, enviar una respuesta con la cookie CSRF envenenada configurada para example.com. El servidor tomará ese valor, ya que nuevamente no tiene forma de determinar que no es una cookie con la bandera segura. Esto se debe nuevamente a la política laxa del mismo origen para 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 conexiones http simples durante la vida útil del registro HSTS (tal vez años) y evitará que un atacante establezca las cookies. Las entradas HSTS también se pueden enviar a los proveedores de navegadores para su inclusión en la compilación, lo que significa que los usuarios no tienen que visitar el sitio al menos una vez para que se establezca el registro HSTS. Consulte Precarga de HSTS.
valoraciones y reseñas
Si sostienes alguna suspicacia y forma de aumentar nuestro escrito puedes dejar una crónica y con placer lo interpretaremos.