CSRF, peticiones que la persona no eligió

Un CSRF necesita tres cosas a la vez: una acción que cambie algo, una sesión que ya esté abierta y un navegador que adjunte la cookie de forma automática a cualquier petición hacia ese sitio. La víctima no entrega nada; solo abre una página o un enlace mientras está conectada. Por eso lo que se prueba es si la aplicación exige algo más que la cookie para aceptar la acción.

Esa condición también marca el límite del hallazgo: sin una sesión abierta, no hay nada que aprovechar. El informe lo dice, porque cambia la probabilidad y por tanto la prioridad.

La defensa estándar es un token anti-CSRF: un valor imprevisible, distinto por sesión o por formulario, que el servidor incluye en la página y exige de vuelta con cada acción que cambia algo. Una página de otro origen no puede leerlo y por eso no puede incluirlo en la petición. Si falta o no coincide, el servidor la rechaza.

Abre formulario.txt y acciones.txt: la acción protegida rechazó la petición sin token.

Dos acciones aceptaron la petición sin token. No pesan lo mismo: el impacto depende de qué se puede conseguir con cada una. Para decidirlo se mira qué cambia la acción y qué otras funciones dependen de ello. Un cambio de correo, por ejemplo, tiene consecuencias sobre cualquier función que use ese correo como prueba de identidad.

Lee recuperacion.txt y relaciónalo con acciones.txt.

La corrección es un token anti-CSRF verificado en el servidor en cada acción que cambia algo. El atributo SameSite de la cookie de sesión es una capa adicional útil, porque el navegador deja de enviarla en ciertas peticiones entre sitios, pero no sustituye al token. Comprobar solo el método, o esconder la dirección de la acción, no corrige nada: la petición se puede construir igual y la dirección no es un secreto.

Para las acciones más sensibles, pedir otra vez la contraseña actual (como hace la de cambiar contraseña en la evidencia) añade una barrera que el CSRF no puede saltar.

La acción de quitar un favorito cambia algo con una petición GET y sin token. Una petición GET no debería cambiar nada: los navegadores, los precargadores y las herramientas la usan sin que la persona lo decida. Corregirla significa pasarla a un método que cambie estado y protegerla igual que las demás. La severidad, en cambio, se razona con el efecto: un favorito quitado se recupera y no da acceso a nada.