Imagine que tiene un sitio web como un Twitter simplificado, alojado en a.com. Los usuarios registrados pueden ingresar texto (un tweet) en un formulario que se envía al servidor como una solicitud POST y se publica cuando presionan el botón Enviar. En el servidor, el usuario se identifica mediante una cookie que contiene su ID de sesión única, por lo que su servidor sabe quién publicó el Tweet.
La forma podría ser tan simple como eso:
<form action="http://a.com/tweet" method="POST">
<input type="text" name="tweet">
<input type="submit">
</form>
Ahora imagine que un chico malo copia y pega este formulario en su sitio web malicioso, digamos b.com. La forma aún funcionaría. Siempre que un usuario haya iniciado sesión en su Twitter (es decir, que tenga una cookie de sesión válida para a.com), la solicitud POST se enviará
http://a.com/tweety procesará como de costumbre cuando el usuario haga clic en el botón Enviar.
Hasta ahora, este no es un gran problema, siempre y cuando el usuario esté al tanto de lo que hace exactamente el formulario, pero qué pasa si nuestro chico malo modifica el formulario de esta manera:
<form action="https://example.com/tweet" method="POST">
<input type="hidden" name="tweet" value="Buy great products at http://b.com/#iambad">
<input type="submit" value="Click to win!">
</form>
Ahora, si uno de tus usuarios termina en el sitio web del malo y presiona el botón "¡Haz clic para ganar!" botón, el formulario se envía a su sitio web, el usuario se identifica correctamente mediante la ID de sesión en la cookie y se publica el Tweet oculto.
Si nuestro chico malo fuera aún peor, haría que el usuario inocente envíe este formulario tan pronto como abra su página web usando JavaScript, tal vez incluso completamente oculto en un iframe invisible. Esto es básicamente una falsificación de solicitud entre sitios.
Un formulario se puede enviar fácilmente desde cualquier lugar a todas partes. En general, esa es una característica común, pero hay muchos más casos en los que es importante permitir que solo se envíe un formulario desde el dominio al que pertenece.
Las cosas son aún peores si su aplicación web no distingue entre solicitudes POST y GET (por ejemplo, en PHP usando $ _REQUEST en lugar de $ _POST). ¡No hagas eso! Las solicitudes de modificación de datos se pueden enviar tan fácilmente como<img src="http://a.com/tweet?tweet=This+is+really+bad"> integrarse en un sitio web malicioso o incluso en un correo electrónico.
¿Cómo me aseguro de que un formulario solo se pueda enviar desde mi propio sitio web? Aquí es donde entra en juego el token CSRF. Un token CSRF es una cadena aleatoria, difícil de adivinar. En una página con un formulario que desea proteger, el servidor generará una cadena aleatoria, el token CSRF, lo agregará al formulario como un campo oculto y también lo recordará de alguna manera, ya sea almacenándolo en la sesión o configurando una cookie que contiene el valor Ahora el formulario se vería así:
<form action="https://example.com/tweet" method="POST">
<input type="hidden" name="csrf-token" value="nc98P987bcpncYhoadjoiydc9ajDlcn">
<input type="text" name="tweet">
<input type="submit">
</form>
Cuando el usuario envía el formulario, el servidor simplemente tiene que comparar el valor del campo csrf-token publicado (el nombre no importa) con el token CSRF recordado por el servidor. Si ambas cadenas son iguales, el servidor puede continuar procesando el formulario. De lo contrario, el servidor debería detener inmediatamente el procesamiento del formulario y responder con un error.
¿Por qué funciona esto? Hay varias razones por las cuales el malo de nuestro ejemplo anterior no puede obtener el token CSRF:
Copiar el código fuente estático de nuestra página a un sitio web diferente sería inútil, porque el valor del campo oculto cambia con cada usuario. Sin que el sitio web del malo conozca el token CSRF del usuario actual, su servidor siempre rechazará la solicitud POST.
Debido a que la página maliciosa del malo es cargada por el navegador de su usuario desde un dominio diferente (b.com en lugar de a.com), el malo no tiene la posibilidad de codificar un JavaScript, que carga el contenido y, por lo tanto, el token CSRF actual de nuestro usuario su página web. Esto se debe a que los navegadores web no permiten solicitudes AJAX entre dominios de forma predeterminada.
El malo tampoco puede acceder a la cookie establecida por su servidor, porque los dominios no coincidirían.
¿Cuándo debo proteger contra la falsificación de solicitudes entre sitios? Si puede asegurarse de no mezclar GET, POST y otros métodos de solicitud como se describe anteriormente, un buen comienzo sería proteger todas las solicitudes POST de forma predeterminada.
No tiene que proteger las solicitudes PUT y DELETE, porque como se explicó anteriormente, un navegador no puede enviar un formulario HTML estándar utilizando esos métodos.
JavaScript, por otro lado, puede hacer otros tipos de solicitudes, por ejemplo, utilizando la función $ .ajax () de jQuery, pero recuerde, para que las solicitudes AJAX funcionen, los dominios deben coincidir (siempre y cuando no configure explícitamente su servidor web) .
Esto significa que, a menudo, ni siquiera tiene que agregar un token CSRF a las solicitudes AJAX, incluso si son solicitudes POST, pero tendrá que asegurarse de que solo omita la verificación CSRF en su aplicación web si la solicitud POST es realmente un Solicitud AJAX. Puede hacerlo buscando la presencia de un encabezado como X-Requested-With, que las solicitudes de AJAX generalmente incluyen. También puede establecer otro encabezado personalizado y verificar su presencia en el lado del servidor. Eso es seguro, ya que un navegador no agregaría encabezados personalizados a un envío de formulario HTML normal (ver arriba), por lo que no es posible que el Sr. Bad Guy simule este comportamiento con un formulario.
Si tiene dudas acerca de las solicitudes AJAX, porque por alguna razón no puede verificar un encabezado como X-Requested-With, simplemente pase el token CSRF generado a su JavaScript y agregue el token a la solicitud AJAX. Hay varias maneras de hacer esto; ya sea agregarlo a la carga útil como lo haría un formulario HTML normal, o agregar un encabezado personalizado a la solicitud AJAX. Siempre que su servidor sepa dónde buscarlo en una solicitud entrante y pueda compararlo con el valor original que recuerda de la sesión o cookie, estará ordenado.