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

Domänenübergreifende Skripterstellung

Einführung.

Die Idee, diesen Artikel zu schreiben, kam zu mir, nachdem es notwendig war, einem Neuling einen Hinweis auf eine detaillierte und verständliche Erklärung dieses Begriffs zu geben. Nachdem ich die Suchmaschinen geklettert hatte, war ich überrascht, dass das Finden eines solchen Artikels nicht einfach genug ist. Der Begriff wurde entweder überhaupt nicht in zwei Wörtern und in Englisch erklärt :) . In der Zwischenzeit werden Windows-Schwachstellen dieses Typs ziemlich oft gefunden und sie sind mehr als ernst! In diesem Artikel habe ich versucht, diese Art von Angriffen, die Besonderheiten der Ausnutzung dieser Art von Schwachstellen und den Schutz vor ihnen zu beschreiben und konkrete Beispiele so detailliert und klar wie möglich zu formulieren. Der Artikel wurde hauptsächlich für Anfänger geschrieben, aber ich hoffe, dass es für erfahrene Leser nützlich sein wird.

Was ist Cross Domain Scripting?

Anfänglich war Cross-Domain Scripting (CDS) mit Schwachstellen im Sicherheitsmodell aller bekannten "Esel" aka Internet Explorer (IE) verbunden. Da jedoch architektonische Merkmale von modernen Browsern unterscheiden sich nicht sehr voneinander, dann sind Angriffe dieser Art derzeit fast allen bekannten Web-Browsern unterworfen. Nichtsdestotrotz führen die bestehenden Unterschiede zwischen den Programmen dieser Klasse dazu, dass das am häufigsten gefundene CDS "browserunabhängig" ist, dh es arbeitet beispielsweise am IE, funktioniert aber nicht an Opera oder umgekehrt.
Die Basis von Schwachstellen wie CDS ist das Konzept der "Domäne". In diesem Zusammenhang unterscheidet sich die Bedeutung dieses Konzepts von der allgemein anerkannten. "Domain" ist nicht nur die Website-Adresse im Internet und nicht einmal der "Bereich des hierarchischen Internet-Namensraums" - dieses Konzept bezeichnet eine bestimmte "Sicherheitsgrenze", die kein Benutzerskript überschreiten darf.
Die Basis des Sicherheitsmodells eines beliebigen Webbrowsers ist das Prinzip, dass die Ressourcen verschiedener Domänen (Seiten, Skripte usw.) sich nicht in irgendeiner Weise schneiden können, d. H. um auf den inneren Inhalt und die Daten voneinander zuzugreifen. Wenn dies möglich wäre, könnte beispielsweise ein Skript auf der Homepage des jungen Vasya-Hackers auf die Mailbox-Daten von einem ahnungslosen Benutzer zugreifen, den Vasya auf seine Seite gelockt hat. Das würde Spaß machen. :) !! Außerdem sind gemäß der Architektur von Windows und den Konzepten des Aufbaus moderner Browser jede Netzwerkressource im lokalen Netzwerk und das kundeneigene Dateisystem auch "Domänen", was bedeutet, dass es möglich ist, von Skripten auf dieselben wie auf eine beliebige Ressource im Internet zuzugreifen. Tatsächlich ist das lokale Dateisystem des Clients meist das Ziel von domänenübergreifenden Angriffen.
Gleichzeitig ist die Interaktion zwischen Ressourcen (Seiten und Skripten) innerhalb der Domain (und all ihrer Subdomains!) Durch das Microsoft-Sicherheitskonzept erlaubt und grundsätzlich in keiner Weise eingeschränkt. Es ist schwer zu beurteilen, ob es richtig ist oder nicht, aber was ist einfacher? :) und gleichzeitig erweitern sich die Möglichkeiten des Surfs im Internet, das ist sicher.
Was ist die domänenübergreifende Skripterstellung? Im Zusammenhang mit dem Vorangehenden kann dieser Ausdruck als "domänenübergreifendes Skripting" übersetzt werden; "Überquerte Skriptdomänengrenzen" ist eine Verletzung dieser geschätzten Sicherheitszeile, deren Zugriff Zugriff auf Daten aus anderen Domänen, einschließlich des lokalen Dateisystems des Clients, gibt. Diese Verletzung wird am häufigsten von der Möglichkeit begleitet, beliebigen HTML- und Java-Code im Kontext anderer Domänen zu schreiben und auszuführen, Daten aus anderen Domänen (z. B. Passwortformulare oder Dateien auf dem Client-System) zu lesen und sogar beliebige Befehle auf dem Remotecomputer auszuführen.
Häufig wird das Konzept des domänenübergreifenden Skripts durch das Konzept des Cross Site Scripting (XSS) ersetzt. Tatsächlich kommt es häufig vor, dass die externen Manifestationen dieser Schwachstellen sehr ähnlich sind, insbesondere wenn CDS Java-Code in den Kontext einer anderen Domäne einfügt. Trotz dieser Ähnlichkeit ist das Wesen dieser Schwachstellen anders:
Zunächst ist der Umfang von XSS per Definition auf eine Domäne beschränkt. Während CDS in der Regel von allen Domänen + dem lokalen Dateisystem des Clients betroffen ist.
Zweitens liegt die Ursache von XSS-Schwachstellen in den Fehlern von Skripten, die sich auf dem Server befinden, und besteht in der Regel in einer unzureichenden Filterung der vom Benutzer empfangenen Daten. Die Quelle von CDS-Schwachstellen ist die Client-Software (Browser und Betriebssystem) und ist normalerweise nicht mit Benutzerdaten verknüpft.
Nun, wir sollten nicht vergessen, dass die Gefahr der erfolgreichen Ausnutzung eines Angreifers durch XSS viel geringer ist als bei CDS. Im ersten Fall werden maximal vertrauliche Benutzerdaten (Passwörter usw.) und nur von einer Seite aus bestanden, und mit CDS ist es möglich, vertrauliche Daten von beliebigen Sites zu stehlen und oft willkürliche Befehle auf dem Client-System auszuführen, die erlaubt es Ihnen, die volle Kontrolle zu übernehmen.

