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

Cross Domain Scripting

Einleitung

Die Idee, diesen Artikel zu schreiben, kam zu mir, nachdem es notwendig war, einem Anfänger einen Hinweis auf eine detaillierte und verständliche Erklärung dieses Begriffs zu geben. Nachdem ich die Suchmaschinen geklettert hatte, war ich überrascht zu finden, dass das Finden eines solchen Artikels nicht einfach ist. Der Begriff entweder wurde überhaupt nicht erklärt, entweder in zwei Worten und in Englisch :) . Mittlerweile sind Windows-Schwachstellen dieser Art ziemlich oft und sie sind mehr als ernst! Deshalb habe ich in diesem Artikel versucht, diese Art von Angriffen zu beschreiben, die Besonderheiten der Ausbeutung dieser Art von Schwachstellen und Schutz gegen sie sowie konkrete Beispiele zu geben. Der Artikel wurde meistens natürlich für Anfänger geschrieben, aber ich hoffe, dass es für erfahrene Leser nützlich sein wird.

Was ist Cross Domain Scripting?

Zunächst wurde Cross-Domain Scripting (CDS) mit Fehlern im Sicherheitsmodell aller bekannten "Esel" aka Internet Explorer (IE) verknüpft. Jedoch seit Die architektonischen Besonderheiten der modernen Browser unterscheiden sich nicht viel voneinander, dann sind Angriffe dieser Art derzeit fast allen bekannten Webbrowsern unterworfen. Dennoch führen die bestehenden Unterschiede zwischen den Programmen dieser Klasse dazu, dass die CDS am häufigsten "browserabhängig" ist, dh zB funktioniert sie auf IE, funktioniert aber nicht auf Opera oder umgekehrt.
Die Basis von Schwachstellen wie CDS ist das Konzept der "Domain". In diesem Zusammenhang unterscheidet sich die Bedeutung dieses Begriffes etwas von dem allgemein akzeptierten. "Domain" ist nicht nur eine Internet-Site-Adresse, es ist nicht einmal eine "Domäne des hierarchischen Internet-Namensraums" - dieses Konzept bezeichnet eine bestimmte "Sicherheitsgrenze", die kein Benutzer-Skript erlaubt ist, darüber hinauszugehen.
Im Kern des Sicherheitsmodells eines beliebigen Webbrowsers ist das Prinzip, dass sich die Ressourcen verschiedener Domänen (Seiten, Skripte usw.) nicht in irgendeiner Weise schneiden können, d.h. Zugriff auf den inneren Inhalt und die Daten von einander. Wenn dies möglich wäre, könnte beispielsweise ein Skript auf der Homepage des jungen Vasya-Hackers auf die Mail.Ru-Mailbox-Daten von einem ahnungslosen Benutzer zugreifen, den Vasya auf seine Seite gelockt hat. Das würde Spaß machen :) !! Darüber hinaus sind nach der Architektur von Windows und den Konzepten des Aufbaus moderner Browser jede Netzwerkressource im lokalen Netzwerk und das eigene Dateisystem des Clients auch "Domains", was bedeutet, dass es möglich ist, von Scripts aus wie eine Ressource im Internet zuzugreifen. Eigentlich ist das lokale Dateisystem des Kunden oft das Ziel von domänenübergreifenden Angriffen.
Gleichzeitig ist die Interaktion zwischen Ressourcen (Seiten und Skripten) innerhalb der Domain (und all ihrer Subdomains!) Vom Microsoft Sicherheitskonzept erlaubt und ist grundsätzlich unbegrenzt. Es ist schwer zu beurteilen, ob es richtig ist oder nicht, aber was ist so einfacher :) Und gleichzeitig wachsen die Möglichkeiten des Web-Surfens, das ist sicher.
Also, was ist Cross-Domain Scripting? Im Zusammenhang mit dem Vorstehenden kann dieser Begriff als "domänenübergreifendes Scripting" übersetzt werden, d.h. "Scripted Domain Grenzen überschreiten" ist eine Verletzung dieser geschätzten Sicherheitslinie, deren Zugriff für den Zugriff auf Daten aus anderen Domains, einschließlich des lokalen Dateisystems des Clients, erfolgt. Diese Verletzung wird am häufigsten von der Fähigkeit begleitet, beliebige HTML- und Java-Code im Kontext anderer Domänen zu schreiben und auszuführen, Daten aus anderen Domänen zu lesen (z. B. Kennwortformulare oder Dateien auf dem Client-System) und sogar beliebige Befehle auf dem Remotecomputer auszuführen.
Oft wird das Konzept der domänenübergreifenden Scripting durch das Konzept der Cross-Site-Scripting (XSS) ersetzt. In der Tat kommt es oft vor, dass die externen Manifestationen dieser Schwachstellen sehr ähnlich sind, besonders wenn CDS Java-Code in den Kontext einer anderen Domain einfügt. Trotz der Ähnlichkeit ist das Wesen dieser Schwachstellen jedoch anders:
Zuerst ist der Umfang von XSS definitionsgemäß auf eine Domäne beschränkt. Während CDS im Allgemeinen alle Domains + das lokale Dateisystem des Clients beeinflusst.
Zweitens liegt die Ursache von XSS-Schwachstellen in den Fehlern von Scripts, die sich auf dem Server befinden, und besteht in der Regel in einer unzureichenden Filterung von Daten, die vom Benutzer empfangen werden. Die Quelle der CDS-Schwachstellen ist die Client-Software (Browser und Betriebssystem), und es ist in der Regel nicht mit Benutzerdaten verknüpft.
Nun, vergiss nicht, dass die Gefahr der erfolgreichen Ausbeutung eines Angreifers XSS viel geringer ist als aus dem CDS. Immerhin wird im ersten Fall ein Maximum an vertraulichen Nutzdaten (Passwörter etc.) und nur von einem Standort aus veräußert, und mit CDS ist es möglich, vertrauliche Daten von beliebigen Seiten zu stehlen und oftmals beliebige Befehle auf dem Client-System auszuführen Erlaubt Ihnen, die volle Kontrolle zu übernehmen.

