security - asp - filtro csrf
CSRF: ¿Puedo usar una cookie? (5)
Compruebe el patrón de token cifrado , que permite la protección CSRF sin estado sin la necesidad de almacenar tokens en el servidor.
¿Está bien poner el token CSRF en una cookie? (y en todas las formas, como información oculta, por lo que puedo verificar si coinciden, por supuesto). Escuché a alguien decir que al hacerlo, supera todo el propósito de la ficha, aunque no entiendo por qué. Me parece seguro.
Y si es seguro, ¿es menos seguro que poner el token en la URL?
¿Hay algún otro método?
¿Dónde puedo leer más sobre el tema?
ACTUALIZACIÓN : Hasta el momento, nadie puede decirme cómo es inseguro el método de cookies, si aún tiene que coincidir con el token del formulario, que el atacante no debería poder obtener, a menos que use otro truco como XSS, que es un materia diferente, y aún así no hace una diferencia entre el uso de cookies y el token de URL.
ACTUALIZACIÓN 2 : Bueno, parece que algunos marcos famosos utilizan este método, por lo que debería estar bien. Gracias
El uso de cookies funciona, y es una práctica común (por ejemplo, Django lo usa ). El atacante no puede leer ni cambiar el valor de la cookie debido a la política del mismo origen y, por lo tanto, no puede adivinar el parámetro GET / POST correcto.
El uso de una cookie derrota el propósito de CSRF. Este es el por qué:
CSRF funciona porque muchos sitios utilizan solicitudes GET para ejecutar comandos. Así que digamos que Bob tiene algún tipo de cuenta web administrativa y que ha iniciado sesión en ella. Alguna solicitud se podría hacer como:
http://somesite.com/admin/whatever.php?request=delete_record&id=4
Así que ahora Bob se vincula a un sitio de ataque (alguien está tratando de alterar sus datos). El atacante luego carga la URL anterior en una imagen, probablemente con otra identificación y elimina algún otro registro. El navegador lo carga porque Bob ya ha iniciado sesión en su sitio de administración, por lo que tiene una sesión válida.
CSRF busca eliminar esto agregando un parámetro seguro a la transacción. Ese parámetro debe rotar en cada solicitud y luego ser reenviado por el navegador. Haciendo que la URL se vea algo como esto:
http://somesite.com/admin/whatever.php?request=delete_record&id=4&csrf=<some long checksum>
La idea es que ahora el atacante tiene que adivinar "una suma de comprobación larga" para crear un ataque. Y si esa suma de comprobación gira en cada solicitud, debería ser prácticamente imposible.
PERO si almacena esa suma de comprobación en una cookie, está de vuelta en la casilla 1. El atacante ya no tiene que adivinarlo. Simplemente crea la URL original. El parámetro CSRF ya está allí en la cookie y se envía junto con la sesión. No detiene el comportamiento inseguro.
Si decide poner el token CSRF en una cookie, recuerde marcar esa cookie como HttpOnly . Si su sitio tiene una vulnerabilidad de secuencias de comandos entre sitios, el pirata informático no podrá leer el token CSRF. Puede verificar las cookies que se pueden leer con JavaScript mediante el comando console.log(document.cookie) en cualquier consola del navegador moderno. Si tiene cookies de sesión u otras cookies confidenciales, estas también deben estar marcadas como HttpOnly .
Otras lecturas:
"CSRF funciona porque muchos sitios usan solicitudes GET para ejecutar comandos". Por lo tanto, muchos sitios no utilizan el método GET como se esperaba, ya que estas solicitudes deben ser idempotentes: consulte el rfc2616 .
"El parámetro CSRF ya está allí en la cookie y se envía junto con la sesión". , ¿así que cómo?
La cookie solo se utiliza tiene un almacenamiento de token, como el DOM cuando configuramos el token en un campo de entrada oculto. Una pieza de javascript debe obtener el valor del token de esta cookie y establecerlo como un parámetro en la URL, el cuerpo de la solicitud o en el encabezado de la solicitud. Se verificará en el servidor con el valor almacenado en la sesión. Esa es la forma Django de manejar el token CSRF.
Javascript no puede acceder a la cookie desde otro dominio, debido a la protección del navegador entre dominios, por lo que no sé cómo un usuario malintencionado puede forzar a alguien a enviar el token correcto a lo largo de una solicitud falsificada. Con un XSS, sí, pero XSS derrota las contramedidas comunes de CSRF.
Prefiero dar esta aclaración, porque creo que es una pregunta importante y no tan fácil de manejar.
La solicitud GET se debe usar para obtener un recurso y / o mostrar sus datos, no se debe usar para cambiar su estado (eliminación, incremento de propiedades o cualquier cambio).
La validación de CSRF debe realizarse en el lado del servidor, parece ser obvio, pero lo pongo como un recordatorio. Este método no puede ser un vector de ataque si observas estas recomendaciones.