Wie funktioniert es?

Warum ist diese Art von Angriff möglich? Der Grund ist, dass die gleiche "Sicherheitslinie" zwischen den Domänen künstlich erzeugt wird, dass alle Arbeiten zur Verhinderung von domänenübergreifendem Skripting vom Webbrowser und seinen Komponenten ausgeführt werden - es gibt keine architektonischen Einschränkungen. Es besteht also immer die Möglichkeit von Fehlern bei den Überprüfungsprozeduren, die Möglichkeit, sie zu umgehen, was nun erfolgreich gemacht wird.
Seit mehr als einem Jahrzehnt der Verwendung von Webbrowsern wurden viele Wege gefunden, um die Domäne der Domain-Domäne zu überwinden. Die meisten von ihnen können jedoch in zwei Klassen eingeteilt werden:
1. Verwendung von Sicherheitsfehlern im objektorientierten Browsermodell;
2. Verwenden Sie eine Zwischenverbindung, um einen Angriff auszuführen.
Betrachten wir diese Angriffsklassen genauer.
Im Mittelpunkt der ersten steht eine eindeutig geäußerte objektorientierte Architektur moderner Browser und der Java Virtual Machine. Tatsächlich sind alles, was wir auf dem Bildschirm eines Webbrowsers sehen, Objekte bestimmter Klassen mit ihren Eigenschaften, Ereignissen und Methoden. Mit diesem objektorientierten Modell und Java-Skripten können wir auf jedes Element der in den Browser geladenen Seite zugreifen, Daten darin lesen und schreiben, neue Fenster öffnen usw. Darüber hinaus ist es mit Hilfe von Skripts möglich, die Elemente des Webbrowsers selbst und sogar Benutzeraktionen teilweise zu steuern: Vorwärts / Zurück zu Seiten bewegen, zu Favoriten hinzufügen usw.
Einzelne Fenster oder Seitenelemente in einem Webbrowser können jedoch zu verschiedenen Domänen gehören, was bedeutet, dass der Zugriff auf diese verhindert werden muss. Sie können nicht zulassen, dass ein benutzerdefiniertes Skript eine andere Domäne in einem neuen Browserfenster öffnet, die Möglichkeit hat, dort etwas zu schreiben oder von dort aus zu übernehmen. Sie können kein Skript auf einer Seite mit einem Frame zulassen, in dem die Ressource aus einer anderen Domäne geladen ist, auf diesen Frame zugreifen und auf seine Daten zugreifen kann. Darüber hinaus ist Datenleck von einer Domäne zur anderen nicht nur durch Eigenschaften, sondern auch durch Methoden und Ereignisse von Objekten möglich! Sagen Sie ein Skript auf der Seite des jungen Vasi-Hackers, wo er einen ahnungslosen Benutzer angelockt hat, sollte nicht wissen, welche Tasten er drückt, wenn er das Passwort für die Anmeldung in Mail.Ru eingibt, das in einem anderen Browserfenster geöffnet wird. Nun, es gibt viele solcher Beispiele!
Unglücklicherweise und vielleicht zum Glück;) werden solche Sicherheitsüberprüfungen oft falsch ausgeführt und manchmal sogar komplett abwesend! Daher wird es möglich, auf Elemente von Seiten aus anderen Domänen zuzugreifen, Daten von ihnen zu lesen, ihren Java-Code in den Kontext anderer Domänen zu schreiben usw. Aufgrund der ziemlich komplexen Architektur des objektorientierten Modells sind solche "Löcher" oft darin enthalten. Unten ist ein Beispiel für diese Klasse von Angriffen (Beispiel 1).
Um Angriffe zweiter Klasse durchzuführen, verwenden Sie einige Zwischenstufen. Was soll ich tun, wenn der direkte Zugriff auf eine andere Domain verboten ist? Das ist richtig! Umhergehen! Und plötzlich geht jemand hin, dem dieser Appell nicht verboten ist, und er kann Daten von dort aufnehmen und an uns oder umgekehrt übertragen - um unsere Daten in den Kontext einer anderen Domain zu schreiben. An dieser Stelle ist die ActiveX-Technologie von Microsoft am verletzlichsten. Die ActiveX-Technologie stellt dem Benutzer Objekte, deren Eigenschaften und Methoden zur Verfügung, die vom Betriebssystem für beliebige Hilfszwecke verwendet werden. Um beispielsweise die Windows-Hilfedateien (* .chm) über den Webbrowser anzuzeigen, verwenden Sie die HTML-Hilfe-ActiveX-Komponente. Ist es nicht bequem? Häufig fungieren jedoch ActiveX-Objekte als eine Art "Trojanisches Pferd"! Fakt ist, dass diese Komponenten (Download, Zugriff auf ihre Eigenschaften und Methoden) über eine Webseite verwaltet werden können. Verwenden Sie dazu das Tag. Oft enthalten diese ActiveX-Objekte jedoch Methoden zur Manipulation des Dateisystems, zum Starten von Anwendungen, zum Navigieren durch Webseiten usw. So. es besteht die Möglichkeit, all diese Aktionen von außen durchzuführen und darüber hinaus einen vollständigen Datenaustausch mit dem Opfer durchzuführen! Lesen Sie beispielsweise den Inhalt lokaler Clientdateien und senden Sie diese Daten an das Skript zurück oder verwenden Sie ActiveX, um eine andere Domäne zu öffnen und den Java-Code in seinen Kontext zu schreiben. Mit dieser Klasse von Angriffen ist es manchmal möglich, eine willkürliche Codeausführung (Ausführen von cmd.exe mit den erforderlichen Parametern) auf dem Client-System zu erreichen. Gegenwärtig ist diese Art von CDS auch weit verbreitet und findet ständig neue verwundbare ActiveX-Objekte. Das Folgende ist ein Beispiel für eine solche Sicherheitsanfälligkeit (Beispiel 2).
Zusätzlich zu den betrachteten CDS-Klassen gibt es noch andere Möglichkeiten, die Einschränkungen in der Interdomain zu umgehen. Es stimmt, oft sind diese Methoden sehr exotisch und selten. Zum Beispiel die Cross-Cookie-Schwachstelle, die im Juli 2004 entdeckt wurde (http://www.westpoint.ltd.uk/advisories/wp-04-0001.txt). Es ist unter bestimmten Bedingungen erlaubt, auf die Cookies anderer Domains zuzugreifen (lesen / schreiben). Und dies war einer der wenigen Fälle, in denen viele Browser verwundbar waren: IE, Mozilla, Opera, Konqueror.
So. CDS ist derzeit eine sehr häufige Art von Angriff und es werden ständig neue Wege zur Ausnutzung dieser Schwachstellen entdeckt (der "Angriffsvektor").

Beispiele für CDS

Um das oben Beschriebene klarer zu machen, betrachten Sie ein paar Beispiele für echte CDS-Schwachstellen. Alle von ihnen wurden im Internet Explorer gefunden und ermöglichen es Ihnen, Ihren Java-Code in den Kontext anderer Domänen einzufügen. Normalerweise wird dies verwendet, um Cookies zu stehlen oder beliebige Aktionen innerhalb der aktuellen Benutzersitzung auszuführen.

Beispiel 1. Sicherheitsanfälligkeit bei einer ähnlichen Methodennamenumleitungsübergreifenden Domäne - CAN-2004-0727 (MS04-038)

Diese Sicherheitslücke wurde im Juli 2004 entdeckt und ist mit einem Sicherheitsfehler im objektorientierten IE-Modell (die erste Klasse von CDS-Schwachstellen aus den oben genannten) verbunden.
Sein Wesen ist wie folgt. Wie Sie wissen, können Sie zum Laden einer anderen Seite in das aktuelle Browserfenster (möglicherweise aus einer anderen Domäne) die location.href-Eigenschaft oder die location.assign () -Methode verwenden. Nach dem Laden der erforderlichen Seite ist die weitere Ausführung des Java-Codes des aktuellen Skripts jedoch nicht möglich - ansonsten könnte das Skript Mail.Ru laden und im Kontext dieser Domäne beliebige Aktionen ausführen. Es war jedoch möglich, diese Einschränkung zu umgehen, indem die location.assign () -Methode auf das exakt gleiche, aber andere Fenster umgeleitet wurde (schließlich haben wir ein objektorientiertes Modell, und wir können einander die Methoden verschiedener Objekte zuweisen). Infolgedessen wurde es möglich, Java-Code im Kontext des aktuellen Fensters auszuführen, aber nach dem Herunterladen der erforderlichen Seite - wie erforderlich! Das folgende Skript führt die erforderlichen Aktionen aus:


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


Zuerst öffnet sich ein neues Fenster, das in der Schleife darauf wartet, dass die Seite (in unserem Fall mit localhost) in das Hauptfenster (aktuell) geladen wird. In der Zwischenzeit weist das Skript die Methoden location.assign () neu zu und startet das Laden des Hauptfensters der angeforderten Seite (localhost). Sobald der Download abgeschlossen ist, löst der Trigger in der Schleife des neuen Fensters einen Trigger aus, weist der assign () -Methode Java-Code zu (wegen der Neuzuweisung der Methoden erfolgt die Einfügung im Kontext des Hauptfensters) und das neue Fenster wird sofort geschlossen. Als Ergebnis der Ausführung des Skripts im Kontext von localhost führt es document.cookie aus.
Anscheinend haben Microsoft-Entwickler die Umleitungsfunktion nicht bereitgestellt und keine Sicherheitsüberprüfung (oder falsch eingefügt) in dieses Ereignis eingefügt. Um diese Sicherheitsanfälligkeit auszunutzen, müssen Sie Active Browsing in Ihrem Browser aktiviert haben. Weitere Informationen zu dieser Sicherheitsanfälligkeit finden Sie hier: http://greyhatsecurity.org/similarmethodnameredir-discussion.htm.

Beispiel 2. Sicherheitsanfälligkeit durch domänenübergreifende Sicherheitsanfälligkeit in der Active Directory-Domäne der DHTML-Bearbeitung CAN-2004-1319 (MS05-013)

Diese Sicherheitslücke wurde Ende letzten Jahres entdeckt, wurde jedoch erst im Februar behoben. Sie bezieht sich auf den zweiten Typ von CDS-Angriffen von den oben betrachteten, d. H. verwendet einen Intermediate (DHTML ActiveX), um den Angriff durchzuführen. Um die Sicherheitsanfälligkeit erfolgreich auszunutzen, müssen Sie die folgende Abfolge von Aktionen ausführen:
1. Laden Sie DHTML ActiveX herunter. Dies geschieht mit Hilfe eines Tags.




2. Laden Sie die gewünschte Seite in das ActiveX-Objekt (beliebige Domäne). Dies erfolgt durch Ausführen unseres Skripts im Kontext von DHTML ActiveX.

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

3.Well, und danach können Sie unseren HTML- und Java-Code bereits einbetten. Es wird im Kontext der geladenen Domäne ausgeführt. Alles ist einfach zu schämen :) !!

