Cross Domain Scripting

Présentation.

L'idée d'écrire cet article me vint après un pris pour donner le débutant un lien vers une explication claire et détaillée du terme. Grimpez sur les moteurs de recherche, je fus surpris de constater que cet article est assez difficile. Le terme n'a pas expliqué en général ou en deux mots et en anglais :) . Pendant ce temps dans Windows vulnérabilité de ce type se trouvent assez souvent, et ils sont plus sérieux! Par conséquent, dans cet article, je l'ai essayé autant que possible en détail et décrire clairement ce type d'attaque, en particulier l'exploitation de ce type de vulnérabilités et de défendre contre eux, donner des exemples précis. L'article a été écrit principalement, bien sûr, pour les débutants, mais nous espérons que sera quelque chose d'utile pour les lecteurs plus expérimentés.

Quel est le Cross Domain Scripting?

Initialement, Cross-Domain Scripting (CDS) a été liée à des lacunes dans le modèle de l'âne bien connu "» aka Internet Explorer (IE) sécurité. Cependant, étant donné que caractéristiques architecturales des navigateurs modernes ne sont pas très différents les uns des autres, les attaques de ce type sont actuellement soumis à presque tous les navigateurs Web connus. Néanmoins, il existe des différences entre la classe du programme conduit au fait que le plus souvent est trouvé CDS "brauzerozavisimym", à savoir, par exemple, fonctionne sur IE, mais ne fonctionne pas sur Opera, ou vice versa.
Au coeur du type de vulnérabilité de la CDS est la notion de "domaine". Dans ce contexte, la signification de ce concept est un peu différent de l'habituel. "Domaine" - est non seulement une adresse de site Web sur l'Internet, et même «la région de l'espace de l'Internet des noms hiérarchiques» - ce concept fait référence à une (limite de sécurité) certaine «sécurité des frontières», pour aller au-delà de ce qui est pas permis de scripts personnalisés.
Le modèle de sécurité basé sur un navigateur Web est le principe selon lequel les ressources des différents domaines (pages, scripts, etc.) ne peuvent en aucun cas interférer les uns avec les autres, à savoir, l'accès aux composants internes et des données à l'autre. Si cela était possible, alors, par exemple, le script sur la page d'accueil du jeune hacker Vassia pourrait obtenir l'accès à la boîte aux lettres de données sur Mail.Ru utilisateur non averti que Bob leurré à votre page. Ce serait amusant :) ! En outre, selon l'architecture et les concepts de la construction d'un navigateur moderne Windows, tout partage réseau sur le réseau local et un système de fichiers client privé est également un "domaine", et il est donc possible de faire appel des scripts de la même manière à toutes les ressources sur Internet! En fait, il est le système de fichiers local du client, et est souvent l'objet d'attaques inter-domaines.
Dans le même temps, l'interaction entre une ressource (pages et scripts) dans un domaine (et tous ses sous-domaines!) Concept de sécurité Microsoft est autorisé et ne se limite pas, en principe. Il est difficile de juger bon ou mauvais, mais qui est plus facile :) tout en élargissant surfer sur le web - c'est sûr.
Alors, quelle est la Croix-Domain Scripting? Dans le contexte de ce qui précède, ce terme peut être traduit comme - "cross-domain scripting», à savoir, "domaine de script Intersection frontières" - une violation de cette ligne de sécurité chère, la sortie qui donne accès aux données d'autres domaines, y compris le système de fichiers local du client. Une telle violation est le plus souvent accompagnée de la possibilité d'enregistrer et d'exécuter du code HTML et Java dans le contexte d'autres domaines, pour lire des données provenant d'autres domaines (par exemple, forme avec les mots de passe ou des fichiers sur le système client) et même exécuter des commandes arbitraires sur un ordinateur distant.
Souvent, le concept de «scripting cross-domain» confondu avec le terme «cross site scripting» (XSS). En effet, il est souvent que les symptômes de ces vulnérabilités sont très similaires - en particulier quand il y a une insertion Java code à la suite de la CDS dans le cadre d'un autre domaine. Cependant, malgré les similitudes, l'essence de ces vulnérabilités varie:
Tout d'abord, la zone d'action XSS par définition est limitée à un seul domaine. Bien que la CDS affecte généralement tous les domaines + système de fichiers client local.
Deuxièmement, la raison réside dans le script d'erreur de vulnérabilités XSS situé sur un serveur, et est habituellement le filtrage des données insuffisantes reçues de l'utilisateur. Source CDS vulnérabilités - logiciel client (et du système d'exploitation du navigateur), et il a généralement rien à voir avec les données utilisateur.
Et il ne faut pas oublier que le niveau de danger de l'opération réussie de malveillant XSS bien inférieur à celui des CDS. En effet, dans le premier cas, comme un maximum, il y aura des fuites de données confidentielles de l'utilisateur (mots de passe, etc.), et seulement d'un site, tandis que la CDS peut voler des données confidentielles de tous les sites, et souvent l'exécution de commandes arbitraires sur le système client, il vous permet de prendre le contrôle complet.

Comment ça marche?

Alors pourquoi il est possible de ce type d'attaque? La raison en est que la même "ligne de sécurité" entre les domaines créés artificiellement, que le travail pour éviter cross-site scripting exécute un navigateur Web et de ses composants - pas de limites architecturales. Donc, il y a toujours un risque d'erreur dans les procédures de test, la capacité d'obtenir autour d'eux, que maintenant fait avec succès.
Pour l'histoire de plus de dix ans d'utilisation des navigateurs Web sont de nombreuses façons ont été trouvés pour surmonter la frontière de domaine convoité. Cependant, la plupart d'entre eux peuvent être divisés en deux catégories:
erreurs de sécurité 1.Ekspluatatsiya dans le modèle des navigateurs orienté objet;
2. Utilisez un intermédiaire pour effectuer l'attaque.
Considérons les classes de données d'attaques.
La première est basée sur une architecture orientée objet prononcé des navigateurs modernes et machine virtuelle Java. En effet, tout ce que nous voyons sur l'écran du navigateur Web sont des objets de certaines classes avec leurs propriétés, événements et méthodes. En utilisant le modèle orienté objet et les scripts Java, nous pouvons nous référer à tout élément dans une page chargée navigateur pour lire et écrire des données en elle, ouvrir de nouvelles fenêtres, etc. En outre, avec l'aide de scripts possibles éléments partiels de contrôle de votre navigateur web et même les actions de l'utilisateur: Move "Forward" / "Retour" sur la page, ajouter dans les "Favoris", etc.
Cependant, les éléments individuels d'une fenêtre ou d'une page dans un navigateur Web peuvent appartenir à des domaines différents, et ont donc besoin d'empêcher l'accès. Nous ne pouvons pas permettre à un script personnalisé par l'ouverture d'un nouveau domaine dans une nouvelle fenêtre de navigateur, était capable d'écrire quoi que ce soit ou de lire à partir de là. Nous ne pouvons pas permettre à un script sur une page avec un cadre, qui chercher une ressource d'un autre domaine pourrait accéder à ce cadre et avoir accès à ses données. De plus, les fuites de données d'un domaine à un autre est possible non seulement par les propriétés, mais aussi grâce à des méthodes et des événements installations! Disons que le script sur la page de la jeune hacker Vassia, où il a attiré l'utilisateur non averti n'a pas à "savoir" quelles touches il appuie quand entrer un mot de passe pour vous connecter avec Mail.Ru, ouvert dans une autre fenêtre du navigateur. Et ces exemples sont très!
Malheureusement, ou heureusement;) ces contrôles de sécurité sont souvent réalisées de manière incorrecte, et parfois inexistante! Par conséquent, il devient possible d'accéder aux éléments des pages d'autres domaines, pour lire les données d'eux, écrivez votre code Java dans le contexte d'autres domaines, etc. Grâce à l'architecture assez complexe d'un modèle orienté objet de tels «trous» dans celui-ci sont très fréquentes. Voici un exemple de ce type d'attaques (exemple 1).
Pour effectuer la deuxième classe d'attaques à l'aide de certains intermédiaires. Que faire quand un appel direct vers un autre domaine est interdite? C'est vrai! Faites le tour! Que faire s'il y a quelqu'un d'aller quelque chose qui est pas interdit de la circulation et à partir de là on peut considérer les données et envoyez-nous, ou vice versa - pour enregistrer nos résultats dans le contexte d'un autre domaine. Les plus vulnérables de ce point de vue est la technologie ActiveX de Microsoft. La technologie ActiveX permet à l'utilisateur avec des objets, leurs propriétés et les méthodes qui sont utilisées par le système d'exploitation à des fins auxiliaires. Par exemple, pour afficher un navigateur Web dans les fichiers d'aide Windows (* .chm) utilise le composant ActiveX HTML Help. Est-ce pas pratique? Cependant, les objets ActiveX servent souvent comme une sorte de "chevaux de Troie"! Le fait qu'il y ait un moyen de gérer ces composants (téléchargement, accéder à leurs propriétés et méthodes) via la page web. Ceci est fait en utilisant la balise. Mais souvent, ces objets ActiveX comprennent des procédés de manipulation avec le système de fichiers, lancer des applications, des pages Web, la navigation, etc. ainsi il est possible de produire la totalité de ces actions extérieures et mettre en œuvre une communication complète avec la victime de plus! Par exemple, lire le contenu des fichiers locaux du client et de renvoyer les données vers le script, ou en utilisant un objet ActiveX pour ouvrir un domaine différent, et de l'écrire dans le contexte de votre code Java. Il est par cette classe d'attaque est parfois possible d'obtenir l'exécution de code arbitraire (cmd.exe exécuter avec les paramètres nécessaires) sur le système client. À l'heure actuelle, ce type de CDS est également largement parlé et trouver constamment de nouveaux objets ActiveX vulnérables. Voici un exemple d'une vulnérabilité (exemple 2).
Aussi discuté classe de la CDS, il existe d'autres façons de contourner les restrictions inter-domaines. Cependant, ces méthodes sont souvent plutôt exotique et se produisent rarement. Par exemple, détecté en Juillet 2004. Cross-Cookie vulnérabilité (http://www.westpoint.ltd.uk/advisories/wp-04-0001.txt). Il vous permet d'accéder (lecture / écriture) pour les cookies d'autres domaines sous certaines conditions. Et ce fut l'un des rares cas où vulnérables étaient nombreux navigateurs: IE, Mozilla, Opera, Konqueror.
ainsi La CDS est maintenant un type très courant d'attaque et constamment trouvé de nouvelles façons d'exploiter ces vulnérabilités ( "vecteurs d'attaque»).

Des exemples de CDS

Pour tout ce qui précède ont été compréhensible - regarder quelques exemples de CDS vulnérabilités réelles. Chacun d'entre eux ont été trouvés dans Internet Explorer et vous permettent d'insérer votre code Java dans le contexte d'autres domaines. Habituellement, il est utilisé pour voler les cookies ou l'exécution de l'action arbitraire dans la session de l'utilisateur actuel.

Exemple 1. Méthode similaire Nom Redirection vulnérabilité inter - domaines - CAN-2004-0727 (MS04-038)

Cette vulnérabilité a été découverte en Juillet 2004, et le bug lié à la sécurité dans IE modèle orienté objet (1ère classe des vulnérabilités de CDS discutées ci-dessus).
Son essence est la suivante. Il est connu pour charger dans la fenêtre du navigateur une autre page (peut-être d'un autre domaine), vous pouvez utiliser la méthode ou la propriété location.href location.assign (). Cependant, après le chargement de la page demandée poursuite de l'exécution du code de script Java cela ne peut pas être - ou le script pourrait Mail.Ru pour charger et exécuter dans le cadre de ce domaine est arbitraire. Cependant, il était possible de contourner cette restriction par une méthode de redirection (redirection) location.assign () exactement le même, mais l'autre fenêtre (après tout, nous avons un modèle orienté objet et nous pouvons attribuer les méthodes d'objets différents les uns des autres). En conséquence, la possibilité d'exécuter du code Java dans le contexte de la fenêtre en cours, mais après le chargement de la page souhaitée - au besoin! Le script suivant exécute l'action requise:


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


Tout d'abord, une nouvelle fenêtre apparaît, qui est dans la boucle d'attente pour la page de téléchargement (dans ce cas localhost) à la fenêtre principale (en cours). Pendant ce temps, le script réaffecte méthodes location.assign () et commence le chargement de la fenêtre principale de la page souhaitée (localhost). Une fois le téléchargement se termine dans une boucle de la nouvelle fenêtre est activée déclencheur, la méthode assign () code Java est inséré (en raison de l'insertion se produit des méthodes remappage dans le contexte de la fenêtre principale) et la nouvelle fenêtre est immédiatement fermée. En tant que résultat du script est exécuté dans le contexte de la machine locale document.cookie.
Apparemment, Microsoft n'a pas fourni la possibilité de rediriger les fonctions et les contrôles de sécurité ne sont pas insérés (ou inséré à tort) à cet événement. Pour l'exploitation de cette vulnérabilité nécessite que le navigateur a été activé Active scripting. En savoir plus sur cette vulnérabilité et de trouver un exemple de travail, vous pouvez exploiter ici: http://greyhatsecurity.org/similarmethodnameredir-discussion.htm.

Exemple 2. DHTML Editing Component Cross contrôle ActiveX domaine vulnérabilité CAN-2004-1319 (MS05-013)

Cette vulnérabilité a été découverte à la fin de l'année dernière, mais est fixé seulement en Février. Il se réfère au second type de CDS d'attaque discutés ci-dessus, à savoir, Il utilise un intermédiaire (DHTML ActiveX) pour mener à bien l'attaque. L'exploitation requiert que vous devez effectuer les étapes suivantes:
1. Insérez le DHTML ActiveX. Ceci est fait en utilisant la balise.




2.Zagruzit dans l'objet ActiveX que vous souhaitez nous page (domaine personnalisé). Ceci est réalisé par l'exécution dans le cadre de notre script DHTML ActiveX.

exploit.DOM.Ssript.execSsript ( "window.name =" new "; open (" http: // localhost "," nouveau ");");

3.Well et après que vous pouvez insérer notre code HTML et Java. Il sera mis en œuvre dans le cadre du domaine chargé. Il est simple à la laideur :) !

exploit.DOM.Ssript.execSsript ( "alert (document.cookie)");

Quelles sont les causes de cette vulnérabilité? Je choisirais deux d'entre eux:
Tout d'abord, la possibilité d'exécuter des scripts externes arbitraires dans l'objet ActiveX - à mon avis, il est trop de liberté!
Deuxièmement, quand la page se charge du DHTML ActiveX pour charger tout - même les cookies! Question: Pourquoi? Ce contrôle ActiveX peut être utilisé pour modifier des pages, et pourquoi il est besoin des cookies - on ne sait pas ...
Naturellement, pour l'exploitation de cette vulnérabilité nécessite que la mise en œuvre de ActiveX a été activé dans votre navigateur. En savoir plus sur cette vulnérabilité et de trouver un exemple de travail, vous pouvez exploiter ici: http://greyhatsecurity.org/abusiveparent-discussion.htm.

Comment se protéger?

Protéger contre cross-site scripting est pas si simple. parce que Options d'exploitation ( "vecteurs d'attaque»), ces vulnérabilités sont très diverses, la plupart de l'action sera très limitée et temporaire. Couper tous les "vecteurs d'attaque" est presque impossible. Donc, je vais vous donner quelques lignes directrices qui ne peut réduire le risque d'une attaque réussie, mais ne protège pas complètement.
prudence 1.Soblyudenie lorsque vous surfez sur le web.
Pour la mise en œuvre réussie de presque toutes les variétés de la CDS doit d'abord inciter l'utilisateur sans méfiance à une page, l'exploit, et alors il serait soumis à cette attaque. Vous ne pouvez pas faire confiance à des liens, comme par hasard, jeter dans une conversation, différentes "pages d'accueil", etc. Ceci est probablement la principale recommandation de tous. Malheureusement correctement appliqué XSS peut effacer toute la prudence.
2.Operativnaya installer des correctifs pour votre système d'exploitation et le navigateur.
Habituellement, toutes les vulnérabilités publiées sur le fabricant Internet (même Microsoft :) ) Dans un court laps de temps produit un correctif (patch). Il permettra de protéger contre cette vulnérabilité particulière, mais pas sur l'autre, n'a pas naydennyhJ (ou trouvé, mais n'a pas rendre public). Bien entendu, les exemples présentés dans la vulnérabilité a longtemps corrigé le Microsoft, et qui voulait, il avait déjà pris soin de leur sécurité.
3.Otklyuchenie dans le navigateur ActiveX et Active Scripting.
Cette mesure rendrait impossible à exécuter dans le ActiveX Brother et exécuter Java et scripts VBS. Il va vraiment faire la majorité des CDS attaques inefficaces, la vérité peut affecter sensiblement la fonctionnalité des sites visités. Cependant, tous les CDS pour une attaque réussie nécessite le soutien de ActiveX navigateur ou Active Scripting - et ce ne sont pas une panacée pour tous les maux!
4.Rabota Internet avec des droits limités seulement.
La mise en œuvre de cette recommandation, même dans le cas d'une attaque réussie, afin de réduire les dommages potentiels de celle-ci. Comme cela est bien connu navigateur (et donc tous les scripts en elle) est exécuté avec les droits de l'utilisateur actuel. Ne laissez pas un pirate Vassia obtenir cmd.exe avec des droits d'administrateur :) !
Suite à ces directives aidera tous trudnouyazvimym devenir pour Cross-Domain Scripting!