Qu'est-ce que L'Inclusion de Script Cross Site (XSSI)?
J'ai récemment vu XSSI mentionné sur plusieurs pages, par exemple Web Application Exploits and Defenses :
Les navigateurs empêchent les pages d'un domaine de lire des pages dans d'autres domaines. Mais ils n'empêchent pas les pages d'un domaine du référencement des ressources dans d'autres domaines. En particulier, ces images permettent d'être rendu à partir d'autres domaines et les scripts à exécuter à partir d'autres domaines. Un script inclus n'a pas son propre contexte de sécurité. Il fonctionne dans la sécurité contexte de la page qui l'incluait. Par exemple, si www.evil.example.com inclut un script hébergé sur www.google.com ensuite, ce script s'exécute dans le contexte maléfique et non dans le contexte google. Donc, toutes les données de l'utilisateur dans ce script vont "fuir."
Je ne vois pas quel genre de problèmes de sécurité cela crée dans la pratique. Je comprends XSS et XSRF mais XSSI est un peu mystérieux pour moi.
Quelqu'un peut-il esquisser un exploit basé sur XSSI?
Merci
3 réponses
Ceci est généralement un problème si vous utilisez JSONP pour transférer des données. Considérons un site web composé d'un domaine A qui charge les données du domaine B. L'utilisateur doit être authentifié sur les sites A et B, et parce que la même Politique d'origine empêche les navigateurs plus anciens de communiquer directement avec un domaine différent (B) que la page actuelle (A), les développeurs ont décidé d'utiliser JSONP. Ainsi, le site a inclut un script pointant vers http://B/userdata.js, qui est quelque chose comme:
displayMySecretData({"secret":"this is very secret", ...})
Donc Un définit une fonction appelée displayMySecretData, et lorsque le script inclus du serveur B s'exécute, il appelle cette fonction et affiche les données secrètes à l'utilisateur.
Maintenant, le serveur maléfique e arrive. Il voit que A inclut des données de B en utilisant JSONP. Ainsi, le serveur e inclut le même script, mais définit son propre displayMySecretData qui vole à la place les données. L'attaquant trompe alors l'utilisateur en visitant son site. Lorsque l'utilisateur y va et qu'il est connecté à B, le navigateur envoie automatiquement les cookies d'authentification pour B avec la demande à fecth le script de B. B voit un utilisateur authentifié, et renvoie donc le script comme prévu. E obtient les données, et presto...
L'utilisation de JSONP pour charger des données confidentielles d'un domaine différent de cette façon est donc vraiment non sécurisée, mais les gens l'utilisent toujours. Mauvaise idée.
XSSI n'est pas limité aux réponses jsonp. Dans certains navigateurs, vous pouvez remplacer le constructeur de tableau. Si une réponse JSON contient [...] et que vous l'incluez en tant que script, elle exécutera le nouveau constructeur au lieu de celui intégré. Le correctif consiste à insérer quelque chose dans la réponse qui ne peut pas être analysé comme ])}while(1);</x>, puis à utiliser du code pour le supprimer avant de l'analyser. Un attaquant ne peut pas faire cela puisque l'inclusion de script est toujours le script entier.
Plus de détails sur le problème et cette solution à http://google-gruyere.appspot.com/part3#3__cross_site_script_inclusion
XSSI est une façon fantaisiste de dire: vous incluez dans votre programme, quelqu'un d'autre code; vous n'avez aucun contrôle sur ce qui est dans ce code, et vous n'avez aucun contrôle sur la sécurité du serveur sur lequel il est hébergé.
Par exemple, disons que j'inclus dans ma page html
<script type="text/javascript" src="http://mymatedave.com/js/coolwidget.js"></script>
Ce script s'exécutera dans ma webapp avec le même niveau de confiance que n'importe quel de mon propre code javascript. Il aura accès au contenu de la page complète et DOM, il sera en mesure de lire tous mes les cookies de l'application et lire les utilisateurs touches et les mouvements de la souris, et tout ce que javascript peut faire.
Si mon compagnon dave, décide alors de mettre quelque chose de malveillant dans son widget cool (disons, un sniffer/keylogger qui envoie tous les cookies de l'utilisateur, les données de formulaire et les touches à son serveur) alors je ne le saurai pas nécessairement. Aussi, la sécurité de mon application dépend de la sécurité de dave serveur. Si le serveur de dave est compromis et coolwidget.js est remplacé par l'attaquant, Je ne le ferai plus nécessairement savoir et le code malveillant fonctionnera dans le cadre de mon application.