Almacenamiento del token anti-CSRF en una cookie

Dice "sesión": ¿tiene una sesión del lado del servidor? Si es así, ¿por qué no poner el token CSRF en la sesión en lugar de una cookie del lado del cliente? Ese es el patrón normal; evita que un atacante pueda usar su propio valor de token CSRF generado contra otro usuario en el caso de que tenga una corrección de cookies.

Otro enfoque similar al agua que no necesita una cookie adicional, si no tiene almacenamiento en el lado del servidor, es crear un valor que incluya el usuario o el ID de la sesión y firmarlo con un MAC (generalmente HMAC) con un lado del servidor secreto. El servidor puede verificar que el token en el formulario proviene del usuario cuya sesión es.

  

el atacante no puede leer ni establecer la cookie de un dominio que no posee

Bueno, probablemente ... por lo general. Formas en que la inyección de cookies tiende a suceder (aparte de XSS, en cuyo caso ya perdió mucho más):

• errores del navegador, tablas / reglas de "dominio genérico" obsoletas, etc.
• dominios vecinos vulnerables (por ejemplo, establecer una cookie en www.example.com desde test.example.com)
• permitir que su sitio se sirva desde un dominio atacante (siempre verifique el Nombre de host: es un nombre de dominio reconocido como bueno)

Estos suelen ser problemas marginales, pero dependen de factores potencialmente fuera de su control como autor de la aplicación. Por lo tanto, en el caso de los sistemas sensibles a la seguridad, generalmente es una buena idea no confiar en que sus cookies no sean fijables.

Puramente como un mecanismo Anti-CSRF que me suena razonable. La protección estándar es utilizar un token aleatorio en un campo de formulario oculto y luego verificarlo en el envío, por lo que me parece que la única diferencia en su esquema es que, en lugar de mantener ese token del lado del servidor, lo está comparando con un token en una cookie. La solución con la que ha llegado suena como la opción "Enviar cookies" de la OWASP Anti -CSRF Cheatsheet

Obviamente, si hay otros problemas en su aplicación (por ejemplo, las secuencias de comandos entre sitios) es probable que tenga problemas, pero luego XSS causa todo tipo de problemas.

De acuerdo con mis puntos de vista, esto no es una implementación completamente segura, ya que solo valida que el valor de la cookie y el parámetro param son " iguales y existen ", y si hay un CRLF Vulnerabilidad de inyección también conocida como HTTP Response Splitting en la aplicación, que me permite configurar otra cookie llamada "csrftoken = test" y el valor de param de csrf post "test" y enviar la solicitud. Esto omite la comprobación de csrf en su conjunto ambos valores son prueba y coincidencias.

Corrígeme si me equivoco.

Un atacante puede enviarle un enlace que abrirá su navegador cuando tenga una sesión en su aplicación protegida. Esto puede suceder incluso mostrando imágenes en un correo electrónico. En este caso, la solicitud de su navegador contiene la cookie de sesión pero no el token anti-CRSF y el servidor puede invalidar la solicitud maliciosa del navegador de la víctima. Los tokend de CSRF tienen que vivir en la sesión del servidor y en la página html, no en la cookie que se envía desde el cliente en todo momento. También es recomendable volver a generar el valor en cada solicitud (un token de tiempo) y solicitar nuevamente las credenciales de inicio de sesión para solicitudes especiales (cambiar la contraseña, aplicar el filtro de correo electrónico, etc.).