exploit.DOM.Scrypt.execScript ("alert (document.cookie)");

Was sind die Ursachen für diese Sicherheitsanfälligkeit? Ich würde zwei von ihnen herauslesen:
Erstens, die Fähigkeit, beliebige Skripte innerhalb des ActiveX-Objekts extern auszuführen - das ist meiner Meinung nach zu viel Freiheit!
Zum zweiten wird beim Laden einer Seite in DHTML ActiveX alles geladen - sogar Cookies! Frage: Warum? Dieses ActiveX-Objekt kann zum Bearbeiten von Seiten verwendet werden und warum Cookies benötigt werden - es ist unklar ...
Um diese Sicherheitsanfälligkeit auszunutzen, ist es natürlich erforderlich, dass der Browser die ActiveX-Ausführung zulässt. Weitere Informationen zu dieser Sicherheitsanfälligkeit finden Sie hier: http://greyhatsecurity.org/abusiveparent-discussion.htm.

Wie verteidigen Sie sich?

Das Schützen vor domänenübergreifender Skripterstellung ist nicht so einfach. Weil Die Ausnutzungsvarianten (der "Vektor der Angriffe") dieser Schwachstellen sind sehr vielfältig, die meisten Maßnahmen werden nur sehr begrenzten und vorübergehenden Charakter haben. Es ist fast unmöglich, alle "Angriffsvektoren" zu blockieren. Deshalb gebe ich ein paar Empfehlungen, die nur das Risiko eines erfolgreichen Angriffs reduzieren können, aber nicht vollständig zu schützen.
1. Vorsicht beim Surfen im Internet.
Um fast alle Arten von CDS erfolgreich ausführen zu können, müssen Sie zunächst einen ahnungslosen Benutzer auf eine Exploit-Seite locken, woraufhin er diesen Angriff durchläuft. Sie können Links nicht zufällig, zufällig, in der Konversation, verschiedenen "Homepages" usw. vertrauen. Dies ist wahrscheinlich die wichtigste Empfehlung von allen. Unglücklicherweise kann XSS korrekt vorgehen.
2. Installieren Sie Patches für das Betriebssystem und den Browser.
In der Regel wird für alle im Internet veröffentlichten Sicherheitslücken der Hersteller (auch Microsoft :) ) in kurzer Zeit erzeugt einen Patch (Patch). Es schützt vor dieser besonderen Verwundbarkeit, aber nicht von anderen, die noch nicht gefunden wurden (oder gefunden, aber nicht publiziert wurden). Natürlich wurden die in den Beispielen untersuchten Schwachstellen schon lange von Microsoft behoben, und wer es wollte, hat sich bereits um seine Sicherheit gekümmert.
3. Deaktivieren im Browser ActiveX und Active Scripting.
Diese Maßnahme macht es unmöglich, ActiveX auszuführen und Java- oder VBS-Skripte auszuführen. Dies wird die meisten CDS-Angriffe tatsächlich unwirksam machen, obwohl sie die Funktionalität der besuchten Sites erheblich beeinträchtigen können. Allerdings erfordert CDS für einen erfolgreichen Angriff nicht immer Unterstützung aus dem ActiveX-Browser oder Active Scripting - und dies ist kein Allheilmittel für alle Übel!
4. Arbeiten Sie nur mit eingeschränkten Rechten im Internet.
Die Umsetzung dieser Empfehlung wird, selbst im Falle eines erfolgreichen Angriffs, den möglichen Schaden reduzieren. Wie Sie wissen, wird der Browser (und damit alle darin enthaltenen Skripts) mit den Rechten des aktuellen Benutzers ausgeführt. Lassen Sie Hacker Vasya cmd.exe mit Administratorrechten nicht erhalten :) !!
Die Befolgung all dieser Empfehlungen wird für domänenübergreifende Skripterstellung schwer zu attackieren sein!