Imagine una aplicación web de banca electrónica en banking.example.com
con el siguiente formulario para enviar una transacción:
<form action="/transaction" method="post">
<input type="text" name="beneficiary"/>
<input type="text" name="amount"/>
<input type="submit" value="Pay"/>
</form>
Un atacante podría ahora crear un sitio web en hacker.net
con lo siguiente:
<form action="https://banking.example.com/transaction" method="post" style="visibility:hidden">
<input type="text" name="beneficiary" value="John Doe, Account No. 34-236326-1"/>
<input type="text" name="amount" value="1000000"/>
<input type="submit" value="Pay"/>
</form>
<script>
document.forms[0].submit();
</script>
El atacante engañaría a las víctimas para que visiten el hacker.net
, lo que hará que los navegadores de las víctimas envíen una solicitud POST a la aplicación de banca electrónica, lo que implicará una gran transacción para el pirata informático. Esto funciona porque el navegador de la víctima envía felizmente la cookie de sesión junto con la solicitud POST falsificada a la aplicación de banca electrónica. Si el formulario hubiera estado protegido por un token CSRF, el atacante no podría haber causado que el navegador de la víctima enviara una solicitud POST válida y, por lo tanto, el ataque no sería posible.
Este tipo de ataque se denomina ataque de falsificación de solicitudes entre sitios (CSRF).
Incidentemente, los ataques de CSRF también son la razón por la cual las personas dan el consejo de nunca visitar otros sitios web mientras están conectados a una banca electrónica u otra aplicación web crítica.
Los tokens CSRF no protegen un formulario web que los usuarios normales autorizados envían automáticamente como ellos mismos. Para protegerse de eso, usaría un CAPTCHA.
@agf Acabo de leer esa pregunta, y no veo la duplicación ': (' –
Claro, estoy leyendo la respuesta ahora ...;) –
Usted describe una publicación "anónima". Se trata de proteger esa publicación de que ocurra con las credenciales de un usuario autenticado. – Cheekysoft