Wie funktioniert es

Warum ist diese Art von Angriff möglich? Der Grund dafür ist, dass die gleiche "Sicherheitslinie" zwischen Domains künstlich erstellt wird, dass alle Arbeiten zur Vermeidung von domänenübergreifenden Scripting durch den Webbrowser und seine Komponenten durchgeführt werden - es gibt keine architektonischen Einschränkungen. So gibt es immer eine Möglichkeit von Fehlern in den Verifikationsverfahren, die Fähigkeit, sie zu umgehen, was jetzt erfolgreich gemacht wird.
Für mehr als ein Jahrzehnt der Verwendung von Web-Browsern wurden viele Wege gefunden, um die Domäne der geschätzten Grenze zu überwinden. Allerdings können die meisten von ihnen in zwei Klassen unterteilt werden:
1. Verwendung von Sicherheitsfehlern im objektorientierten Browser-Modell;
2. Verwenden eines Zwischenlinks, um einen Angriff auszuführen.
Betrachten wir diese Angriffsklassen genauer.
Im Mittelpunkt der ersten ist die klar ausgedrückte objektorientierte Architektur moderner Browser und der virtuellen Java-Maschine. In der Tat ist alles, was wir auf dem Bildschirm eines Webbrowsers sehen, Objekte bestimmter Klassen mit ihren Eigenschaften, Ereignissen und Methoden. Mit diesem objektorientierten Modell- und Java-Scripts können wir auf jedes beliebige Element der in den Browser geladenen Seite zugreifen, Daten lesen und schreiben, neue Fenster öffnen usw. Darüber hinaus ist es mit Scripts möglich, die Elemente des Webbrowsers selbst und sogar Benutzeraktionen teilweise zu steuern: Vorwärts / Rückwärts durch Seiten zu bewegen, Hinzufügen zu Favoriten usw.
Allerdings können einzelne Fenster oder Seitenelemente in einem Webbrowser zu verschiedenen Domänen gehören, was bedeutet, dass es notwendig ist, den Zugriff auf sie zu verhindern. Sie können nicht zulassen, ein Benutzer-Skript öffnen Sie eine andere Domain in einem neuen Browser-Fenster, haben die Möglichkeit, etwas da unten zu schreiben oder nehmen Sie es von dort aus. Sie können kein Skript auf einer Seite mit einem Frame zulassen, in dem die Ressource aus einer anderen Domain geladen ist, auf diesen Frame zugreifen und auf seine Daten zugreifen können. Darüber hinaus ist ein Datenverlust von einer Domain zur anderen nicht nur durch Eigenschaften möglich, sondern auch durch Methoden und Ereignisse von Objekten! Sagen Sie ein Skript auf der Seite des jungen Hackers Vasya, wo er einen ahnungslosen Benutzer lockte, sollte nicht wissen, welche Tasten er klickt, wenn er das Passwort für die Anmeldung in Mail.Ru eingibt, in einem anderen Browserfenster geöffnet. Nun, es gibt viele Beispiele!
Leider, und vielleicht zum Glück;), werden solche Sicherheitskontrollen oft falsch durchgeführt und manchmal sogar völlig 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 Domains zu schreiben usw. Wegen der ziemlich komplexen Architektur des objektorientierten Modells werden solche "Löcher" oft darin gefunden. Unten ist ein Beispiel für diese Klasse von Angriffen (Beispiel 1).
Um Anschläge der zweiten Klasse durchzuführen, benutze etwas Zwischenstufe. Was ist zu tun, wenn der direkte Zugriff auf eine andere Domain verboten ist? Das ist richtig Herumlaufen! Und plötzlich gibt es jemanden, an den dieser Appell nicht verboten ist, und er kann von dort aus Daten nehmen und auf uns oder umgekehrt übertragen, um unsere Daten in den Kontext einer anderen Domain zu schreiben. Die am meisten anfällig aus dieser Sicht ist Microsofts ActiveX-Technologie. ActiveX-Technologie bietet dem Benutzer Objekte, deren Eigenschaften und Methoden, die vom Betriebssystem für alle Hilfszwecke verwendet werden. Um beispielsweise die Windows-Hilfedateien (* .chm) über den Webbrowser anzuzeigen, verwenden Sie die HTML Help ActiveX-Komponente. Ist es nicht bequem? Allerdings fungieren ActiveX-Objekte oft als eine Art Trojanische Pferde! Die Tatsache ist, dass es einen Weg, um diese Komponenten (Download, Zugriff auf ihre Eigenschaften und Methoden) über eine Web-Seite zu verwalten. Verwenden Sie dazu das Tag. Aber oft enthalten diese ActiveX-Objekte Methoden zur Manipulation des Dateisystems, starten Anwendungen, navigieren durch Webseiten und so weiter. So Es gibt eine Gelegenheit von außen, alle diese Aktionen zu produzieren und darüber hinaus einen vollständigen Austausch von Daten mit dem Opfer durchzuführen! Lesen Sie zum Beispiel den Inhalt der lokalen Client-Dateien und senden Sie diese Daten wieder an das Skript oder verwenden Sie ein ActiveX-Objekt, um eine andere Domain zu öffnen und seinen Java-Code in seinen Kontext zu schreiben. Mit dieser Klasse von Angriffen ist es manchmal möglich, eine beliebige Codeausführung (mit cmd.exe mit den notwendigen Parametern) auf dem Client-System zu erreichen. Derzeit ist diese Art von CDS auch weit verbreitet und findet ständig neue anfällige ActiveX-Objekte. Das folgende ist ein Beispiel für eine solche Schwachstelle (Beispiel 2).
Zusätzlich zu den betrachteten Klassen von CDS gibt es noch andere Möglichkeiten zur Umgehung von Interdomain-Beschränkungen. True, oft sind diese Methoden sehr exotisch und sind selten. Zum Beispiel wurde die Cross-Cookie-Schwachstelle im Juli 2004 (http://www.westpoint.ltd.uk/advisories/wp-04-0001.txt) entdeckt. Es erlaubte unter bestimmten Bedingungen den Zugriff auf die Cookies anderer Domains (lesen / schreiben). Und das war einer der wenigen Fälle, in denen viele Browser anfällig waren: IE, Mozilla, Opera, Konqueror.
So CDS ist jetzt eine sehr häufige Art von Angriff und neue Wege der Ausnutzung dieser Schwachstellen werden ständig entdeckt (der "Angriffsvektor").

Beispiele für CDS

Das alles oben beschrieben wurde klarer - schauen wir uns ein paar Beispiele für echte CDS-Schwachstellen an. Alle wurden im Internet Explorer gefunden und erlauben es Ihnen, Ihren Java Code in den Kontext anderer Domains einzufügen. Normalerweise wird dies verwendet, um Cookies zu stehlen oder beliebige Aktionen innerhalb der aktuellen Benutzersitzung durchzuführen.

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

Diese Sicherheitsanfälligkeit wurde im Juli 2004 entdeckt und ist mit einem Sicherheitsfehler im objektorientierten IE-Modell verbunden (die erste Klasse von CDS-Schwachstellen aus den oben diskutierten).
Sein Wesen ist wie folgt. Wie Sie wissen, um eine andere Seite in das aktuelle Browser-Fenster (möglicherweise aus einer anderen Domain) zu laden, können Sie die location.href-Eigenschaft oder die location.assign () -Methode verwenden. Nach dem Laden der benötigten Seite ist jedoch eine weitere Ausführung des Java-Codes des aktuellen Skripts unmöglich - ansonsten könnte das Skript Mail.Ru laden und beliebige Aktionen im Kontext dieser Domain ausführen. Allerdings war es möglich, diese Einschränkung zu umgehen, indem sie die location.assign () - Methode auf genau das gleiche umwandelt, aber ein anderes Fenster (schließlich haben wir ein objektorientiertes Modell und wir können die Methoden der verschiedenen Objekte zueinander zuordnen). Als Ergebnis wurde es möglich, Java-Code im Kontext des aktuellen Fensters auszuführen, aber nach dem Herunterladen der benötigten Seite - wie erforderlich! Das folgende Skript führt die erforderlichen Aktionen aus:


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 = "/ click? Http: // localhost";


Zuerst öffnet sich ein neues Fenster, das in der Schleife auf die Seite (in unserem Fall mit localhost) wartet, um in das Hauptfenster geladen zu werden. Mittlerweile ordnet das Skript die location.assign () - Methoden zu und startet das Hauptfenster der angeforderten Seite (localhost). Sobald der Download abgeschlossen ist, löst der Trigger einen Trigger in der Schleife des neuen Fensters aus, weist der Methode Java zu (da die Methode neu zugeordnet wird, die Einfügung im Kontext des Hauptfensters erfolgt) und das neue Fenster schließt sofort. Als Ergebnis der Ausführung des Skripts im Kontext von localhost führt es document.cookie aus.
Anscheinend haben die Microsoft-Entwickler die Umleitungsfunktion nicht bereitgestellt und haben in diesem Fall keine Sicherheitskontrolle eingefügt (oder falsch eingefügt). Um diese Sicherheitsanfälligkeit auszunutzen, müssen Sie Active Browsing in Ihrem Browser aktiviert haben. Lesen Sie mehr über diese Sicherheitsanfälligkeit und finden Sie hier ein Beispiel für ein Exploit: http://greyhatsecurity.org/similarmethodnameredir-discussion.htm.

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

Diese Verwundbarkeit wurde am Ende des vergangenen Jahres entdeckt, aber es wurde erst im Februar behoben. Es bezieht sich auf die zweite Art von CDS-Angriffen von den oben betrachteten, d.h. Verwendet ein Zwischenprodukt (DHTML ActiveX), um einen Angriff zu führen. Um eine Sicherheitsanfälligkeit erfolgreich ausnutzen zu können, müssen Sie folgende Aktionen ausführen:
1. DHTML ActiveX herunterladen. Dies geschieht mit Hilfe eines Tags.




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

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

3.Well, und danach kannst du 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 dieser Schwachstelle? Ich würde zwei von ihnen aussprechen:
Zuerst die Fähigkeit, beliebige Skripte innerhalb des ActiveX-Objekts extern auszuführen - meines Erachtens ist das zu viel Freiheit!
Zweitens, beim Laden einer Seite in DHTML ActiveX, ist alles dort geladen - sogar Cookies! Die Frage ist: warum? Dieses ActiveX-Objekt kann zum Bearbeiten von Seiten verwendet werden und warum gibt es Cookies nötig - es ist unklar ...
Natürlich, um diese Sicherheitsanfälligkeit auszunutzen, ist es notwendig, dass der Browser ActiveX-Ausführung ermöglicht. Lesen Sie mehr über diese Sicherheitsanfälligkeit und finden Sie hier ein Beispiel für eine Exploit: http://greyhatsecurity.org/abusiveparent-discussion.htm.

Wie kann ich dich verteidigen?

Der Schutz vor domänenübergreifenden Scripting ist nicht so einfach. Weil Die Varianten der Ausbeutung (der "Vektor der Angriffe") dieser Schwachstellen sind sehr unterschiedlich, die meisten Maßnahmen werden von einer sehr begrenzten und vorübergehenden Natur sein. Es ist fast unmöglich, alle "Angriffsvektoren" zu blockieren. Deshalb werde ich ein paar Empfehlungen geben, die nur das Risiko eines erfolgreichen Angriffs reduzieren können, aber nicht vollständig zu schützen.
1.Konservierung der Vorsicht beim Surfen im Internet.
Für die erfolgreiche Ausführung von fast allen Sorten von CDS ist es notwendig, zuerst einen ahnungslosen Benutzer auf die Exploit-Seite zu locken, worauf er diesen Angriff durchmachen wird. Sie können nicht vertrauen Links, wie durch Zufall, in die Konversation geworfen, verschiedene "Home-Seiten", etc. Dies ist wahrscheinlich die wichtigste Empfehlung von allen. Leider kann korrekt angewandter XSS alle Vorsicht übergehen.
2. Installieren Sie Patches für das Betriebssystem und den Browser.
In der Regel für alle Schwachstellen im Internet veröffentlicht der Hersteller (auch Microsoft :) ) In kurzer Zeit produziert ein Patch (Patch). Es wird vor dieser besonderen Verwundbarkeit schützen, aber nicht von anderen noch nicht gefunden (oder gefunden, aber nicht veröffentlicht). Natürlich wurden die in den Beispielen untersuchten Schwachstellen schon seit langem von Microsoft fixiert und wer auch immer wollte, hat sich schon 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 Scripts auszuführen. Dies wird wirklich die meisten CDS-Angriffe unwirksam machen, obwohl es die Funktionalität der besuchten Seiten erheblich beeinträchtigen kann. Allerdings erfordert nicht immer CDS für einen erfolgreichen Angriff Unterstützung aus dem ActiveX Browser oder Active Scripting - und das ist kein Allheilmittel für alle Krankheiten!
4. Arbeiten im Internet nur mit eingeschränkten Rechten.
Die Umsetzung dieser Empfehlung wird, auch im Falle eines erfolgreichen Angriffs, Schadenersatz daraus reduzieren. Wie Sie wissen, wird der Browser (und damit alle Skripte in ihm) mit den Rechten des aktuellen Benutzers ausgeführt. Lassen Sie sich nicht hacker Vasya bekommen cmd.exe mit Administratorrechten :) !!
Nach all diesen Empfehlungen wird es schwierig sein, für Cross-Domain Scripting anzugreifen!