Con cookies anónimas

Si está feliz de generar tokens seguros que se configuran como cookies de usuarios anónimos, pero no para almacenarlos en el servidor, simplemente podría enviar cookies de forma doble .

por ejemplo Usuario legítimo:

1. Un usuario Anon navega a la página de inicio de sesión, recibe una cookie que se envía al navegador.
2. El usuario Anon inicia sesión y el navegador envía la cookie como un encabezado y como un valor de formulario oculto.
3. El usuario ya ha iniciado sesión.

El atacante no puede abusar de esto, ya que ahora sucederá lo siguiente:

1. El atacante crea una cuenta de host en el dominio de confianza
2. El atacante forja una solicitud de inicio de sesión en el navegador de la víctima con las credenciales de esta cuenta del host Sin embargo, el atacante no tiene acceso al valor de cookie de la víctima y no puede falsificarla como el token CSRF en el cuerpo de la solicitud. El ataque falla.

Incluso si solo se puede acceder a su sitio a través de HTTPS y usted establece correctamente el Secure Flag , se debe tener cuidado con este enfoque como atacante podría potencialmente MiTM cualquier conexión desde la víctima al cualquier sitio web HTTP (si el atacante está colocado adecuadamente, redirigirlos a su dominio a través de HTTP, que también es MiTM'd y luego establecer el valor de cookie requerido). Esto sería un ataque de Session Fixation . Para protegerse contra esto, puede enviar el valor de la cookie al encabezado y al campo de formulario oculto cada una vez que se carga esta página (inicio de sesión) (a través de HTTPS) en lugar de reutilizar cualquier valor de cookie ya establecido. Esto se debe a que, aunque un navegador puede configurar el indicador seguro, seguirá enviando cookies sin el indicador seguro a través de una conexión HTTPS, y el servidor no podrá saber si el indicador seguro fue configurado. (Los atributos de las cookies, como el indicador de seguridad, solo son visibles cuando la cookie está configurada, no cuando se lee. Lo único que el servidor puede ver es el nombre y el valor de la cookie). Implementando HSTS sería una buena opción para la protección en navegadores compatibles.

Es recomendable establecer X-Frame-Options para evitar un ataque de eliminación de clics en la IU (de lo contrario, el atacante podría utilizar la funcionalidad del sitio para completar previamente su nombre de usuario y contraseña en espera de que el usuario haga clic y los envíe junto con el valor CSRF).

Sin cookies anónimas

Si no desea configurar cookies para usuarios anónimos (que luego sospechan que están siendo rastreados por el servidor), se puede utilizar el siguiente método: un formulario de inicio de sesión de varias etapas.

La primera etapa es la combinación habitual de nombre de usuario / contraseña.

Después de enviar el formulario, se redirige a otro formulario. Este formulario está protegido por una cookie de token de autenticación intermediaria especial y un token CSRF. La autenticación aquí solo permitirá que se envíe la autenticación de la segunda etapa, pero no permitirá ninguna otra acción en la cuenta (excepto posiblemente un cierre de sesión completo). Esto permitirá que el token CSRF sea asociado y utilizado por esta cuenta de usuario solo en esta sesión intermedia.

Ahora, solo cuando se envía este formulario, incluida la cookie de token y el valor de formulario CSRF oculto, el usuario está completamente autenticado con el dominio. Cualquier atacante que intente un ataque CSRF no podrá recuperar el token CSRF y su intento de inicio de sesión completo fallará.

El único inconveniente es que el usuario tendrá que hacer clic manualmente para completar el inicio de sesión, lo que puede ser una experiencia de usuario torpe. Es recomendable configurar X-Frame-Options para evitar que esto ocurra se utiliza en combinación con un ataque de jacking de reparación de IU. Cualquier envío automático con JavaScript sería beneficioso para el atacante y podría hacer que su ataque tenga éxito, por lo que en este momento solo puedo ver un clic manual del usuario que trabaja.

Ahora se desarrollaría así:

1. El atacante crea una cuenta de host en el dominio de confianza
2. El atacante forja una solicitud de inicio de sesión en el navegador de la víctima con las credenciales de esta cuenta de host pero no puede pasar la etapa dos para autenticarse por completo
3. El atacante engaña a la víctima para que use el sitio de confianza, pero como no están completamente autenticados, el sitio actuará como si el usuario no estuviera autenticado

Por lo tanto, es un requisito de nicho, pero oye un CSRF válido. Hay un par de opciones sobre cómo puede abordar esto tan pronto como viene a la mente

• Técnicas estándar de anti-automatización como un CAPTCHA. Por supuesto, no es la solución más fácil de usar, pero puede ayudar a mitigar otros ataques al mismo tiempo.
• Tenga un token estándar Anti-CSRF que esté vinculado a la información proporcionada por el cliente que está disponible antes de la autenticación. Una opción obvia sería vincularlo a la dirección IP de origen. Eso no es perfecto (los sistemas detrás de proxies tendrían la misma dirección) pero reducirían el riesgo bastante. Otra opción sería vincular el token a identidades específicas del navegador. Si observa Panopticlick puede ver que los navegadores proporcionan información de identificación para que sea posible crear una huella digital basada en eso y emitir un Anti. - Token CSRF para cada huella dactilar que contacta con el sitio. Una vez más, no es perfecto, pero hace que el ataque sea más difícil de ejecutar.

Me gustaría proponer una variante del Encrypted Token Pattern que funciona de la siguiente manera: cuando un cliente solicita una página HTML que necesita protección CSRF ...

1. El servidor comprueba la existencia de una cookie sessionId . Si falta, el servidor establece una nueva cookie HttpOnly que contiene un valor pseudoaleatorio criptográficamente fuerte. Tenga en cuenta que este valor no se almacena en el servidor pero aún protege contra el CSRF de inicio de sesión (un atacante no puede autenticarse sin pasar por el formulario de inicio de sesión).
2. Si el usuario está desconectado, devuelva una página HTML que active la autenticación para las operaciones no seguras. Vuelve al paso 1.
3. Si el usuario ha iniciado sesión, el servidor cifra [sessionId + nonce] usando una clave secreta e inserta el valor (que llamaremos csrfToken ) en el archivo HTML. No es importante donde está incrustado csrfToken , siempre que la función Formulario o Javascript que realiza la solicitud pueda acceder a ella. nonce es un valor pseudoaleatorio criptográficamente sólido utilizado para prevenir ataques de fuerza bruta en la clave secreta, pero no se usa durante el proceso de validación.
4. Los formularios envían csrfToken usando un campo oculto del mismo nombre. Las funciones de Javascript envían csrfToken usando un encabezado de solicitud personalizado llamado csrf-token .
5. El servidor descifra csrfToken y compara su valor con sessionId . Si los dos no coinciden, el servidor devuelve 401 Unauthorized y activa la autenticación.

Puede aplicar cualquiera de las técnicas anti-CSRF estándar, ya sea el Patrón de token del sincronizador o las Cookies de envío doble. El primero generalmente es más seguro, ya que los subdominios pueden sobrescribir las cookies.

Usted afirmó que el patrón de token del sincronizador solo funciona después de la autenticación, pero este no es el caso. Un atacante no tiene acceso al token de un usuario, independientemente de si el usuario está autenticado o no.

Por supuesto, el atacante puede visitar la página de inicio de sesión y obtener un token anti-CSRF válido. Pero este token solo funciona para el atacante. Si la víctima hace una solicitud, entonces no se acepta el token, porque no está presente en la sesión de la víctima. De hecho, la sesión estará completamente vacía en la primera solicitud.