Qué hace posible una petición no deseada

Una falsificación de petición entre sitios (CSRF, CWE-352) ocurre cuando una página de otro sitio hace que el navegador de una persona con la sesión abierta envíe una acción al portal, y el portal la acepta como si la persona la hubiera elegido. Para que sea posible tienen que darse tres cosas a la vez: una acción que cambie algo, una credencial que el navegador adjunte solo (una cookie de sesión, por ejemplo) y unos parámetros que quien arma la página pueda conocer de antemano.

Si falta cualquiera de las tres, la acción no se puede disparar a ciegas. Por eso la revisión empieza por un inventario: qué cambia cada acción, cómo se autentica y si exige algo que solo conoce la persona o su página.

No toda autenticación se adjunta de forma automática. Una cookie sí: el navegador la añade a cada petición hacia su dominio. Un token que la página guarda en memoria y coloca ella misma en una cabecera no: solo lo envía el código que lo conoce, y una página de otro sitio no puede leerlo.

Abre inventario-acciones.txt y fíjate en la columna de autenticación y en las notas del equipo.

El tercer ingrediente es la previsibilidad. Si una acción exige un valor que quien arma la página ajena no puede conocer, la petición falsificada llega incompleta y falla. Así funciona, en el fondo, cualquier token anti-CSRF; pero también lo consigue una acción que pide un secreto de la persona.

Busca en el inventario una acción que no lleva token de formulario y aun así exige algo que solo sabe el asociado.

Muchos equipos creen que una API JSON está a salvo por ser API. Un formulario HTML de otro sitio solo puede enviar ciertos tipos de cuerpo (application/x-www-form-urlencoded, multipart/form-data y text/plain), y el navegador los envía sin consulta previa. Si la API se autentica con la cookie y además acepta alguno de esos tipos, queda tan expuesta como un formulario viejo. Exigir application/json obliga al navegador a una consulta previa entre orígenes, que el servidor puede negar.

Lee las notas del equipo en el inventario.

La cabecera Referer, cuando viene, dice desde qué página salió la petición. Un cambio legítimo de cuenta destino sale de las páginas del propio portal; uno que llega con la dirección de otro sitio es la huella de una acción que la persona no eligió. Cruza registro-cambios.txt con la nota de soporte.