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

Cross Domain Scripting

Einführung.

Die Idee, diesen Artikel zu schreiben kam mir, nachdem er eine nahm Neuling Link auf detaillierte und klare Erklärung des Begriffs zu geben. Klettern Sie auf der Suchmaschinen, ich war überrascht, dass so ein Artikel zu finden, ist schwierig genug. Begriff oder gar nicht, entweder in zwei Worten und in Englisch erklärt :) . Inzwischen ist Windows-Schwachstelle dieser Art recht häufig gefunden, und sie sind mehr als ernst! Deshalb habe ich in diesem Artikel haben, so viel wie möglich, mehr und mehr klar versucht, diese Art von Angriff zu beschreiben, insbesondere die Ausbeutung dieser Art von Schwachstellen und verteidigen gegen sie, konkrete Beispiele nennen. Der Artikel wurde in erster Linie geschrieben, natürlich, für Anfänger, aber hoffentlich etwas Nützliches für erfahrene Leser sein.

Was ist das Cross Domain Scripting?

Zunächst domänenübergreifenden Scripting (CDS) wurde auf Mängel im Sicherheitsmodell des bekannten „Esel» aka Internet Explorer (IE) verknüpft. Da jedoch architektonischen Besonderheiten von modernen Browsern voneinander unterscheiden sich nicht wesentlich, sind die Angriffe dieser Art derzeit Gegenstand fast allen bekannten Web-Browsern. Dennoch gibt es Unterschiede zwischen dieser Klasse von Programmen auf die Tatsache, dass die meisten oft gefunden CDS ist „brauzerozavisimym“, also zum Beispiel funktioniert auf IE, aber nicht auf Opera arbeiten, oder umgekehrt.
Im Herzen von CDS Art von Schwachstelle ist der Begriff der „Domäne“. In diesem Zusammenhang ist die Bedeutung dieses Konzepts etwas anders als die üblichen. „Domain“ - ist nicht nur eine Web-Adresse im Internet, und sogar „die Region des Raumes der Internet hierarchischen Namen“ - dieser Begriff bezieht sich auf bestimmte „Grenzsicherheit» (Sicherheitsgrenze), über die keine benutzerdefinierte Skripts erlaubt.
Das Modell der Sicherheit basierend auf einem beliebigen Web-Browser beruht auf dem Prinzip, dass die Ressourcen der verschiedenen Domänen (Seiten, Skripte, etc.) können nicht in irgendeiner Weise miteinander interferieren, dh Zugriff auf die inneren Inhalte und Daten zueinander. Wenn dies möglich wäre, dann, zum Beispiel, wird das Skript auf der Website des jungen Hacker Wasja könnte Zugriff auf die Daten Mailbox auf Mail.Ru ahnungslose Benutzer erhalten gelockt Bob auf Ihrer Seite. Das würde Spaß machen, :) ! Darüber hinaus sind nach der Windows-Architektur und Konzepte der einen modernen Browser bauen, Netzwerkfreigabe auf dem lokalen Netzwerk und private Client-Dateisystem ist auch eine „Domäne“, und daher ist es möglich, aus den Skripten in gleicher Weise ansprechen wie auf jede Ressource im Internet! Eigentlich ist es das lokale Dateisystem des Clients und ist oft der Zweck der Cross-Domain-Attacken.
Zur gleichen Zeit wird die Interaktion zwischen einer Ressource (Seiten und Skripten) innerhalb der Domäne (und alle ihre Subdomains!) Microsoft-Sicherheitskonzept ist erlaubt und wird grundsätzlich nicht beschränkt. Es ist schwierig zu beurteilen, ob es richtig ist oder nicht, aber die Tatsache, dass es einfacher :) während Web-Surfen erweitern - das ist sicher.
Also, was ist das Kreuz-Domain-Scripting? „Domänenübergreifende Scripting“, das heißt - Im Zusammenhang mit dem oben genannten, dieser Begriff kann übersetzt werden „Crossing Domänengrenzen Skript“ - eine Verletzung dieser gehegten Sicherheitslinie, deren Ausgang den Zugriff auf andere Bereiche der Daten gibt, einschließlich der lokalen Dateisystem des Clients. Eine solche Verletzung am häufigsten durch die Fähigkeit, im Zusammenhang mit anderen Domänen, beliebigen HTML- und Java-Code zur Aufzeichnung begleitet wird, und führen Sie Daten aus anderen Domänen zu lesen (zum Beispiel bildet mit Passwörtern oder Dateien auf dem Client-System) und sogar beliebige Befehle auf einem Remote-Computer auszuführen.
Oft wird der Begriff des «Cross-Domain-Scripting» verwechselt mit dem Begriff «Cross-Site-Scripting» (XSS). Tatsächlich ist es oft, dass die Symptome dieser Schwachstellen sehr ähnlich sind - vor allem, wenn es eine Java-Code Insertion als Folge des CDS im Zusammenhang mit einer anderen Domäne ist. Doch trotz der Ähnlichkeiten variiert die Essenz dieser Sicherheitsanfälligkeiten:
Erstens, eine Domäne der Bereich XSS Aktion definitionsgemäß begrenzt. Zu dieser Zeit, als die CDS in der Regel unterliegen alle Domänen + lokale Client-Dateisystem.
Zum anderen liegt der Grund liegt in XSS Verwundbarkeiten Fehler Skript auf einem Server befindet, und in der Regel in der unzureichenden Filtern von Daten von dem Benutzer empfangen. Quelle CDS Schwachstellen - Client-Software (Browser und Betriebssystem), und es hat in der Regel nichts mit Benutzerdaten zu tun.
Nun ja, nicht vergessen, dass die Gefährlichkeit des erfolgreichen Betriebes von bösartigen XSS viel niedriger als die der CDS. Tatsächlich im ersten Fall von maximal vertraulichen Benutzerdaten durchgesickert (Passwörter, etc.), und nur von einer Seite, während CDS vertrauliche Daten von Websites stehlen kann, und oft auch die Ausführung von beliebigem Code auf dem Client-System, es ermöglicht Ihnen die vollständige Kontrolle über das System zu übernehmen.

