This page has been robot translated, sorry for typos if any. Original content here.

Script interdomaine

Introduction

L'idée d'écrire cet article m'est venue après qu'il était nécessaire de donner à un nouveau venu un lien vers une explication détaillée et compréhensible de ce terme. En grimpant sur les moteurs de recherche, j'ai été surpris de constater qu'il est assez difficile de trouver un tel article. Le terme n'est pas expliqué du tout, ou en deux mots et en anglais :) . Pendant ce temps, dans Windows, ce type de vulnérabilité se retrouve assez souvent et ils sont plus que sérieux! C'est pourquoi, dans cet article, j'ai essayé de décrire ce type d'attaques, les caractéristiques spécifiques de l'exploitation de ce type de vulnérabilités et la protection contre celles-ci, afin de donner des exemples spécifiques aussi complets et clairs que possible. Bien entendu, cet article a été principalement conçu pour les débutants, mais j'espère que ce sera utile pour des lecteurs plus expérimentés.

Qu'est-ce qu'un script interdomaine?

Au départ, le script interdomaine (CDS) était associé à des failles dans le modèle de sécurité du célèbre «âne», également appelé Internet Explorer (IE). Cependant, depuis Comme les caractéristiques architecturales des navigateurs modernes ne sont pas très différentes les unes des autres, presque tous les navigateurs Web connus font actuellement l'objet d'attaques de ce type. Cependant, les différences existantes entre les programmes de cette classe font que CDS le plus souvent trouvé est "dépendant du navigateur", c’est-à-dire qu'il fonctionne sous IE, mais ne fonctionne pas sur Opera ou inversement.
Les vulnérabilités telles que CDS reposent sur la notion de «domaine». Dans ce contexte, la signification de ce concept est quelque peu différente de celle généralement acceptée. Un «domaine» n'est plus simplement une adresse de site Web, et même pas «une zone de l'espace de noms hiérarchique d'Internet». Ce concept signifie une certaine «frontière de sécurité» au-delà de laquelle aucun script utilisateur n'est autorisé.
Le modèle de sécurité de tout navigateur Web repose sur le principe que les ressources de différents domaines (pages, scripts, etc.) ne peuvent en aucun cas se chevaucher, c.-à-d. avoir accès au contenu interne et aux données les uns des autres. Si cela était possible, par exemple, un script figurant sur la page d'accueil d'un jeune pirate informatique, Vasya, pourrait accéder aux données de la boîte aux lettres Mail.Ru d'un utilisateur peu méfiant, que Vasya a attiré sur sa page. Ce serait amusant :) ! En outre, selon l’architecture Windows et le concept de construction de navigateurs modernes, toute ressource réseau du réseau local et le système de fichiers du client sont également des «domaines», ce qui signifie qu’ils peuvent être accessibles à partir de scripts comme toute autre ressource sur Internet! En réalité, c'est le système de fichiers local du client qui est le plus souvent la cible d'attaques interdomaines.
En même temps, l’interaction entre les ressources (pages et scripts) du domaine (et tous ses sous-domaines!) Entre le concept de sécurité Microsoft est autorisée et n’est en principe pas limitée. Il est difficile de juger si c'est correct ou non, mais qu'est-ce qui est plus facile? :) et tout en élargissant les possibilités de navigation sur le Web, c’est certain.
Alors, quel est le script interdomaine? Dans le contexte de ce qui précède, ce terme peut être traduit par «script interdomaine», c.-à-d. «Les scripts traversant les limites de domaine» constituent une violation de la précieuse ligne de sécurité, qui permet d'accéder aux données d'autres domaines, y compris le système de fichiers local du client. Une telle violation s’accompagne le plus souvent de la possibilité d’enregistrer et d’exécuter du code HTML et Java arbitraire dans le contexte d’autres domaines, de lire des données d’autres domaines (par exemple, des formulaires avec des mots de passe ou des fichiers sur le système du client) et même d’exécuter des commandes arbitraires sur un ordinateur distant.
Le concept de "script interdomaine" est souvent remplacé par le concept de "script intersite" (XSS). En effet, il est fréquent que les manifestations externes de ces vulnérabilités soient très similaires, en particulier lorsque le résultat de CDS est l’insertion de code Java dans le contexte d’un autre domaine. Cependant, malgré les similitudes, l’essence de ces vulnérabilités est différente:
Premièrement, la portée de XSS est par définition limitée à un domaine. Alors que CDS est généralement soumis à tous les domaines + système de fichiers client local.
Deuxièmement, la cause des vulnérabilités XSS réside dans les erreurs des scripts situés sur le serveur et, en règle générale, dans le filtrage insuffisant des données reçues de l'utilisateur. Le logiciel client (navigateur et système d'exploitation) est la source des vulnérabilités de CDS. Il n'a généralement rien à voir avec les données utilisateur.
Nous ne devons pas oublier que le niveau de danger d’une opération réussie par un attaquant de systèmes XSS est bien inférieur à celui de CDS. En effet, dans le premier cas, au maximum, les données confidentielles de l’utilisateur (mots de passe, etc.) seront divulguées, mais seulement d’un site, tandis que les données confidentielles peuvent être volées sur n’importe quel site, et souvent l’exécution de commandes arbitraires sur le système du client, qui vous permet de prendre le contrôle total sur elle.

