Cross Domain Scripting

Einführung.

Die Idee, diesen Artikel zu schreiben kam mir, nachdem er nahm man dem Anfänger einen Link zu einer detaillierten und klaren Erläuterung des Begriffs zu geben. Klettern Sie auf den Suchmaschinen, ich war überrascht, dass ein solcher Artikel ist schwierig genug. Der Begriff wird nicht erklärt, entweder allgemein oder in zwei Worten und in Englisch :) . Inzwischen in Windows Verwundbarkeit dieser Art sind recht häufig gefunden, und sie sind mehr als ernst! Deshalb habe ich in diesem Artikel haben so viel wie möglich im Detail ausprobiert und klar beschreiben diese Art von Angriff, 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 der Cross Domain Scripting?

Zunächst Quer Domain-Scripting (CDS) wurde auf Mängel im Sicherheitsmodell des bekannten "Esel» aka Internet Explorer (IE) verbunden sind. Da jedoch architektonischen Besonderheiten von modernen Browsern voneinander nicht sehr verschieden ist, sind die Angriffe dieser Art derzeit Gegenstand fast allen bekannten Web-Browsern. Dennoch bestehen Unterschiede zwischen der Klasse des Programms führt zu der Tatsache, dass die meisten oft CDS "brauzerozavisimym" gefunden, das heißt beispielsweise an IE läuft, 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 Begriffs etwas anders als die üblichen. "Domain" - ist nicht nur eine Website-Adresse im Internet, und sogar "die Region des Raumes der Internet hierarchische Namen" - dieser Begriff bezieht sich auf eine bestimmte "Grenzsicherheit» (Sicherheitsgrenze), gehen darüber hinaus, dass keine benutzerdefinierte Skripts erlaubt ist.
Das Sicherheitsmodell basiert auf einem beliebigen Web-Browser ist das Prinzip, dass die Ressourcen der verschiedenen Domänen (Seiten, Skripte, etc.) können in irgendeiner Weise nicht miteinander interferieren, dh Zugriff auf die inneren Inhalte und Daten zueinander. Wenn dies möglich wäre, dann zum Beispiel den Zugriff auf das Datenfach auf Mail.Ru ahnungslose Benutzer das Skript auf der Homepage des jungen Hacker Wasja bekommen konnte, dass Bob auf Ihre Seite gelockt. 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 einem eigenen Client-Dateisystem ist auch eine "Domäne", und deshalb 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 das Ziel von Cross-Domain-Attacken.
Zur gleichen Zeit wird die Wechselwirkung zwischen einer Ressource (Seiten und Scripts) innerhalb einer Domain (und alle ihre Unterdomänen!) Microsoft Sicherheitskonzept erlaubt und ist grundsätzlich nicht beschränkt. Es ist schwierig, richtig oder falsch zu beurteilen, aber das ist leichter :) während Web-Surfen erweitert - das ist sicher.
Also, was ist bei domänenübergreifender Scripting? Im Zusammenhang mit den oben genannten, dieser Begriff kann übersetzt werden - "Cross-Domain-Scripting", das heißt, "Schnittpunkt Skript Domänengrenzen hinweg" - eine Verletzung dieser Sicherheitslinie geschätzt, dessen Ausgang den Zugriff auf die Daten von anderen Domänen 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 ausgeführt werden.
Oft wird der Begriff der «Cross-Domain-Scripting» verwirrt mit dem Begriff «Cross-Site-Scripting» (XSS). Tatsächlich ist es oft, dass die Symptome dieser Schwachstellen sehr ähnlich sind - vor allem, wenn es ein Java-Code Insertion als Folge der CDS im Zusammenhang mit einer anderen Domäne ist. Doch trotz der Ähnlichkeiten, ändert sich die Essenz dieser Schwachstellen:
Zunächst wird der Wirkungsbereich XSS per Definition eine Domäne beschränkt. Während seiner Tätigkeit als CDS betrifft in der Regel alle Domänen + lokale Client-Dateisystem.
Zweitens liegt der Grund im Skript XSS Schwachstellen-Fehler auf einem Server befindet, und in der Regel nicht ausreicht, das Filtern von Daten von dem Benutzer empfangen. Quelle CDS Verwundbarkeiten - Client-Software (Browser und Betriebssystem), und es hat in der Regel nichts mit Benutzerdaten zu tun.
Und wir müssen nicht, dass das Niveau der Gefahr, dass der erfolgreiche Betrieb von bösartigen XSS vergessen viel niedriger als die der CDS. Tatsächlich in dem ersten Fall als Maximum, wird es Leckage von vertraulichen Daten des Benutzers (Passwörter, etc.) und nur von einer Seite, während die CDS vertrauliche Daten von Websites stehlen kann, und oft auch die Ausführung beliebigen Befehle auf dem Client-System, es ermöglicht Ihnen die vollständige Kontrolle über das System zu übernehmen.

Wie funktioniert es?

