# CSRF

> Un ataque que hace que tu navegador mande, en tu nombre, un pedido que nunca quisiste.

- Nivel: Avanzado
- Temas: Seguridad
- URL: https://tidbit.legios.com.ar/es/csrf/
- En inglés: [CSRF](https://tidbit.legios.com.ar/csrf/)

**CSRF** viene de cross-site request forgery, algo así como falsificación de pedidos entre sitios. Aprovecha una costumbre de todo navegador: cuando una página le manda un pedido a un sitio, el navegador le pega solo las cookies de ese sitio, incluida la cookie de sesión que dice que estás logueado. Entonces, si tenés el home banking abierto en una pestaña y entrás a una página maliciosa en otra, esa página puede enviar en silencio un formulario al banco, y el banco ve un pedido normalísimo que viene de vos.

El ejemplo clásico: la página maliciosa tiene un formulario oculto que apunta a `https://bank.example/transfer` con la cuenta del atacante como destino, y una línea de JavaScript que lo envía apenas carga. Vos no ves nada. El atacante nunca ve tu contraseña ni tu cookie, y tampoco puede leer lo que responde el banco: el ataque funciona a ciegas. Esa es la diferencia con el cross-site scripting, donde el atacante logra ejecutar código adentro del sitio. Al CSRF le alcanza con que la acción sea predecible: cambiar el mail, cambiar la contraseña, hacer un pago.

Las defensas se combinan. Los sitios ponen en cada formulario un **token CSRF**, un secreto aleatorio, y rechazan los pedidos que no lo traen; una página ajena no lo puede adivinar. Las cookies se pueden marcar `SameSite=Lax` o `Strict` para que el navegador no las mande en pedidos que arrancan en otros sitios, y los navegadores modernos ya vienen con algo parecido por defecto. El servidor también puede revisar el encabezado `Origin` y pedir la contraseña de nuevo antes de cambios delicados. Casi todos los frameworks web traen protección contra CSRF de fábrica; los agujeros suelen aparecer cuando alguien la apaga o hace una acción importante con un simple link `GET`.

## Una analogía

Alguien te mete una boleta de extracción ya llenada y firmada en la pila de papeles que le llevás al cajero del banco. El cajero te conoce la cara y la procesa, porque vino de vos.

## Para quedarse

- Explota que el navegador manda solo las cookies al sitio al que pertenecen.
- El atacante dispara acciones en tu nombre pero no puede leer las respuestas.
- Defensas: tokens CSRF, cookies SameSite, chequeo de Origin, volver a pedir la clave.
- Un pedido GET nunca debería modificar datos.

## Para seguir leyendo

- [Cross-site request forgery en Wikipedia](https://es.wikipedia.org/wiki/Cross-site_request_forgery)
- [CSRF (MDN Web Docs)](https://developer.mozilla.org/es/docs/Glossary/CSRF)
- [Guía de prevención de CSRF de OWASP (en inglés)](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html)

## Términos relacionados

- [Navegador web](https://tidbit.legios.com.ar/es/web-browser/): La app que trae páginas web desde internet y las dibuja en tu pantalla.
- [Cookies](https://tidbit.legios.com.ar/es/cookies/): Notitas que un sitio le pide a tu navegador que guarde, para reconocerte después.
- [JavaScript](https://tidbit.legios.com.ar/es/javascript/): El lenguaje de programación que corre en las páginas web y las vuelve interactivas.
- [Cross-site scripting](https://tidbit.legios.com.ar/es/cross-site-scripting/): Meter código en un sitio web para que se ejecute en los navegadores de otros visitantes.
- [Servidor](https://tidbit.legios.com.ar/es/server/): Una computadora cuyo trabajo es responder pedidos de otras computadoras, todo el día.
- [Framework](https://tidbit.legios.com.ar/es/framework/): Un esqueleto ya armado para una app: define la estructura y llama a tu código.
