El token de autenticidad se usa para evitar ataques de falsificación de solicitudes entre sitios (CSRF). Para comprender el token de autenticidad, primero debe comprender los ataques CSRF.
CSRF
Supongamos que usted es el autor de bank.com. Tiene un formulario en su sitio que se utiliza para transferir dinero a una cuenta diferente con una solicitud GET:
Un pirata informático podría enviar una solicitud HTTP al servidor diciendo GET /transfer?amount=$1000000&account-to=999999, ¿verdad?
Incorrecto. El ataque de los hackers no funcionará. El servidor básicamente pensará?
¿Eh? ¿Quién es este tipo tratando de iniciar una transferencia? No es el propietario de la cuenta, eso es seguro.
¿Cómo sabe esto el servidor? Porque no hay session_idcookies que autentiquen al solicitante.
Cuando inicia sesión con su nombre de usuario y contraseña, el servidor establece una session_idcookie en su navegador. De esa manera, no tiene que autenticar cada solicitud con su nombre de usuario y contraseña. Cuando su navegador envía la session_idcookie, el servidor sabe:
Oh, ese es John Doe. Ingresó exitosamente hace 2.5 minutos. Él es bueno para irse.
Un hacker podría pensar:
Hmm Una solicitud HTTP normal no funcionará, pero si pudiera conseguir esa session_idcookie, sería oro.
El navegador de los usuarios tiene un conjunto de cookies establecidas para el bank.comdominio. Cada vez que el usuario realiza una solicitud al bank.comdominio, se envían todas las cookies. Incluyendo elsession_id galleta.
Así que si un pirata informático podría conseguir que haga la solicitud GET que transfiere dinero a su cuenta, tendría éxito. ¿Cómo podría engañarte para que lo hagas? Con falsificación de solicitud de sitio cruzado.
Es bastante simple, en realidad. El hacker podría hacerte visitar su sitio web. En su sitio web, podría tener la siguiente etiqueta de imagen:
<img src="http://bank.com/transfer?amount=$1000000&account-to=999999">
Cuando el navegador del usuario encuentre esa etiqueta de imagen, realizará una solicitud GET a esa URL. Y dado que la solicitud proviene de su navegador, enviará con ella todas las cookies asociadas bank.com. Si el usuario había iniciado sesión recientemente en bank.com... la session_idcookie se establecerá, ¡y el servidor pensará que el usuario tenía la intención de transferir $ 1,000,000 a la cuenta 999999!
Bueno, simplemente no visites sitios peligrosos y estarás bien.
Eso no es suficiente. ¿Qué pasa si alguien publica esa imagen en Facebook y aparece en su muro? ¿Qué pasa si se inyecta en un sitio que estás visitando con un ataque XSS?
No es tan malo. Solo las solicitudes GET son vulnerables.
No es verdad. Un formulario que envía una solicitud POST puede generarse dinámicamente. Aquí está el ejemplo de la Guía de Rails sobre Seguridad :
<a href="http://www.harmless.com/" onclick="
var f = document.createElement('form');
f.style.display = 'none';
this.parentNode.appendChild(f);
f.method = 'POST';
f.action = 'http://www.example.com/account/destroy';
f.submit();
return false;">To the harmless survey</a>
Token de autenticidad
Cuando tienes ApplicationControlleresto:
protect_from_forgery with: :exception
Esta:
<%= form_tag do %>
Form contents
<% end %>
Se compila en esto:
<form accept-charset="UTF-8" action="/" method="post">
<input name="utf8" type="hidden" value="✓" />
<input name="authenticity_token" type="hidden" value="J7CBxfHalt49OSHp27hblqK20c9PgwJ108nDHX/8Cts=" />
Form contents
</form>
En particular, se genera lo siguiente:
<input name="authenticity_token" type="hidden" value="J7CBxfHalt49OSHp27hblqK20c9PgwJ108nDHX/8Cts=" />
Para protegerse contra los ataques CSRF, si Rails no ve el token de autenticidad enviado junto con una solicitud, no considerará la solicitud como segura.
¿Cómo se supone que un atacante sabe qué es este token? Se genera un valor diferente al azar cada vez que se genera el formulario:
Un ataque Cross Site Scripting (XSS): así es como. Pero esa es una vulnerabilidad diferente para un día diferente.