Comment ça marche?

Alors pourquoi ce type d'attaque devient-il possible? La raison en est que la très «ligne de sécurité» entre les domaines est créée artificiellement, que le navigateur Web et ses composants effectuent tout le travail nécessaire à la prévention des scripts entre domaines. Aucune restriction architecturale n'est imposée. Donc, il y a toujours le risque d'erreur dans les procédures de vérification, la possibilité de les contourner, ce qui se fait avec succès maintenant.
Pendant plus de dix ans d’utilisation des navigateurs Web, de nombreuses méthodes ont été trouvées pour dépasser les limites du domaine chéri. Cependant, la plupart d'entre eux peuvent être divisés en deux classes:
1. Erreurs de sécurité dans le modèle de navigateur orienté objet;
2. Utiliser un lien intermédiaire pour exécuter une attaque.
Examinons ces classes d’attaques plus en détail.
Le premier est basé sur une architecture orientée objet prononcée de navigateurs modernes et une machine virtuelle Java. En effet, tout ce que nous voyons sur l’écran du navigateur Web correspond aux objets de certaines classes avec leurs propriétés, événements et méthodes. En utilisant ce modèle orienté objet et les scripts Java, nous pouvons accéder à n’importe quel élément de la page chargé dans le navigateur, y lire et écrire des données, ouvrir de nouvelles fenêtres, etc. De plus, en utilisant des scripts, il est possible de contrôler partiellement les éléments du navigateur Web lui-même et même les actions de l'utilisateur: déplacer «Suivant» / «Précédent» dans les pages, ajouter des «Favoris», etc.
Toutefois, des fenêtres ou des éléments de page individuels dans un navigateur Web peuvent appartenir à différents domaines, ce qui signifie qu’il est nécessaire d’arrêter leur accès. Nous ne pouvons pas permettre au script utilisateur, ouvrant un autre domaine dans une nouvelle fenêtre de navigateur, d’avoir l’occasion d’écrire quelque chose ou de lire à partir de là. Nous ne pouvons pas autoriser le script sur la page avec le cadre dans lequel la ressource d'un autre domaine est chargée, pour pouvoir accéder à ce cadre et obtenir l'accès à ses données. De plus, la fuite de données d'un domaine à un autre est possible non seulement à travers des propriétés, mais également à travers des méthodes et des événements d'objets! Supposons que le script sur la page du jeune pirate informatique Vasya, où il a attiré l'utilisateur sans méfiance, ne devrait pas «savoir» sur quelles touches il a appuyé lorsqu'il a saisi le mot de passe pour accéder à Mail.Ru, ouvert dans une autre fenêtre du navigateur. Eh bien, il y a beaucoup d'exemples de ce genre!
Malheureusement, et peut-être heureusement;), ces contrôles de sécurité sont souvent effectués de manière incorrecte, et parfois ils sont complètement absents! Par conséquent, il devient possible d'accéder aux éléments de page d'autres domaines, de lire leurs données, d'écrire votre code Java dans le contexte d'autres domaines, etc. En raison de l'architecture assez complexe du modèle orienté objet, de tels «trous» s'y trouvent assez souvent. Vous trouverez ci-dessous un exemple de cette classe d’attaques (exemple 1).
Pour effectuer des attaques de deuxième classe, un intermédiaire est utilisé. Que faire lorsque l'accès direct à un autre domaine est interdit? Droit Faire le tour! Et tout à coup, il y a quelqu'un qui va quelque chose à qui cet appel n'est pas interdit, et il sera capable de lire des données à partir de là et de nous les transférer, ou vice-versa - pour écrire nos données dans le contexte d'un autre domaine. Le plus vulnérable de ce point de vue est la technologie ActiveX de Microsoft. La technologie ActiveX met à la disposition des utilisateurs les objets, leurs propriétés et les méthodes utilisées par le système d'exploitation à des fins auxiliaires. Par exemple, pour afficher les fichiers d’aide Windows (* .chm) via un navigateur Web, utilisez le composant ActiveX HTML Help. N'est-ce pas pratique? Cependant, les objets ActiveX agissent souvent comme une sorte de chevaux de Troie! Le fait est qu’il existe un moyen de gérer ces composants (téléchargement, accès à leurs propriétés et méthodes) via une page Web. Pour ce faire, utilisez la balise. Mais souvent, ces objets ActiveX contiennent des méthodes pour manipuler le système de fichiers, lancer des applications, naviguer dans des pages Web, etc. Donc il existe une opportunité extérieure pour effectuer toutes ces actions et, en outre, pour réaliser un échange complet de données avec la victime! Par exemple, lisez le contenu des fichiers du client local et renvoyez ces données au script ou utilisez un objet ActiveX pour ouvrir un autre domaine et écrire son code Java dans son contexte. C’est avec cette classe d’attaques qu’il est parfois possible d’exécuter du code arbitraire (exécuter cmd.exe avec les paramètres nécessaires) sur le système du client. Actuellement, ce type de CDS est également répandu et recherche constamment de nouveaux objets ActiveX vulnérables. Voici un exemple d'une telle vulnérabilité (Exemple 2).
Outre les classes CDS considérées, il existe d'autres moyens de contourner les restrictions interdomaines. Cependant, ces méthodes sont souvent très exotiques et peu fréquentes. Par exemple, la vulnérabilité Cross-Cookie découverte en juillet 2004 (http://www.westpoint.ltd.uk/advisories/wp-04-0001.txt). Il permettait, sous certaines conditions, d'accéder (en lecture / écriture) aux cookies d'autres domaines. Et c'était l'un des rares cas où de nombreux navigateurs étaient vulnérables: IE, Mozilla, Opera, Konqueror.
Donc CDS est actuellement un type d'attaque très courant et de nouvelles façons d'exploiter ces vulnérabilités («vecteur d'attaque») sont constamment découvertes.

Exemples de CDS

Pour clarifier tout ce qui est décrit ci-dessus, prenons quelques exemples de vulnérabilités réelles de CDS. Tous ont été trouvés dans Internet Explorer et vous permettent d'insérer votre code Java dans le contexte d'autres domaines. Ceci est généralement utilisé pour voler des cookies ou effectuer des actions arbitraires au cours de la session utilisateur en cours.

Exemple 1. Vulnérabilité entre domaines liés à la redirection de nom de méthode similaire - CAN-2004-0727 (MS04-038)

Cette vulnérabilité a été découverte en juillet 2004 et est liée à un bogue de sécurité dans le modèle orienté objet de IE (vulnérabilités CDS de 1ère classe décrites ci-dessus).
Son essence est la suivante. Comme vous le savez, pour charger une autre page dans la fenêtre du navigateur en cours (éventuellement à partir d'un autre domaine), vous pouvez utiliser la propriété location.href ou la méthode location.assign (). Toutefois, après le chargement de la page requise, il est impossible d'exécuter le code Java du script actuel. Dans le cas contraire, le script pourrait charger Mail.Ru et effectuer des actions arbitraires dans le contexte de ce domaine. Cependant, il était possible de contourner cette restriction en redirigeant (redirigeant) la méthode location.assign () vers une fenêtre identique mais différente (après tout, nous avons un modèle orienté objet et nous pouvons affecter les méthodes de différents objets). En conséquence, il est devenu possible d'exécuter du code Java dans le contexte de la fenêtre en cours, mais après avoir chargé la page requise - comme requis! Le script suivant effectue les actions requises:


w = window.open ("javascript: setInterval (function () {try {x = opener.location.href;}} catch (e) {location.assign ('jvascript: alert (document.cookie)'); window.close ();}}, 100) ");
w.location.assign = location.assign;
location.href = "/ click? http: // localhost";


Tout d'abord, une nouvelle fenêtre s'ouvre qui attend que la page soit chargée (dans notre cas à partir de localhost) dans la fenêtre principale (actuelle). Dans l'intervalle, le script réaffecte les méthodes location.assign () et commence à charger la page requise (localhost) dans la fenêtre principale. Dès que le téléchargement est terminé, un déclencheur se déclenche dans la boucle de la nouvelle fenêtre, le code Java est inséré par la méthode assign () (en raison de la réaffectation des méthodes, l'insertion a lieu dans le contexte de la fenêtre principale) et la nouvelle fenêtre est immédiatement fermée. A la suite de l'exécution du script dans le contexte localhost, docking.cookie est exécuté.
Apparemment, les développeurs Microsoft n’avaient pas prévu la possibilité de rediriger des fonctions et n’avaient pas inséré de contrôle de sécurité (ou mal inséré) dans cet événement. Pour exploiter cette vulnérabilité, il est nécessaire que le script actif soit activé dans le navigateur. Vous pouvez en savoir plus sur cette vulnérabilité et trouver un exemple opérationnel d’exploitation ici: http://greyhatsecurity.org/similarmethodnameredered-discussion.htm.

Exemple 2. Vulnérabilité transversale dans plusieurs domaines du contrôle ActiveX du composant d'édition DHTML CAN-2004-1319 (MS05-013)

Cette vulnérabilité a été découverte à la fin de l’année dernière, mais elle n’a été corrigée qu’en février. Il fait référence au deuxième type d’attaques CDS parmi celles considérées ci-dessus, c’est-à-dire utilise intermédiaire (ActiveX DHTML) pour mener une attaque. Pour exploiter une vulnérabilité avec succès, la séquence d'actions suivante est nécessaire:
1.Téléchargez ActiveX DHTML. Ceci est fait en utilisant une balise.




2. Chargez dans l'objet ActiveX la page dont vous avez besoin (domaine arbitraire). Ceci est fait en exécutant notre script dans le contexte de DHTML ActiveX.

exploit.DOM.Sсript.execScript ("window.name =" new "; open (" http: // localhost "," new ");");

3. Après cela, vous pouvez déjà insérer notre code HTML et Java. Il sera exécuté dans le contexte du domaine chargé. Tout est simple à la laideur :) !

exploit.DOM.S Script.exec Script ("alert (document.cookie)");

Quelles sont les causes de cette vulnérabilité? Je choisirais deux d'entre eux:
Premièrement, la possibilité d'exécuter des scripts arbitraires de l'intérieur de l'objet ActiveX de l'extérieur - à mon avis, c'est trop de liberté!
Deuxièmement, lors du chargement d’une page dans DHTML ActiveX, TOUT est chargé ici, même des cookies! Question: pourquoi Cet objet ActiveX peut être utilisé pour éditer des pages et pourquoi les cookies sont nécessaires - ce n'est pas clair ...
Naturellement, pour exploiter cette vulnérabilité, il est nécessaire que le navigateur autorise l'exécution ActiveX. Vous pouvez en savoir plus sur cette vulnérabilité et trouver un exemple de travail exploit ici: http://greyhatsecurity.org/abusiveparent-discussion.htm.

Comment se protéger?

La protection contre les scripts interdomaines n'est pas si facile. Depuis les options d'exploitation («vecteur d'attaque») de ces vulnérabilités sont très diverses, la plupart des mesures seront très limitées et temporaires. Il est presque impossible de remplacer tous les «vecteurs d'attaque». Par conséquent, je vais donner quelques recommandations qui ne peuvent que réduire le risque d’une attaque réussie, mais ne pas protéger complètement.
1. Respect des précautions lors de la navigation sur le Web.
Pour mener à bien presque toutes les variétés de CDS, vous devez tout d’abord attirer l’utilisateur non méfiant sur la page d’exploitation, après quoi il subira cette attaque. Vous ne pouvez pas faire confiance aux liens, comme par hasard, jetés dans la conversation, diverses "pages d'accueil", etc. C'est probablement la principale recommandation de tous. Malheureusement, une application XSS bien appliquée peut éliminer toute prudence.
2. Installation opérationnelle des correctifs pour le système d'exploitation et le navigateur.
Habituellement, pour toutes les vulnérabilités publiées sur le fabricant Internet (même Microsoft :) ) dans un court laps de temps émet une correction (patch). Cela protégera contre cette vulnérabilité particulière, mais pas contre ceux qui n'ont pas encore été trouvés (ou trouvés, mais non publiés). Naturellement, les vulnérabilités décrites dans les exemples sont corrigées depuis longtemps par Microsoft, et celui qui le souhaite s’est déjà occupé de sa sécurité.
3. Désactivez ActiveX et Active Scripting dans le navigateur.
Cette mesure rend impossible l'exécution dans le navigateur ActiveX et l'exécution de scripts Java ou VBS. Cela rendra en réalité la plupart des attaques CDS inefficaces, bien que cela puisse affecter de manière significative la fonctionnalité des sites visités. Cependant, CDS n’a pas toujours besoin de l’assistance d’ActiveX ou du navigateur de script actif pour une attaque réussie - et ce n’est pas une panacée pour tous les maux!
4. Travailler sur Internet uniquement avec des droits limités.
La mise en œuvre de cette recommandation permettra, même dans le cas d’une attaque réussie, de réduire les dommages éventuels. Comme vous le savez, le navigateur (et donc tous les scripts qu'il contient) fonctionne avec les droits de l'utilisateur actuel. Ne laissez pas le pirate Vasya obtenir cmd.exe avec des droits d'administrateur :) !
En suivant toutes ces recommandations, il deviendra difficile d’atteindre les scripts inter-domaines!