¿Qué es un token CSRF? ¿Cuál es su importancia y cómo funciona?
Estoy escribiendo una aplicación (Django, da la casualidad) y solo quiero tener una idea de qué es realmente un "token CSRF" y cómo protege los datos.
¿Los datos de la publicación no son seguros si no usas tokens CSRF?
Falsificación de solicitudes entre sitios (CSRF) en palabras simples
- Supongamos que actualmente ha iniciado sesión en su banca en línea en
www.mybank.com - Supongamos que una transferencia de dinero
mybank.comdará como resultado una solicitud (conceptualmente) del formulariohttp://www.mybank.com/transfer?to=<SomeAccountnumber>;amount=<SomeAmount>. (Su número de cuenta no es necesario porque está implícito en su inicio de sesión). - Visitas
www.cute-cat-pictures.org, sin saber que es un sitio malicioso. - Si el propietario de ese sitio conoce el formulario de la solicitud anterior (¡fácil!) y adivina correctamente que usted ha iniciado sesión
mybank.com(¡requiere algo de suerte!), podría incluir en su página una solicitud comohttp://www.mybank.com/transfer?to=123456;amount=10000(¿dónde123456está el número de su cuenta en las Islas Caimán? y10000es una cantidad que antes creías que te alegraría poseer ). - Usted recuperó esa
www.cute-cat-pictures.orgpágina, por lo que su navegador realizará esa solicitud. - Su banco no puede reconocer este origen de la solicitud: su navegador web enviará la solicitud junto con su
www.mybank.comcookie y parecerá perfectamente legítima. ¡Ahí va tu dinero!
Este es el mundo sin tokens CSRF .
Ahora lo mejor con tokens CSRF :
- La solicitud de transferencia se amplía con un tercer argumento:
http://www.mybank.com/transfer?to=123456;amount=10000;token=31415926535897932384626433832795028841971. - Ese token es un número aleatorio enorme, imposible de adivinar, que
mybank.comse incluirá en su propia página web cuando se lo entreguen. Es diferente cada vez que le muestran una página a alguien. - El atacante no puede adivinar el token, no puede convencer a su navegador web para que lo entregue (si el navegador funciona correctamente...), por lo que el atacante no podrá crear una solicitud válida, porque las solicitudes con el El token incorrecto (o ningún token) será rechazado por
www.mybank.com.
Resultado: conservas tus 10000unidades monetarias.
(Su experiencia puede ser diferente.)
EDITAR del comentario que vale la pena leer de SOFe :
Vale la pena señalar que el script
www.cute-cat-pictures.orgnormalmente no tiene acceso a su token anti-CSRFwww.mybank.comdebido al control de acceso HTTP. Esta nota es importante para algunas personas que envían sin razón un encabezadoAccess-Control-Allow-Origin: *para cada respuesta del sitio web sin saber para qué sirve, simplemente porque no pueden usar la API de otro sitio web.
Sí, los datos de la publicación están seguros. Pero el origen de esos datos no lo es. De esta manera, alguien puede engañar al usuario con JS para que inicie sesión en su sitio mientras navega por la página web del atacante.
Para evitar eso, Django enviará una clave aleatoria tanto en la cookie como en los datos del formulario. Luego, cuando los usuarios realicen PUBLICACIONES, comprobará si dos claves son idénticas. En caso de que se engañe al usuario, el sitio web de terceros no puede obtener las cookies de su sitio, lo que provoca un error de autenticación.