Wie funktioniert es?

Warum ist es für diese Art von Angriff möglich? Der Grund dafür ist, dass die gleiche „Sicherheitslinie“ zwischen den Domänen künstlich geschaffen, dass die Arbeit Cross-Site-Scripting zu verhindern, führt einen Web-Browser und seine Komponenten - keine architektonischen Einschränkungen. So gibt es immer eine Chance auf Fehler in Testverfahren, die Fähigkeit, um sie zu bekommen, das jetzt erfolgreich getan.
Geschichte von Web-Browsern Seit mehr als zehn Jahren nutzt eine Vielzahl von Möglichkeiten hat die begehrte Domain Grenze zu überwinden gefunden. die meisten von ihnen können jedoch in zwei Klassen eingeteilt werden:
1.Ekspluatatsiya Sicherheitslücken in einem objektorientierten Modell von Browsern;
2. Mit Hilfe eines Vermittlers einen Angriff auszuführen.
Lassen Sie uns die Daten Angriffsklassen berücksichtigen.
Die erste basiert auf einer ausgeprägten objektorientierte Architektur von modernen Browsern und Java Virtual Machine. Tatsächlich ist alles, was wir auf dem Web-Browser-Bildschirm zu sehen sind Objekte bestimmter Klassen mit ihren Eigenschaften, Ereignisse und Methoden. Mit Hilfe der objektorientierten Modell und Java-Scripts, können wir auf ein beliebiges Element in einer Seite geladen Browser beziehen sich zum Lesen und Schreiben von Daten in, öffnen neue Fenster, usw. Darüber hinaus mit Hilfe von Skripten in teilweise die Kontrolle der Elemente des Web-Browsers führen kann, und auch die Aktionen des Benutzers: move „Forward“ / „Zurück“ auf der Seite, fügen Sie in den „Favoriten“, usw.
Jedoch können einige Elemente eines Fensters oder einer Seite in einem Webbrowser zu verschiedenen Domänen gehören, und damit den Zugang zu ihnen verhindern müssen. Wir können kein Benutzerskript erlauben, eine neue Domäne in einem neuen Browser-Fenster zu öffnen, ich war in der Lage, etwas zu schreiben oder von dort zu lesen. Wir können nicht ein Skript auf einer Seite mit einem Rahmen ermöglichen, die eine Ressource von einer anderen Domäne holen an diesem Rahmen beziehen konnte und den Zugriff auf ihre Daten erhalten. Darüber hinaus sickerte die Daten von einer Domäne in einer anderen möglich ist, nicht nur durch die Eigenschaften, sondern auch durch die Methoden und Ereignisse Einrichtungen! Lassen Sie sich auf der Seite des jungen Hacker das Skript sagen Wasja, wo er den ahnungslose Benutzer gelockt nicht zu „weiß“ hat, welche Tasten er drückt, wenn ein Passwort einzugeben Fenster einloggen mit Mail.Ru, offen in einem anderen Browser. Nun, solche Beispiele sind sehr viel!
Leider oder vielleicht zum Glück;) solche Sicherheitskontrollen werden häufig falsch durchgeführt, und manchmal nicht existent! Daher wird es möglich, die Elemente der Seiten aus anderen Domänen zuzugreifen, zum Lesen von Daten von ihnen, schreiben Sie Ihren Java-Code im Kontext von anderen Domänen, usw. Aufgrund der recht komplexen Architektur eines objektorientierten Modells solcher „Löcher“ in es ist durchaus üblich. Im Folgenden finden Sie ein Beispiel für diese Klasse von Angriffen (Beispiel 1).
Um die zweite Klasse von Angriffen führen einige Zwischen verwenden. Was tun, wenn ein direkter Aufruf an einer anderen Domäne ist verboten? Das ist richtig! Zu gehen um! Was passiert, wenn es etwas, den jemand gehen, der nicht aus dem Verkehr verboten ist und von dort aus können sie die Daten und senden uns in Betracht gezogen werden, oder umgekehrt - unsere Erkenntnisse in Zusammenhang mit einer anderen Domäne aufzunehmen. Die schwächsten aus dieser Sicht stellt sich die ActiveX-Technologie von Microsoft. ActiveX-Technologie bietet den Benutzer Objekte, die Eigenschaften und Methoden, die durch das Betriebssystem für irgendwelche Hilfszwecke verwendet werden. Um zum Beispiel einen Web-Browser in Windows-Hilfedateien (* .chm) verwendet HTML Help ActiveX-Komponente zu betrachten, durch. Ist es nicht bequem? Oft aber handeln ActiveX-Objekte als eine Art „Trojanisches Pferd“! Die Tatsache, dass es einen Weg gibt, diese Komponenten (Upload, Zugriff auf ihre Eigenschaften und Methoden) über die Web-Seite zu verwalten. Um dies zu tun, verwenden Sie den Tag. Aber oft ist diese ActiveX-Objekte umfassen Methoden der Manipulation mit dem Dateisystem, Anwendungen starten, Web-Seite Navigation usw. so ist es möglich, alle diese externen Aktionen zu erzeugen und darüber hinaus eine vollständige Kommunikation mit dem Opfer durchzuführen! Zum Beispiel, lesen Sie die Inhalte des lokalen Dateien des Kunden und die Daten an das Skript zurückzuschicken, oder durch ein ActiveX-Objekt mit einer anderen Domäne zu öffnen und es im Zusammenhang mit Java-Code schreiben. Es ist durch diese Klasse von Angriffen manchmal möglich ist, die Ausführung von beliebigem Code (run cmd.exe mit den gewünschten Parametern) zu dem Client-System zu machen. Derzeit wird auch diese Art von CDS weit verbreitet und ständig neue verwundbar ActiveX-Objekte finden. Unten ist ein Beispiel für eine Schwachstelle (Beispiel 2).
Auch CDS Klassen betrachtet, gibt es andere Möglichkeiten, um die Cross-Domain-Beschränkungen zu umgehen. Doch oft sind diese Methoden sehr exotisch und ungewöhnlich. Zum Beispiel erfaßt im Juli 2004 Kreuz-Cookie-Verwundbarkeit (http://www.westpoint.ltd.uk/advisories/wp-04-0001.txt). Es ermöglicht Ihnen, in anderen Bereichen unter bestimmten Bedingungen (Lesen / Schreiben) auf die Cookies zuzugreifen. Und es war einer der wenigen Fälle, in denen verwundbar waren viele Browser: IE, Mozilla, Opera, Konqueror.
so CDS ist jetzt eine sehr häufige Art von Angriff und fand immer wieder neue Wege, um diese Schwachstellen ( „Angriffsvektoren“) zu nutzen.

Beispiele CDS

Um alle der oben genannten klar war - Blick auf ein paar Beispiele für reale CDS Verwundbarkeiten. Alle von ihnen wurden in den Internet Explorer und ermöglicht es Ihnen, Ihre Java-Code im Kontext von anderen Domänen einzufügen gefunden. Dies wird in der Regel zu stehlen Cookies oder willkürliche Aktion innerhalb der aktuellen Benutzersitzung verwendet.

Beispiel 1. ähnlicher Methodenname Redirection Cross Domain Vulnerability - CAN-2004-0727 (MS04-038)

Diese Schwachstelle wurde im Juli 2004 und die damit verbundene Sicherheitslücke im Internet Explorer objektorientierte Modellen (erste Klasse von CDS Anfälligkeiten oben erörtert) entdeckt.
Sein Wesen ist wie folgt. Es ist bekannt, eine andere Seite in das aktuelle Browserfenster laden (vielleicht von einer anderen Domain), können Sie die Eigenschaft oder location.href location.assign () -Methode verwenden. Nachdem jedoch die angeforderte Seite die weitere Ausführung von Java-Script-Code Laden das kann nicht sein - oder das Skript könnte die Mail.Ru und führen im Rahmen dieser Domäne beliebige Aktionen laden. Es war jedoch möglich, diese Beschränkung durch eine Umleitung (Redirect) Methode location.assign an genau die gleichen () zu umgehen, aber die anderen Fenstern (weil wir ein objektorientiertes Modell haben, und wir können die Verfahren zur Herstellung verschiedenen Objekte zueinander zuweisen). Als Folge die Möglichkeit, Java-Code im Kontext des aktuellen Fensters zu laufen, aber nach der erforderlichen Seite geladen - je nach Bedarf! Das folgende Skript führt die erforderliche Aktion:


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 = "/ klicken http: // localhost?";


Zunächst öffnet sich ein neues Fenster, das in der Schleife für die Download-Seite wartet (in diesem Fall localhost) in der Haupt (Strom) Fenster. Unterdessen ordnet das Skript Methoden location.assign () und startet das Hauptfenster der gewünschten Seite zu laden (localhost). Wenn der Download abgeschlossen ist, in dem Zyklus des neuen Fensters den Trigger aktiviert wird, fügt die assign () Methode Java-Code (wegen der Umleitungsmethoden des Einführens erfolgt im Zusammenhang mit dem Hauptfenster) und ein neues Fenster wird dann geschlossen. Als Ergebnis des Skripts wird im Kontext von localhost document.cookie ausgeführt.
Anscheinend hat Microsoft nicht macht es möglich, die Funktionen und Sicherheitskontrollen umleiten nicht einfügen (oder falsch eingelegt) bei. Für den Betrieb dieser Sicherheitsanfälligkeit erfordert, dass der Browser Active Scripting aktiviert wurde. Lesen Sie mehr über diese Schwachstelle und ein funktionierendes Beispiel finden Sie hier ausnutzen können: http://greyhatsecurity.org/similarmethodnameredir-discussion.htm.

Beispiel 2. DHTML Editing Component ActiveX Control Cross Domain Vulnerability CAN-2004-1319 (MS05-013)

Diese Sicherheitsanfälligkeit wurde Ende des vergangenen Jahres entdeckt, aber erst im Februar korrigiert. Es gehört zu dem zweiten Typ von Angriff CDS oben diskutiert, d.h. Es nutzt Zwischen (DHTML ActiveX) für den Angriff. Ein erfolgreicher Angriff setzt voraus, dass Sie die folgenden Schritte durchführen müssen:
1. Stellen Sie den DHTML ActiveX ein. Dies geschieht, um den Tag mit.




2.Zagruzit in ActiveX-Objekt, das Sie wollen, dass wir Seite (beliebige Domain). Dies wird durch die Durchführung im Rahmen unseres DHTML ActiveX Script.

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

3.Well und danach können Sie unsere HTML und Java-Code einzufügen. Es wird im Rahmen der geladenen Domäne implementiert werden. Es ist einfach zu Hässlichkeit :) !

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

