Las fugas entre sitios , también conocidas como fugas XS , son un término de seguridad de Internet que se utiliza para describir una clase de ataques que se utilizan para acceder a la información confidencial de un usuario en otro sitio web. Las fugas entre sitios permiten a un atacante acceder a las interacciones de un usuario con otros sitios web. Esto puede contener información confidencial. Los navegadores web normalmente impiden que otros sitios web vean esta información. Esto se aplica a través de un conjunto de reglas llamadas política del mismo origen . Los atacantes a veces pueden eludir estas reglas, utilizando una "fuga entre sitios". Los ataques que utilizan una fuga entre sitios a menudo se inician al incitar a los usuarios a visitar el sitio web del atacante. Al visitarlo, el atacante utiliza un código malicioso en su sitio web para interactuar con otro sitio web. Un atacante puede utilizar esto para conocer las acciones anteriores del usuario en el otro sitio web. La información de este ataque puede identificar de forma única al usuario ante el atacante.
Estos ataques se han documentado desde el año 2000. Uno de los primeros artículos de investigación sobre el tema fue publicado por investigadores de la Universidad de Purdue . El artículo describía un ataque en el que se explotaba la memoria caché web para recopilar información sobre un sitio web. Desde entonces, las filtraciones entre sitios se han vuelto cada vez más sofisticadas. Los investigadores han descubierto filtraciones más nuevas dirigidas a varios componentes del navegador web. Si bien la eficacia de algunas de estas técnicas varía, continuamente se descubren técnicas más nuevas. Algunos métodos más antiguos se bloquean mediante actualizaciones del software del navegador. La introducción y eliminación de funciones en Internet también hace que algunos ataques se vuelvan ineficaces.
Las fugas entre sitios son una forma diversa de ataque y no existe una clasificación uniforme de dichos ataques. Varias fuentes clasifican las fugas entre sitios según la técnica utilizada para filtrar información. Entre las fugas entre sitios más conocidas se encuentran los ataques de sincronización, que dependen de eventos de sincronización dentro del navegador web. Los eventos de error constituyen otra categoría, que utilizan la presencia o ausencia de eventos para revelar datos. Además, los ataques de sincronización de caché se basan en la caché web para revelar información. Desde 2023, también se han encontrado ataques más nuevos que utilizan los sistemas operativos y los límites del navegador web para filtrar información.
Antes de 2017, se consideraba que la defensa contra las fugas entre sitios era difícil, ya que muchos de los problemas de fuga de información que explotaban los ataques de fuga entre sitios eran inherentes a la forma en que funcionaban los sitios web. La mayoría de las defensas contra esta clase de ataques se introdujeron después de 2017 en forma de extensiones del protocolo de transferencia de hipertexto (HTTP). Estas extensiones permiten a los sitios web indicar al navegador que no permita o anote ciertos tipos de solicitudes con estado que provienen de otros sitios web. Uno de los enfoques más exitosos que han implementado los navegadores son las cookies SameSite . Las cookies SameSite permiten a los sitios web establecer una directiva que impide que otros sitios web accedan y envíen cookies confidenciales. Otra defensa implica el uso de encabezados HTTP para restringir qué sitios web pueden incrustar un sitio en particular. La partición de caché también sirve como defensa contra las fugas entre sitios, lo que evita que otros sitios web utilicen la caché web para exfiltrar datos.
Las aplicaciones web (web apps) tienen dos componentes principales: un navegador web y uno o más servidores web . El navegador normalmente interactúa con los servidores a través del protocolo de transferencia de hipertexto (HTTP) y conexiones WebSocket para entregar una aplicación web. [nota 1] Para hacer que la aplicación web sea interactiva, el navegador también procesa HTML y CSS , y ejecuta el código JavaScript proporcionado por la aplicación web. Estos elementos permiten que la aplicación web reaccione a las entradas del usuario y ejecute la lógica del lado del cliente. [2] A menudo, los usuarios interactúan con la aplicación web durante largos períodos de tiempo, realizando múltiples solicitudes al servidor. Para realizar un seguimiento de dichas solicitudes, las aplicaciones web a menudo utilizan un identificador persistente vinculado a un usuario específico a través de su sesión actual o cuenta de usuario. [3] Este identificador puede incluir detalles como la edad o el nivel de acceso, que reflejan el historial del usuario con la aplicación web. Si se revelan a otros sitios web, estos atributos identificables podrían desanonimizar al usuario. [4]
Lo ideal sería que cada aplicación web funcionara de forma independiente sin interferir con las demás. Sin embargo, debido a las diversas opciones de diseño que se tomaron durante los primeros años de la web, las aplicaciones web pueden interactuar regularmente entre sí. [5] Para evitar el abuso de este comportamiento, los navegadores web aplican un conjunto de reglas llamadas política del mismo origen que limita las interacciones directas entre aplicaciones web de diferentes fuentes. [6] [7] A pesar de estas restricciones, las aplicaciones web a menudo necesitan cargar contenido de fuentes externas, como instrucciones para mostrar elementos en una página, diseños y videos o imágenes. Este tipo de interacciones, llamadas solicitudes de origen cruzado, son excepciones a la política del mismo origen. [8] Se rigen por un conjunto de reglas estrictas conocidas como el marco de intercambio de recursos de origen cruzado (CORS). CORS garantiza que dichas interacciones se produzcan en condiciones controladas al evitar el acceso no autorizado a los datos que una aplicación web no tiene permitido ver. Esto se logra al requerir un permiso explícito antes de que otros sitios web puedan acceder al contenido de estas solicitudes. [9]
Las fugas entre sitios permiten a los atacantes eludir las restricciones impuestas por la política del mismo origen y el marco CORS. Aprovechan los problemas de fuga de información ( canales laterales ) que históricamente han estado presentes en los navegadores. Mediante estos canales laterales, un atacante puede ejecutar código que puede inferir detalles sobre los datos que la política del mismo origen habría protegido. [10] Estos datos pueden luego usarse para revelar información sobre las interacciones anteriores de un usuario con una aplicación web. [11]
Para llevar a cabo un ataque de fuga entre sitios, un atacante primero debe estudiar cómo interactúa un sitio web con los usuarios. Necesitan identificar una URL específica que produzca diferentes respuestas de Protocolo de transferencia de hipertexto (HTTP) en función de las acciones anteriores del usuario en el sitio. [12] [13] Por ejemplo, si el atacante está tratando de atacar Gmail , podría intentar encontrar una URL de búsqueda que devuelva una respuesta HTTP diferente en función de la cantidad de resultados de búsqueda que se encuentren para un término de búsqueda específico en los correos electrónicos de un usuario. [14] Una vez que un atacante encuentra una URL específica, puede alojar un sitio web y realizar phishing o atraer de otro modo a usuarios desprevenidos al sitio web. Una vez que la víctima está en el sitio web del atacante, el atacante puede usar varias técnicas de incrustación para iniciar solicitudes HTTP de origen cruzado a la URL identificada por el atacante. [15] Sin embargo, dado que el atacante está en un sitio web diferente, la política del mismo origen impuesta por el navegador web evitará que el atacante lea directamente cualquier parte de la respuesta enviada por el sitio web vulnerable. [nota 2] [16]
Para sortear esta barrera de seguridad, el atacante puede utilizar métodos de filtración del navegador para distinguir diferencias sutiles entre diferentes respuestas. Los métodos de filtración del navegador son fragmentos de JavaScript , CSS o HTML que aprovechan problemas de filtración de información de larga data ( canales laterales ) en el navegador web para revelar características específicas sobre una respuesta HTTP. [12] [13] En el caso de Gmail, el atacante podría usar JavaScript para cronometrar el tiempo que tarda el navegador en analizar la respuesta HTTP devuelta por el resultado de la búsqueda. Si el tiempo que tarda en analizar la respuesta devuelta por el punto final es bajo, el atacante podría inferir que no hubo resultados de búsqueda para su consulta. Alternativamente, si el sitio tardó más, el atacante podría inferir que se devolvieron múltiples resultados de búsqueda. [14] El atacante puede utilizar posteriormente la información obtenida a través de estas filtraciones de información para exfiltrar información confidencial, que puede utilizarse para rastrear y desanonimizar a la víctima. [15] En el caso de Gmail, el atacante podría realizar una solicitud al punto final de búsqueda con una consulta y, posteriormente, medir el tiempo que tardó la consulta en averiguar si el usuario tenía o no correos electrónicos que contuvieran una cadena de consulta específica. [nota 3] Si una respuesta tarda muy poco tiempo en procesarse, el atacante puede suponer que no se devolvieron resultados de búsqueda. Por el contrario, si una respuesta tarda mucho tiempo en procesarse, el atacante puede inferir que se devolvieron muchos resultados de búsqueda. Al realizar múltiples solicitudes, un atacante podría obtener información significativa sobre el estado actual de la aplicación víctima, lo que podría revelar información privada de un usuario y ayudar a lanzar sofisticados ataques de spam y phishing. [17]
Las fugas de datos entre sitios se conocen desde el año 2000; [18] En los artículos de investigación de ese año de la Universidad de Purdue se describe un ataque teórico que utiliza la caché HTTP para comprometer la privacidad de los hábitos de navegación de un usuario. [19] En 2007, Andrew Bortz y Dan Boneh de la Universidad de Stanford publicaron un informe técnico que detallaba un ataque que utilizaba información de tiempo para determinar el tamaño de las respuestas entre sitios. [20] En 2015, investigadores de la Universidad Bar-Ilan describieron un ataque de búsqueda entre sitios que utilizaba métodos de fuga similares. El ataque empleaba una técnica en la que la entrada se creaba para aumentar el tamaño de las respuestas, lo que conducía a un crecimiento proporcional del tiempo necesario para generar las respuestas, aumentando así la precisión del ataque. [21]
Investigadores de seguridad independientes han publicado entradas de blog que describen ataques de fugas entre sitios contra aplicaciones del mundo real. En 2009, Chris Evans describió un ataque contra Yahoo! Mail a través del cual un sitio malicioso podría buscar información confidencial en la bandeja de entrada de un usuario. [22] En 2018, Luan Herrara encontró una vulnerabilidad de fuga entre sitios en el rastreador de errores Monorail de Google, que es utilizado por proyectos como Chromium , Angle y Skia Graphics Engine . Este exploit permitió a Herrara exfiltrar datos sobre problemas de seguridad sensibles al abusar del punto final de búsqueda del rastreador de errores. [23] [24] En 2019, Terjanq, un investigador de seguridad polaco, publicó una entrada de blog que describe un ataque de búsqueda entre sitios que les permitió exfiltrar información confidencial de los usuarios en productos de Google de alto perfil. [25] [26]
Como parte de su mayor enfoque en abordar los problemas de seguridad que dependen del uso indebido de funciones de plataformas web de larga data , Google lanzó XSLeaks Wiki en 2020. La iniciativa tenía como objetivo crear una base de datos de conocimiento abierto sobre las funciones de plataformas web que se estaban utilizando indebidamente y analizar y recopilar información sobre ataques de fugas entre sitios. [22] [27] [28]
Desde 2020, la comunidad académica de seguridad ha mostrado cierto interés por estandarizar la clasificación de estos ataques. En 2020, Sudhodanan et al. estuvieron entre los primeros en resumir sistemáticamente el trabajo previo sobre fugas entre sitios y desarrollaron una herramienta llamada BASTA-COSI que podría utilizarse para detectar URL con fugas. [28] [29] En 2021, Knittel et al. propusieron un nuevo modelo formal para evaluar y caracterizar las fugas entre sitios, lo que permitió a los investigadores encontrar nuevas fugas que afectaran a varios navegadores. [28] [30] En 2022, Van Goethem et al. evaluaron las defensas actualmente disponibles contra estos ataques y ampliaron el modelo existente para considerar el estado de los componentes del navegador como parte del modelo. [28] [13] En 2023, un artículo publicado por Rautenstrauch et al. que sistematizaba investigaciones previas sobre fugas entre sitios recibió el premio Distinguished Paper Award en el Simposio IEEE sobre Seguridad y Privacidad . [31]
El modelo de amenaza de una fuga de datos entre sitios se basa en que el atacante pueda dirigir a la víctima a un sitio web malicioso que esté al menos parcialmente bajo su control. El atacante puede lograr esto comprometiendo una página web, haciendo que el usuario ingrese a una página web y cargue código arbitrario, o utilizando un anuncio malicioso en una página web que de otro modo sería segura. [32] [33]
Los ataques de fuga de información entre sitios requieren que el atacante identifique al menos una URL dependiente del estado en la aplicación víctima para usarla en la aplicación de ataque. Según el estado de la aplicación víctima, esta URL debe proporcionar al menos dos respuestas. Una URL se puede crear, por ejemplo, vinculando a contenido al que solo puede acceder el usuario si ha iniciado sesión en el sitio web de destino. La inclusión de esta URL dependiente del estado en la aplicación maliciosa iniciará una solicitud de origen cruzado a la aplicación de destino. [15] Debido a que la solicitud es una solicitud de origen cruzado, la política del mismo origen impide que el atacante lea el contenido de la respuesta. Sin embargo, utilizando un método de fuga de información del navegador, el atacante puede consultar características identificables específicas de la respuesta, como el código de estado HTTP . Esto le permite al atacante distinguir entre respuestas y obtener información sobre el estado de la aplicación víctima. [12] [13]
Si bien cada método para iniciar una solicitud de origen cruzado a una URL en una página web se puede combinar con cada método de fuga de navegador, esto no funciona en la práctica porque existen dependencias entre los diferentes métodos de inclusión y fugas de navegador. Algunos métodos de fuga de navegador requieren técnicas de inclusión específicas para tener éxito. [34] Por ejemplo, si el método de fuga de navegador se basa en la comprobación de atributos CSS como el ancho y la altura de un elemento, la técnica de inclusión debe utilizar un elemento HTML con una propiedad de ancho y altura, como un elemento de imagen, que cambia cuando una solicitud de origen cruzado devuelve una imagen no válida o de un tamaño diferente. [35] [36]
Las fugas entre sitios comprenden una gama muy variada de ataques [37] para los que no existe una clasificación uniforme establecida. [38] Sin embargo, varias fuentes suelen clasificar estos ataques según las técnicas de fuga utilizadas durante un ataque. [34] A partir de 2021 [actualizar], los investigadores han identificado más de 38 técnicas de fuga que apuntan a componentes del navegador. [32] Las nuevas técnicas suelen descubrirse debido a cambios en las API de la plataforma web , que son interfaces de JavaScript que permiten a los sitios web consultar el navegador para obtener información específica. [39] Aunque la mayoría de estas técnicas implican la detección directa de cambios de estado en la aplicación web víctima, algunos ataques también explotan alteraciones en los componentes compartidos dentro del navegador para obtener información indirectamente sobre la aplicación web víctima. [34]
Los ataques de sincronización se basan en la capacidad de cronometrar eventos específicos en múltiples respuestas. [40] Estos fueron descubiertos por investigadores de la Universidad de Stanford en 2007, lo que los convierte en uno de los tipos de ataques de fuga entre sitios más antiguos que se conocen. [20]
Aunque inicialmente se utilizó solo para diferenciar entre el tiempo que tardaba una solicitud HTTP en resolver una respuesta, [20] las investigaciones realizadas después de 2007 han demostrado el uso de esta técnica de fuga para detectar otras diferencias entre los estados de las aplicaciones web. En 2017, Vila et al. demostraron que los ataques de sincronización podían inferir tiempos de ejecución de origen cruzado en contextos integrados. Esto fue posible gracias a la falta de funciones de aislamiento de sitios en los navegadores contemporáneos, lo que permitió que un sitio web atacante ralentizara y amplificara las diferencias de sincronización causadas por las diferencias en la cantidad de JavaScript que se ejecutaba cuando se enviaban eventos a una aplicación web víctima. [41] [42]
En 2021, Knittel et al. demostraron que la API Performance [nota 4] podía filtrar la presencia o ausencia de redirecciones en las respuestas. Esto fue posible debido a un error en la API Performance que permitía que la cantidad de tiempo que se mostraba al usuario fuera negativa cuando se producía una redirección. Google Chrome corrigió posteriormente este error. [44] En 2023, Snyder et al. demostraron que los ataques de sincronización podían utilizarse para realizar ataques de pool-party en los que los sitios web podían bloquear recursos compartidos agotando su cuota global. Al hacer que la aplicación web víctima ejecutara JavaScript que utilizaba estos recursos compartidos y luego cronometrar el tiempo que tardaban estas ejecuciones, los investigadores pudieron revelar información sobre el estado de una aplicación web. [45]
Los eventos de error son una técnica de fuga que permite a un atacante distinguir entre múltiples respuestas mediante el registro de controladores de eventos de error y la escucha de eventos a través de ellos. Debido a su versatilidad y capacidad para filtrar una amplia gama de información, los eventos de error se consideran un vector de fuga clásico entre sitios. [46]
Uno de los casos de uso más comunes para los eventos de error en los ataques de fugas entre sitios es determinar las respuestas HTTP adjuntando los controladores de eventos onloady onerrorlos controladores de eventos a un elemento HTML y esperando que ocurran eventos de error específicos. La falta de eventos de error indica que no se produjeron errores HTTP. Por el contrario, si el controlador onerrorse activa con un evento de error específico, el atacante puede usar esa información para distinguir entre tipos de contenido HTTP, códigos de estado y errores de tipo de medio. [47] En 2019, investigadores de TU Darmstadt demostraron que esta técnica podría usarse para realizar un ataque de desanonimización dirigido contra usuarios de servicios web populares como Dropbox , Google Docs y GitHub que permiten a los usuarios compartir contenido arbitrario entre sí. [48] [49]
Desde 2019, las capacidades de los eventos de error se han ampliado. En 2020, Janc et al. demostraron que al establecer el modo de redireccionamiento para una solicitud de búsqueda en manual, un sitio web podría filtrar información sobre si una URL específica es una redirección. [50] [42] Casi al mismo tiempo, Jon Masas y Luan Herrara demostraron que al abusar de los límites relacionados con las URL, un atacante podría desencadenar eventos de error que podrían usarse para filtrar información de redireccionamiento sobre las URL. [51] En 2021, Knittel et al. demostraron que los eventos de error que se generan mediante una verificación de integridad de subrecursos , un mecanismo que se utiliza para confirmar que un subrecurso que carga un sitio web no se ha modificado ni comprometido, también podrían usarse para adivinar el contenido sin procesar de una respuesta HTTP y filtrar la longitud del contenido de la respuesta. [52] [53]
Los ataques de sincronización de caché se basan en la capacidad de inferir aciertos y errores en cachés compartidos en la plataforma web. [54] Uno de los primeros casos de un ataque de sincronización de caché implicó la realización de una solicitud de origen cruzado a una página y luego la investigación de la existencia de los recursos cargados por la solicitud en el HTTP compartido y el caché DNS . El artículo que describe el ataque fue escrito por investigadores de la Universidad de Purdue en 2000 y describe la capacidad del ataque de filtrar una gran parte del historial de navegación de un usuario al verificar selectivamente si se han cargado recursos que son exclusivos de una página web. [55] [54] [56]
Este ataque se ha vuelto cada vez más sofisticado, permitiendo la filtración de otros tipos de información. En 2014, Jia et al. demostraron que este ataque podría geolocalizar a una persona midiendo el tiempo que tarda en cargarse el dominio localizado de un grupo de sitios web multinacionales. [54] [57] [58] En 2015, Van Goethem et al. demostraron que, utilizando la caché de aplicación recién introducida , un sitio web podría indicarle al navegador que ignore y anule cualquier directiva de almacenamiento en caché que envíe el sitio web víctima. El documento también demostró que un sitio web podría obtener información sobre el tamaño de la respuesta almacenada en caché cronometrando el acceso a la caché. [59] [60]
Los límites globales, también conocidos como ataques pool-party, no dependen directamente del estado de la aplicación web víctima. Esta fuga entre sitios fue descubierta por primera vez por Knittel et al. en 2020 y luego ampliada por Snyder et al. en 2023. [45] El ataque abusa de los sistemas operativos globales o las limitaciones de hardware para privar de recursos compartidos. [61] Los límites globales que podrían ser abusados incluyen la cantidad de conexiones de socket sin procesar que se pueden registrar y la cantidad de trabajadores de servicio que se pueden registrar. Un atacante puede inferir el estado del sitio web víctima realizando una actividad que active estos límites globales y comparando las diferencias en el comportamiento del navegador cuando se realiza la misma actividad sin que se cargue el sitio web víctima. [62] Dado que este tipo de ataques generalmente también requieren canales laterales de temporización , también se consideran ataques de temporización. [45]
En 2019, Gareth Heyes descubrió que al establecer el hash de la URL de un sitio web en un valor específico y, posteriormente, detectar si se produjo una pérdida de foco en la página web actual, un atacante podría determinar la presencia y la posición de los elementos en un sitio web víctima. [63] En 2020, Knittel et al. demostraron que un atacante podría filtrar si Cross-Origin-Opener-Policyse estableció o no un encabezado obteniendo una referencia al windowobjeto de un sitio web víctima mediante el encuadre del sitio web o creando una ventana emergente del sitio web víctima. Usando la misma técnica de obtención de referencias de ventana, un atacante también podría contar la cantidad de marcos que un sitio web víctima tuvo a través de la window.lengthpropiedad. [44] [64]
Si bien se siguen encontrando técnicas más nuevas, las técnicas más antiguas para realizar fugas entre sitios se han vuelto obsoletas debido a los cambios en las especificaciones del Consorcio World Wide Web (W3C) y las actualizaciones de los navegadores. En diciembre de 2020, Apple actualizó el mecanismo de Prevención de Seguimiento Inteligente (ITP) de su navegador Safari , lo que hizo que una variedad de técnicas de fuga entre sitios que los investigadores de Google habían descubierto fueran ineficaces. [65] [66] [67] De manera similar, la introducción generalizada de la partición de caché en todos los navegadores principales en 2020 ha reducido la potencia de los ataques de sincronización de caché. [68]
El ejemplo de una aplicación web basada en Python con una interfaz de punto final de búsqueda implementada utilizando la siguiente plantilla Jinja demuestra un escenario común de cómo podría ocurrir un ataque de fuga entre sitios. [36]
< html lang = "es" >< cuerpo >< h2 > Resultados de la búsqueda </ h2 > {% para resultado en resultados %} < div class = "resultado" > < img src = "//cdn.com/result-icon.png" /> {% resultado.descripción %} </div> {% fin para %}</ cuerpo ></html>Este código es una plantilla para mostrar los resultados de una búsqueda en una página web. Recorre una colección de resultados proporcionados por un servidor HTTP y muestra cada resultado junto con su descripción dentro de un elemento div estructurado junto con un icono cargado desde un sitio web diferente. La aplicación subyacente autentica al usuario en función de las cookies que se adjuntan a la solicitud y realiza una búsqueda textual de la información privada del usuario utilizando una cadena proporcionada en un parámetro GET. Para cada resultado devuelto, se muestra un icono que se carga desde una red de entrega de contenido (CDN) junto con el resultado. [32] [69]
Esta sencilla funcionalidad es vulnerable a un ataque de fuga cruzada, como lo muestra el siguiente fragmento de JavaScript . [32]
deje que icon_url = 'https://cdn.com/result-icon.png' ; iframe .src = 'https://service.com/?q=contraseña ' ; iframe .onload = async ( ) => { const inicio = rendimiento . ahora (); esperar búsqueda ( icon_url ); const duration = performance . now () - inicio ; si ( duración < 5 ) // recurso cargado desde caché console.log ( ' La consulta tuvo resultados' ) ; demás console.log ( 'No hay resultados para el parámetro de consulta ' ) ;};Este fragmento de código JavaScript, que puede incorporarse en una aplicación web controlada por el atacante, carga la aplicación web víctima dentro de un iframe, espera a que se cargue el documento y, posteriormente, solicita el icono a la CDN. El atacante puede determinar si el icono se almacenó en caché cronometrando su retorno. Debido a que el icono solo se almacenará en caché si y solo si la aplicación víctima devuelve al menos un resultado, el atacante puede determinar si la aplicación víctima devolvió algún resultado para la consulta dada. [36] [69] [26]
Antes de 2017, los sitios web podían defenderse de las fugas entre sitios garantizando que se devolviera la misma respuesta para todos los estados de la aplicación, lo que frustraba la capacidad del atacante de diferenciar las solicitudes. Este enfoque era inviable para cualquier sitio web no trivial. El segundo enfoque consistía en crear URL específicas de la sesión que no funcionaran fuera de la sesión de un usuario. Este enfoque limitaba el intercambio de enlaces y era poco práctico. [18] [70]
La mayoría de las defensas modernas son extensiones del protocolo HTTP que evitan cambios de estado, hacen que las solicitudes de origen cruzado no tengan estado o aíslan por completo los recursos compartidos entre múltiples orígenes. [68]
Uno de los primeros métodos para realizar fugas entre sitios fue el uso de la caché HTTP, un enfoque que se basaba en consultar la caché del navegador en busca de recursos únicos que el sitio web de una víctima pudiera haber cargado. Al medir el tiempo que tardaba una solicitud de origen cruzado en resolver un sitio web atacante, se podía determinar si el recurso estaba almacenado en caché y, de ser así, el estado de la aplicación víctima. [69] [72] A partir de octubre de 2020 [actualizar], la mayoría de los navegadores han implementado la partición de caché HTTP, lo que reduce drásticamente la eficacia de este enfoque. [73] La partición de caché HTTP funciona mediante la clave múltiple de cada solicitud almacenada en caché según el sitio web que solicitó el recurso. Esto significa que si un sitio web carga y almacena en caché un recurso, la solicitud almacenada en caché está vinculada a una clave única generada a partir de la URL del recurso y la del sitio web solicitante. Si otro sitio web intenta acceder al mismo recurso, la solicitud se tratará como un error de caché a menos que ese sitio web haya almacenado en caché previamente una solicitud idéntica. Esto evita que un sitio web atacante deduzca si un recurso ha sido almacenado en caché por un sitio web víctima. [74] [75] [76]
Otra característica más orientada al desarrollador que permite el aislamiento de contextos de ejecución incluye el Cross-Origin-Opener-Policyencabezado (COOP), que se agregó originalmente para abordar problemas de Spectre en el navegador. [77] [78] Ha demostrado ser útil para prevenir fugas entre sitios porque si el encabezado se configura con una same-origindirectiva como parte de la respuesta, el navegador no permitirá que los sitios web de origen cruzado puedan contener una referencia al sitio web defensor cuando se abre desde una página de terceros. [79] [80] [81]
Como parte de un esfuerzo por mitigar las fugas entre sitios, los desarrolladores de todos los navegadores principales han implementado particiones de almacenamiento, [82] lo que permite que todos los recursos compartidos utilizados por cada sitio web tengan múltiples claves, lo que reduce drásticamente la cantidad de técnicas de inclusión que pueden inferir los estados de una aplicación web. [83]
Los ataques de fugas entre sitios dependen de la capacidad de una página web maliciosa de recibir respuestas de origen cruzado de la aplicación víctima. Al impedir que la aplicación maliciosa pueda recibir respuestas de origen cruzado, el usuario ya no corre el riesgo de que se filtren los cambios de estado. [84] Este enfoque se observa en defensas como el X-Frame-Optionsencabezado obsoleto y la frame-ancestorsdirectiva más nueva en los encabezados de la Política de seguridad de contenido , que permiten a la aplicación víctima especificar qué sitios web pueden incluirlo como un marco integrado. [85] Si la aplicación víctima no permite la incrustación del sitio web en contextos no confiables, la aplicación maliciosa ya no puede observar la respuesta a las solicitudes de origen cruzado realizadas a la aplicación víctima mediante la técnica del marco integrado. [86] [87]
Un enfoque similar es adoptado por el mecanismo Cross-Origin Resource Blocking (CORB) y el encabezadoCross-Origin-Resource-Policy (CORP) , que permite que una solicitud de origen cruzado tenga éxito pero bloquea la carga del contenido en sitios web de terceros si hay una discrepancia entre el tipo de contenido que se esperaba y el que se recibió. [88] Esta característica se introdujo originalmente como parte de una serie de mitigaciones contra la vulnerabilidad Spectre [89] pero ha demostrado ser útil para prevenir fugas de origen cruzado porque impide que la página web maliciosa reciba la respuesta y, por lo tanto, infiera cambios de estado. [86] [90] [91]
Uno de los enfoques más eficaces para mitigar las fugas entre sitios ha sido el uso del SameSiteparámetro en cookies . Una vez establecido en Laxo Strict, este parámetro evita que el navegador envíe cookies en la mayoría de las solicitudes de terceros, lo que hace que la solicitud no tenga estado. [nota 5] [91] Sin embargo, la adopción de Same-Sitecookies ha sido lenta porque requiere cambios en la forma en que operan muchos servidores web especializados, como los proveedores de autenticación. [93] En 2020, los creadores del navegador Chrome anunciaron que activarían SameSite=Laxcomo estado predeterminado las cookies en todas las plataformas. [94] [95] A pesar de esto, todavía hay casos en los que SameSite=Laxno se respetan las cookies, como LAX+POSTla mitigación de Chrome, que permite que un sitio de origen cruzado use una SameSite=Laxcookie en una solicitud si y solo si la solicitud se envía mientras se navega por la página y ocurre dentro de los dos minutos posteriores a la configuración de la cookie. [92] Esto ha dado lugar a omisiones y soluciones alternativas contra la SameSite=Laxlimitación que aún permiten que se produzcan fugas entre sitios. [96] [97]
Los encabezados de metadatos de obtención, que incluyen el encabezado Sec-Fetch-Site, Sec-Fetch-Modey , que proporcionan información sobre el dominio que inició la solicitud, detalles sobre el inicio de la solicitud y el destino de la solicitud respectivamente al servidor web defensor, también se han utilizado para mitigar los ataques de fugas entre sitios. Sec-Fetch-User[ 98] Estos encabezados permiten al servidor web distinguir entre solicitudes legítimas de terceros del mismo sitio y solicitudes dañinas de origen cruzado. Al discriminar entre estas solicitudes, el servidor puede enviar una respuesta sin estado a solicitudes maliciosas de terceros y una respuesta con estado a solicitudes rutinarias del mismo sitio. [99] Para evitar el uso abusivo de estos encabezados, una aplicación web no puede configurar estos encabezados, que solo deben ser configurados por el navegador. [100] [75]Sec-Fetch-Dest
Strictdirectiva garantiza que todas las solicitudes entre sitios no tengan estado, mientras que Laxpermite que el navegador envíe cookies para solicitudes que no cambian el estado (es decir, GETo HEAD) que se envían mientras se navega a una página diferente de la página de origen cruzado. [92]Los encabezados de solicitud HTTP Fetch Metadata [45] son un conjunto de encabezados HTTP que proporcionan el contexto de la solicitud HTTP al servidor. El servidor puede usar el contexto para determinar si la solicitud es maliciosa o debe permitirse.
Si bien las implementaciones recientes de navegadores [69, 113] abordan este problema mediante la partición de caché HTTP, esta solución da como resultado un mayor volumen de tráfico y tiempos de carga más altos, ya que los recursos almacenados en caché se vuelven a obtener si se solicitan en un contexto diferente.