Also warum ist es auf 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 Grenzen. So gibt es immer die Möglichkeit von Fehlern in Testverfahren, die Fähigkeit, um sie zu erhalten, das nun erfolgreich durchgeführt.
Seit mehr als zehn Jahren Erfahrung bei der Web-Browser verwenden sind, wurden viele Möglichkeiten, um die begehrte Domain-Grenze zu überwinden gefunden. die meisten von ihnen können jedoch in zwei Klassen unterteilt werden:
1.Ekspluatatsiya Sicherheitsfehler in der objektorientierten Modell von Browsern;
2. einen Vermittler Verwenden Sie den 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 dem 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 werden mit Hilfe von Skripten möglich Teilsteuerelemente des Web-Browsers und auch die Aktionen des Benutzers: move "Forward" / "Zurück" auf der Seite, fügen Sie in den "Favoriten", usw.
Jedoch einzelne Elemente eines Fensters oder einer Seite in einem Web-Browser kann auf verschiedene Domänen gehören, und somit den Zugang zu ihnen zu verhindern müssen. Wir können keine benutzerdefinierten Skript zulassen, indem eine neue Domäne in einem neuen Browser-Fenster zu öffnen, war in der Lage, etwas zu schreiben oder von dort lesen. Wir können nicht ein Skript auf einer Seite mit einem Rahmen zu ermöglichen, die eine Ressource von einer anderen Domäne holen konnte diesen Rahmen zugreifen und haben Zugriff auf ihre Daten. Darüber hinaus Datenverlust von einer Domäne in eine andere ist möglich, nicht nur durch die Eigenschaften, sondern auch durch Methoden und Ereignisse Einrichtungen! Lassen Sie uns auf der Seite des jungen Hacker das Skript sagen Wasja, wo er die ahnungslose Benutzer gelockt nicht zu "wissen" hat, welche Tasten er drückt, wenn ein Passwort einzugeben Fenster zu melden Sie sich mit Mail.Ru, offen in einem anderen Browser. Und 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, um Daten zu lesen von ihnen, schreiben Sie Ihre Java-Code im Kontext von anderen Domänen, usw. Aufgrund der recht komplexe Architektur eines objektorientierten Modells solche "Löcher" in es sind durchaus üblich. Unten ist 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! Gehen Sie um! Was, wenn es etwas, das 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 - unseren Erkenntnissen in Zusammenhang mit einer anderen Domäne aufzunehmen. Die am meisten gefährdeten aus dieser Sicht ist die ActiveX-Technologie von Microsoft. ActiveX-Technologie bietet dem Benutzer Objekte, deren Eigenschaften und Methoden, die durch das Betriebssystem für jede Neben Zweck verwendet werden. Um zum Beispiel einen Web-Browser in Windows-Hilfedateien (* .chm) verwendet HTML Help ActiveX-Komponente anzuzeigen. Ist das nicht praktisch? Allerdings ActiveX-Objekte dienen oft als eine Art "trojanische Pferde"! Die Tatsache, dass es einen Weg gibt, diese Komponenten (Upload, Zugriff auf ihre Eigenschaften und Methoden) über die Web-Seite zu verwalten. Dies geschieht mit dem Tag verwendet. Aber oft sind diese ActiveX-Objekte umfassen Methoden der Manipulation mit dem Dateisystem, Anwendungen starten, Webseiten, Navigation usw. so ist es möglich, alle diese externen Aktionen zu erzeugen und darüber hinaus eine vollständige Kommunikation mit dem Opfer implementieren! Zum Beispiel, lesen Sie die Inhalte der lokalen Dateien des Kunden und die Daten an das Skript zurückschicken, oder durch ein ActiveX-Objekt mit einer anderen Domain zu öffnen und es im Zusammenhang mit Java-Code schreiben. Es ist durch diese Klasse von Angriff manchmal möglich ist, die Ausführung beliebigen Codes (laufen cmd.exe mit den erforderlichen Parametern) auf dem Client-System zu erreichen. Derzeit wird auch diese Art von CDS weit verbreitet und ständig neue verwundbar ActiveX-Objekte finden. Unten ist ein Beispiel einer Sicherheitsanfälligkeit (Beispiel 2).
Auch diskutiert CDS-Klasse, gibt es andere Möglichkeiten, um die Cross-Domain-Beschränkungen zu umgehen. Allerdings sind diese Methoden oft eher exotisch und selten auftreten. Zum Beispiel erfasst im Juli 2004 Kreuz-Cookie-Verwundbarkeit (http://www.westpoint.ltd.uk/advisories/wp-04-0001.txt). Es ermöglicht Ihnen, (Lesen / Schreiben) an die Cookies von anderen Domänen unter bestimmten Bedingungen 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 für CDS

Um alle oben genannten sind verständlich - siehe 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. Normalerweise wird es verwendet, Cookies oder die Ausführung beliebigen Aktion innerhalb der aktuellen Benutzersitzung zu stehlen.

Beispiel 1. Ähnliche Method Name Redirection Cross Domain Vulnerability - CAN-2004-0727 (MS04-038)

Diese Sicherheitslücke wurde im Juli 2004 und die damit verbundene Sicherheitslücke im Internet Explorer objektorientiertes Modell (1. Klasse der CDS Anfälligkeiten oben erörtert) entdeckt.
Sein Wesen ist wie folgt. Es ist bekannt, eine andere Seite in das aktuelle Browserfenster zu laden (vielleicht aus einer anderen Domäne), können Sie die Eigenschaft oder location.href location.assign () -Methode verwenden. Nachdem jedoch die aufgerufene Seite die weitere Ausführung von Java-Script-Code laden kann dies nicht sein - oder das Skript könnte Mail.Ru in Zusammenhang mit dieser Domain zu laden und auszuführen ist Willkür. Allerdings war es möglich, diese Einschränkung durch eine Umleitung (Redirect) Methode location.assign () an genau der gleichen zu umgehen, aber das andere Fenster (immerhin haben wir ein objektorientiertes Modell und wir können die Methoden der verschiedenen Objekte einander zuordnen). Als Folge die Möglichkeit, Java-Code im Kontext des aktuellen Fensters zu laufen, aber nach der gewünschten Seite laden - 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 Sie auf http: // localhost?";


Zunächst öffnet sich ein neues Fenster, das in der Schleife für die Download-Seite wartet (in diesem Fall localhost) mit dem Haupt (Strom) Fenster. Inzwischen ordnet das Skript Methoden location.assign () und beginnt das Hauptfenster der gewünschten Seite zu laden (localhost). Wenn der Download in einer Schleife des neuen Fensters endet Trigger aktiviert ordnen () Methode Java-Code eingefügt wird (aufgrund der Einfügung auftritt Remapping Methoden im Zusammenhang mit dem Hauptfenster) und das neue Fenster wird sofort geschlossen. Als Ergebnis des Skripts wird im Kontext der lokalen Host document.cookie ausgeführt.
Anscheinend hat Microsoft nicht die Möglichkeit zur Verfügung gestellten Funktionen und Sicherheitsprüfungen umleiten nicht eingefügt (oder falsch eingelegt) in diesem Fall. 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 zu 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 am Ende des vergangenen Jahres entdeckt, aber erst im Februar festgelegt ist. Er bezieht sich auf die zweite Art von Angriff CDS oben erörtert, das heißt, Es verwendet einen Zwischen (DHTML ActiveX), um den Angriff auszuführen. Ein erfolgreicher Angriff setzt voraus, dass Sie die folgenden Schritte durchführen müssen:
1. Stellen Sie den DHTML ActiveX einfügen. Dies geschieht mit dem Tag verwendet.




2.Zagruzit in ActiveX-Objekt, das Sie wollen, dass wir Seite (benutzerdefinierte Domäne). Dies wird durch die Ausführung in Zusammenhang mit unserer 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-Steuerelement kann verwendet werden, die Seite zu bearbeiten, und warum gibt es Cookies müssen - es ist unklar, ...
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 zu 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"), sind diese Sicherheitsanfälligkeiten sehr vielfältig, werden die meisten der Aktion sehr begrenzt und vorübergehend. Beenden Sie alle "Angriffsvektoren" ist fast unmöglich. Also werde ich ein paar Richtlinien geben, die nur das Risiko eines erfolgreichen Angriffs zu reduzieren, 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 ahnungslose Benutzer auf eine Seite locken müssen 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, verschiedene "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 Internet Hersteller veröffentlicht (auch Microsoft :) ) In einer kurzen Zeitspanne erzeugt einen Fix (Patch). Es schützt vor dieser besonderen Verletzlichkeit, aber nicht auf der anderen Seite hat nicht naydennyhJ (oder gefunden, aber nicht öffentlich machen). Natürlich sind die Beispiele in der Sicherheitslücke, die seit langem die Microsoft korrigiert, und wer wollte, hatte er bereits betreut ihre Sicherheit.
3.Otklyuchenie im Browser ActiveX und Active Scripting.
Diese Maßnahme würde es unmöglich machen, in dem ActiveX-Bruder zu laufen und Java und VBS-Scripts auszuführen. Es wird wirklich die Mehrheit der CDS unwirksam Angriffe machen, die Wahrheit im Wesentlichen die Funktionalität von Websites besucht beeinflussen können. Allerdings sind nicht alle CDS für einen erfolgreichen Angriff erfordert die Unterstützung von ActiveX-Browser oder Active Scripting - und es ist kein Allheilmittel für alle Übel!
4.Rabota das Internet mit eingeschränkten nur Rechte.
Die Umsetzung dieser Empfehlung wird, auch im Falle eines erfolgreichen Angriffs, potenzielle Schaden von ihr zu vermindern. 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!