Was sind die Ursachen für diese Sicherheitsanfälligkeit? Ich würde zwei von ihnen herausgreifen:
Erstens die Fähigkeit, beliebige externe Skripte in ActiveX-Objekt auszuführen - meiner Meinung nach, ist es zu viel Freiheit!
Zweitens, wenn die Seite geladen wird im DHTML-ActiveX, um alles zu laden - auch Cookies! Frage: Warum? Dieses ActiveX-Objekt kann verwendet werden, um Seiten zu bearbeiten und warum es notwendig Cookies - es ist nicht klar ...
Natürlich für den Betrieb dieser Sicherheitsanfälligkeit erfordert, dass die Implementierung von ActiveX ist in Ihrem Browser aktiviert ist. Lesen Sie mehr über diese Schwachstelle und ein funktionierendes Beispiel finden Sie hier ausnutzen können: http://greyhatsecurity.org/abusiveparent-discussion.htm.

So schützen Sie sich?

Schutz vor Cross-Site-Scripting ist nicht so einfach. da Bedienoptionen ( „Angriffsvektoren“) dieser Schwachstellen sind sehr vielfältig, die meisten Maßnahmen haben eine sehr begrenzte und zeitlich begrenzt. Absperren all „Angriffsvektoren“ ist fast unmöglich. Also werde ich ein paar Richtlinien geben, die nur das Risiko eines erfolgreichen Angriffs verringern, aber nicht vollständig schützen.
1.Soblyudenie Vorsicht beim Surfen im Web.
Für die erfolgreiche Umsetzung der fast alle Sorten von CDS zuerst die ahnungslosen Benutzern auf einer Seite locken muß Exploit, und dann würde er zu diesem Angriff ausgesetzt werden. Sie können keine Links vertrauen, wie zufällig, in einem Gespräch werfen, verschiedener „Homepages“ usw. Dies ist wahrscheinlich die wichtigste Empfehlung von allen. Leider richtig angewandt XSS alle Vorsicht löschen.
2.Operativnaya Patches für Ihr Betriebssystem und Browser installieren.
Normalerweise werden alle Schwachstellen im Web Hersteller veröffentlicht (auch Microsoft :) ) Auf kurze Sicht Mitteilungen fix (Patch). Es schützt vor dieser besonderen Verletzlichkeit, aber nicht auf der anderen Seite, hat noch nicht naydennyhJ (oder gefunden, aber nicht öffentlich machen). Natürlich sind die Beispiele in der Anfälligkeit der Microsoft diskutiert seit langem fest, und wer wollte, hatte er bereits betreut ihre eigene Sicherheit.
3.Otklyuchenie in einem ActiveX-Browser und Active Scripting.
Diese Maßnahme würde es unmöglich machen, in dem ActiveX-Bruder laufen und Java oder VBS-Scripts auszuführen. Es wird wirklich die Mehrheit der CDS unwirksam Angriffe machen, die Wahrheit deutlich die Funktionalität von Websites besucht beeinflussen kann. Allerdings sind nicht alle CDS für einen erfolgreichen Angriff erfordert die Unterstützung von ActiveX-Browser oder Active Scripting - und das ist kein Allheilmittel für alle Übel!
nur 4.Rabota das Internet mit eingeschränkten Rechten.
Die Umsetzung dieser Empfehlung wird, auch im Fall eines erfolgreichen Angriffs, potenziellen Schaden von ihr zu verringern. Neben Browser bekannt ist (und daher in ihm alle Skripte) mit den Rechten des aktuellen Benutzers ausgeführt werden. Seien Sie nicht ein Hacker Wasja erhalten cmd.exe mit Administratorrechten lassen :) !
Im Anschluss an diese Richtlinien werden alle werden trudnouyazvimym für domänenübergreifenden Scripting helfen!