Para entender un ataque de cross site request forgery primero necesitamos saber un par de cosas acerca de las aplicaciones web. Primero, que estas usan el protocolo Http para comunicarse y que como aprendimos al hablar de REST, las peticiones Http son stateless, es decir cada petición es independiente y no lleva ningún tipo de contexto.
Segundo, que para que las páginas sepan por ejemplo, qué usuario está logueado, se guardan cookies en tu navegador, estas cookies contienen información que le pueden ayudar al servidor a guardar datos como una sesión de usuarios. El navegador envía las cookies en cada petición que se hace a tu dominio, para que el servidor las lea y use.
Si yo, por ejemplo, copiara el formulario de comentarios de Código Facilito en mi propia página, al detectar el navegador que el formulario se envía a la página de codigofacilito.com incluiría cualquier cookie asociada a este dominio codigofacilito.com
Este comportamiento de la web abre una brecha de seguridad importante y muy peligrosa si no se previene. Muchas páginas protegen peticiones sensibles detrás de un formulario de autenticación que guarda una cookie, así si quieres eliminar una cuenta, transferir dinero del banco, agregar un comentario, subir un vídeo, primero debes iniciar sesión. El servidor debe recibir la cookie, validar que tienes permisos para la acción solicitada y ejecutarla.
El hecho de que esta cookie se envíe, incluso en peticiones fuera de la página a la que pertenecen dichas cookies abre puerta a que un hacker copie la solicitud y la envíe, asumiendo que el navegador enviará una cookie existente para validar los permisos de dicha petición.
En términos prácticos, yo podría hacer una petición para eliminar tu cuenta de Código Facilito, y si ya has iniciado sesión en alguna otra pestaña, el navegador enviará automáticamente la cookie junto con mi petición maliciosa.
El riesgo de una petición CSRF es el atacante podría enviar una petición usando JavaScript, tan pronto carga la página a ciertas páginas en las que espera que el usuario ya tengo una sesión iniciada, para que la cookie acompañe su petición, abriendo una brecha de seguridad para dichas aplicaciones.
Comúnmente, las aplicaciones web pueden protegerse de esta clase de ataques, asignando a cada petición un secreto, una combinación de caracteres que cambia constantemente, que el servidor conoce.
Esto quiere decir que cuando tú envías un formulario en una de estas aplicaciones, además de los parámetros visibles del formulario, se agrega una cadena de caracteres, que el servidor asignó para dicho formulario, el servidor al recibir la petición compara la cadena con la que asignó y si son iguales, acepta la solicitud.
Para un atacante, es imposible saber cuál sería esta cadena, una vez que cambia constantemente y es asignada una distinta para cada formulario o para cada usuario. Por lo que si intentamos hacer una petición sin esta clave o con una clave incorrecta, el servidor rechazará la petición.
Que agregará al HTML un campo oculto con el token de protección CSRF. Por defecto, cualquier petición con un verbo Http que no sea GET, que no venga con el token de autenticidad, será rechazada por Rails.
Para pasar esta validación, podemos usar el siguiente helper:
hidden_field_tag :authenticity_token, form_authenticity_token
Éste, agrega un campo oculto con el token de autenticidad para el formulario, con lo que al enviar los datos, se incluirá este token y Rails validará nuestra petición.
Esto explica por qué añadimos dicha instrucción al formulario en el capítulo pasado.
Continuemos.