Métodos de protección y omisiones de falsificación de solicitud entre sitios (CSRF)

La falsificación de requests entre sitios es una vulnerabilidad que se encuentra en las aplicaciones web y que permite que un atacante externo realice acciones confidenciales en nombre de un usuario. La explotación de este error puede afectar tanto a los usuarios normales como a los administradores del sitio, lo que a veces lleva a un compromiso total de un sitio web. Los sitios web modernos tienden a implementar algunos mecanismos de protección contra este ataque. La mayoría de los mecanismos de protección son para identificar y rechazar una solicitud que se originó en un sitio web diferente.

Los métodos de protección utilizados actualmente son:

1. Token Anti CSRF
Esta es una string criptográficamente fuerte que se envía al sitio web por separado de las cookies. Esto se puede enviar como un parámetro de solicitud o como un encabezado HTTP. El servidor verifica la presencia y corrección de este token cuando se realiza una solicitud y continúa solo si el token es correcto y las cookies son válidas.

2. Método HTTP PUT
El método PUT se utiliza para crear instancias de un recurso en el servidor. Es similar a POST, excepto que enviar las mismas requests PUT varias veces no hace nada adicional. Si el servidor está utilizando el método PUT para acciones confidenciales, entonces no hay necesidad de ninguna protección CSRF adicional (a menos que esté habilitado el uso compartido de recursos de origen cruzado) en ese punto final. Esto se debe a que la solicitud PUT no se puede duplicar a través de una página web como la solicitud POST (los formularios HTTP no permiten requests PUT). Sin embargo, las requests PUT de XHR se pueden enviar y tendrán éxito si el punto final tiene CORS mal configurado.

3. Autenticación de portador HTTP
Este es un tipo de autenticación HTTP donde el usuario se identifica a través de un token que se envía en el encabezado «Autorización» de cada solicitud. Este mecanismo resuelve CSRF porque, a diferencia de las cookies, el navegador no lo envía automáticamente.

Existen problemas y potenciales derivaciones a cada uno de estos métodos. Los tokens anti CSRF no tienen un estándar fijo, por lo que su mecanismo de generación y uso depende únicamente de cómo los desarrolladores pretendieron que fuera. Debido a esta falta de un estándar, existen muchas lagunas específicas de implementación en las aplicaciones web.

• Algunos sitios web verifican si el token CSRF está vinculado a una sesión o no, pero no verifican si el token está vinculado a la misma sesión a la que intenta acceder la solicitud.
• Algunos sitios web envían el token en un parámetro de encabezado/solicitud, así como en una cookie, y estos tokens se comparan en el lado del servidor. Si la coincidencia es exitosa, se permite la operación. Pero si el sitio web no verifica la autenticidad del token en sí mismo y el sitio web es vulnerable a XSS, este mecanismo se puede eludir fácilmente proporcionando un token aleatorio en el parámetro/encabezado de la solicitud y colocando el mismo token que la cookie al explotar la vulnerabilidad XSS. .
• Esto también se puede omitir si el punto final tiene un CORS mal configurado.
• Si el sitio web es vulnerable a la reparación de la interfaz de usuario (clickjacking), entonces este mecanismo no sirve.

El método HTTP PUT está a salvo de XSS porque no hay ningún «token» que se pueda filtrar. Pero si el sitio web permite el uso compartido de recursos de origen cruzado y no está configurado correctamente, un atacante puede simplemente duplicar una solicitud PUT enviándola a través de XHR. La configuración incorrecta más común refleja el encabezado de origen en la respuesta como un valor de «Acceso-Control-Permitir-Origin». Junto con esto, si el método PUT está permitido para la solicitud CORS, entonces se puede realizar fácilmente un ataque CSRF enviando una solicitud XHR diseñada al punto final. Dado que los formularios HTML pueden permitir requests PUT en algún estándar próximo. Entonces, el desarrollador debe mantenerse actualizado al respecto.
Además, un método PUT mal configurado puede permitir la carga arbitraria de archivos en el servidor.

La autenticación de portador es una buena manera de evitar CSRF, ya que no hay forma de que un atacante sepa el valor de un token válido de un usuario autenticado. Pero algunos sitios web utilizan tanto las cookies como el token del portador como mecanismo de autenticación. En ausencia de un token, pueden confiar en las cookies para la autenticación, lo que hará que la aplicación web sea vulnerable a CSRF.

Los desarrolladores siempre deben tener en cuenta estas cosas al desarrollar un mecanismo anti-CSRF:
1. Nunca envíe tokens CSRF a través de requests GET.
2. Vincule el token a la sesión de un usuario e invalidelo tan pronto como expire la sesión.
3. No utilice sistemas de codificación reversibles para la creación de tokens CSRF.
4. No permita requests PUT entre dominios si confía en requests PUT para la protección CSRF.
5. No use un solo token para cada sesión de un usuario.