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

Domainübergreifendes Scripting

Einleitung

Die Idee, diesen Artikel zu schreiben, entstand, nachdem es notwendig war, einem Neuling einen Link zu einer detaillierten und verständlichen Erklärung dieses Begriffs zu geben. Beim Klettern in Suchmaschinen war ich überrascht, dass es ziemlich schwierig ist, einen solchen Artikel zu finden. Der Begriff wird entweder gar nicht oder in zwei Worten und auf Englisch erklärt :) . In der Zwischenzeit wird diese Art von Sicherheitsanfälligkeit in Windows häufig festgestellt und ist mehr als schwerwiegend! Daher habe ich in diesem Artikel versucht, diese Art von Angriffen, bestimmte Merkmale der Ausnutzung dieser Art von Sicherheitsanfälligkeiten und den Schutz vor diesen Angriffen zu beschreiben, um bestimmte Beispiele so gründlich und klar wie möglich zu nennen. Der Artikel wurde natürlich hauptsächlich für Anfänger geschrieben, aber ich hoffe, er wird für erfahrene Leser von Nutzen sein.

Was ist domänenübergreifendes Scripting?

Anfänglich war Cross-Domain Scripting (CDS) mit Mängeln im Sicherheitsmodell des bekannten "Esels", auch bekannt als Internet Explorer (IE), verbunden. Seitdem jedoch Da sich die Architekturmerkmale moderner Browser kaum voneinander unterscheiden, sind derzeit fast alle bekannten Webbrowser Angriffen dieser Art ausgesetzt. Die bestehenden Unterschiede zwischen Programmen dieser Klasse führen jedoch dazu, dass CDS am häufigsten als „browserabhängig“ eingestuft wird, dh es funktioniert beispielsweise im Internet Explorer, jedoch nicht in Opera oder umgekehrt.
Sicherheitslücken wie CDS basieren auf dem Begriff „Domain“. In diesem Zusammenhang unterscheidet sich die Bedeutung dieses Konzepts etwas von der allgemein anerkannten. Eine „Domain“ ist nicht mehr nur eine Website-Adresse im Internet und auch nicht „ein Bereich des hierarchischen Namensraums des Internets“ - dieses Konzept bedeutet eine bestimmte „Sicherheitsgrenze“ (Sicherheitsgrenze), über die kein Benutzerskript hinausgehen darf.
Das Sicherheitsmodell eines jeden Webbrowsers basiert auf dem Prinzip, dass sich Ressourcen verschiedener Domänen (Seiten, Skripte usw.) in keiner Weise überschneiden dürfen, d. H. Zugriff auf interne Inhalte und Daten voneinander erhalten. Wenn es möglich wäre, könnte beispielsweise ein Skript auf der Homepage eines jungen Hackers Vasya Zugriff auf die Mailbox-Daten auf Mail.Ru eines ahnungslosen Benutzers erhalten, den Vasya auf seine Seite gelockt hat. Das würde Spaß machen :) ! Darüber hinaus sind gemäß der Windows-Architektur und dem Konzept, moderne Browser zu erstellen, alle Netzwerkressourcen im lokalen Netzwerk und das eigene Dateisystem des Clients auch „Domänen“. Auf sie kann also wie auf jede andere Ressource im Internet über Skripts zugegriffen werden! Tatsächlich ist das lokale Client-Dateisystem am häufigsten das Ziel domänenübergreifender Angriffe.
Gleichzeitig ist die Interaktion zwischen den Ressourcen (Seiten und Skripten) innerhalb der Domain (und all ihren Subdomains!) Zwischen dem Microsoft-Sicherheitskonzept erlaubt und grundsätzlich nicht eingeschränkt. Es ist schwer zu beurteilen, ob es richtig ist oder nicht, aber was ist einfacher :) und gleichzeitig die Möglichkeiten des Internetsurfens erweitern - das ist sicher.
Was ist domänenübergreifendes Scripting? Im Zusammenhang mit dem Vorstehenden kann dieser Begriff übersetzt werden als - "Cross Domain Scripting", d.h. "Das Skript überschreitet die Domänengrenzen" ist eine Verletzung dieser geschätzten Sicherheitslinie, die darüber hinaus den Zugriff auf die Daten anderer Domänen, einschließlich des lokalen Client-Dateisystems, ermöglicht. Ein solcher Verstoß geht häufig mit der Möglichkeit einher, beliebigen HTML- und Java-Code im Kontext anderer Domänen aufzuzeichnen und auszuführen, Daten aus anderen Domänen zu lesen (z. B. Formulare mit Kennwörtern oder Dateien auf dem Client-System) und sogar beliebige Befehle auf einem Remotecomputer auszuführen.
Oft wird das Konzept des "Cross Domain Scripting" durch das Konzept des "Cross Site Scripting" (XSS) ersetzt. In der Tat kommt es häufig vor, dass die externen Manifestationen dieser Sicherheitsanfälligkeiten sehr ähnlich sind - insbesondere, wenn das Ergebnis von CDS Java-Code in den Kontext einer anderen Domäne einfügt. Trotz der Ähnlichkeiten unterscheidet sich das Wesen dieser Sicherheitsanfälligkeiten:
Erstens ist der Umfang von XSS per Definition auf eine Domäne beschränkt. CDS unterliegt im Allgemeinen allen Domänen und dem lokalen Client-Dateisystem.
Zweitens liegt die Ursache für XSS-Schwachstellen in den Fehlern der auf dem Server befindlichen Skripte und in der Regel in der unzureichenden Filterung der vom Benutzer empfangenen Daten. Die Quelle für CDS-Schwachstellen ist Client-Software (Browser und Betriebssystem) und hat normalerweise nichts mit Benutzerdaten zu tun.
Nun, man sollte nicht vergessen, dass das Gefährdungsniveau bei erfolgreicher Operation durch einen XSS-Angreifer viel geringer ist als bei CDS. In der Tat werden im ersten Fall maximal vertrauliche Benutzerdaten (Passwörter usw.) von nur einer Site aus verloren gehen, während vertrauliche Daten von jeder Site gestohlen werden können und häufig beliebige Befehle auf dem Client-System ausgeführt werden ermöglicht es Ihnen, die volle Kontrolle darüber zu übernehmen.

Wie funktioniert es

Warum wird diese Art von Angriff möglich? Der Grund dafür ist, dass die eigentliche "Sicherheitslinie" zwischen Domänen künstlich erstellt wird und alle Arbeiten zur Verhinderung domänenübergreifender Skripterstellung vom Webbrowser und seinen Komponenten ausgeführt werden - es gibt keine architektonischen Einschränkungen. Es besteht also immer die Wahrscheinlichkeit eines Fehlers in den Überprüfungsprozeduren, die Möglichkeit, diese zu umgehen, was jetzt erfolgreich durchgeführt wird.
Seit mehr als einem Jahrzehnt der Verwendung von Webbrowsern wurden viele Möglichkeiten gefunden, um die geschätzte Domänengrenze zu überwinden. Die meisten von ihnen können jedoch in zwei Klassen unterteilt werden:
1.Betriebssicherheitsfehler im objektorientierten Browsermodell;
2. Verwenden einer Zwischenverbindung zum Ausführen eines Angriffs.
Betrachten wir diese Angriffsklassen genauer.
Die erste basiert auf einer ausgeprägten objektorientierten Architektur moderner Browser und einer Java Virtual Machine. Alles, was wir auf dem Bildschirm eines Webbrowsers sehen, sind Objekte bestimmter Klassen mit ihren Eigenschaften, Ereignissen und Methoden. Mit diesem objektorientierten Modell und Java-Skripten können wir auf jedes in den Browser geladene Element der Seite zugreifen, Daten darin lesen und schreiben, neue Fenster öffnen usw. Darüber hinaus ist es mit Skripten möglich, die Elemente des Webbrowsers selbst und sogar Benutzeraktionen teilweise zu steuern: Verschieben von "Vorwärts" / "Rückwärts" über Seiten, Hinzufügen zu "Favoriten" usw.
Einzelne Fenster oder Seitenelemente in einem Webbrowser können jedoch zu unterschiedlichen Domänen gehören, sodass der Zugriff auf diese Domänen gestoppt werden muss. Wir können nicht zulassen, dass das Benutzerskript, das eine andere Domain in einem neuen Browserfenster öffnet, die Möglichkeit hat, dort etwas zu schreiben oder von dort zu lesen. Wir können nicht zulassen, dass das Skript auf der Seite mit dem Frame, in den die Ressource aus einer anderen Domain geladen wird, auf diesen Frame zugreift und auf seine Daten zugreift. Darüber hinaus ist ein Datenverlust von einer Domäne zu einer anderen nicht nur durch Eigenschaften, sondern auch durch Methoden und Ereignisse von Objekten möglich! Nehmen wir an, das Skript auf der Seite des jungen Hackers Vasya, das den ahnungslosen Benutzer angelockt hat, sollte nicht wissen, welche Tasten er drückt, wenn er das Kennwort für den Zugriff auf Mail.Ru eingibt, das in einem anderen Browserfenster geöffnet wird. Nun, es gibt viele solcher Beispiele!
Leider und vielleicht zum Glück;) werden solche Sicherheitsüberprüfungen oftmals falsch durchgeführt und manchmal fehlen sie gänzlich! Dadurch wird es möglich, auf die Seitenelemente aus anderen Domänen zuzugreifen, Daten aus diesen zu lesen, Ihren Java-Code im Kontext anderer Domänen zu schreiben usw. Aufgrund der relativ komplexen Architektur des objektorientierten Modells werden solche „Löcher“ häufig gefunden. Nachfolgend finden Sie ein Beispiel für diese Angriffsklasse (Beispiel 1).
Zur Durchführung der Angriffe der zweiten Klasse werden einige Zwischenstufen eingesetzt. Was tun, wenn der direkte Zugriff auf eine andere Domain verboten ist? Richtig Geh umher! Und plötzlich gibt es jemanden, an den diese Berufung nicht verboten ist, und der Daten von dort lesen und an uns übertragen kann oder umgekehrt - um unsere Daten in den Kontext einer anderen Domain zu schreiben. Aus dieser Sicht ist die ActiveX-Technologie von Microsoft am anfälligsten. Die ActiveX-Technologie stellt den Benutzerobjekten ihre Eigenschaften und Methoden zur Verfügung, die vom Betriebssystem für zusätzliche Zwecke verwendet werden. Verwenden Sie beispielsweise die HTML-Hilfe-ActiveX-Komponente, um Windows-Hilfedateien (* .chm) über einen Webbrowser anzuzeigen. Ist es nicht bequem? ActiveX-Objekte fungieren jedoch häufig als eine Art Trojaner! Tatsache ist, dass es eine Möglichkeit gibt, diese Komponenten über eine Webseite zu verwalten (herunterladen, auf ihre Eigenschaften und Methoden zugreifen). Verwenden Sie dazu das Tag. Diese ActiveX-Objekte enthalten jedoch häufig Methoden zum Bearbeiten des Dateisystems, Starten von Anwendungen, Navigieren auf Webseiten usw. Also 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 der lokalen Clientdateien, und senden Sie diese Daten an das Skript zurück, oder verwenden Sie ein ActiveX-Objekt, um eine andere Domäne zu öffnen und den Java-Code in den Kontext zu schreiben. Mit dieser Klasse von Angriffen ist es manchmal möglich, beliebigen Code (Ausführen von cmd.exe mit den erforderlichen Parametern) auf dem Client-System auszuführen. Derzeit ist diese Art von CDS ebenfalls weit verbreitet und findet ständig neue anfällige ActiveX-Objekte. Das Folgende ist ein Beispiel für eine solche Sicherheitsanfälligkeit (Beispiel 2).
Zusätzlich zu den berücksichtigten CDS-Klassen gibt es andere Möglichkeiten, domänenübergreifende Einschränkungen zu umgehen. Zwar sind diese Methoden oft sehr exotisch und kommen nur selten vor. Zum Beispiel die im Juli 2004 entdeckte Cross-Cookie-Sicherheitsanfälligkeit (http://www.westpoint.ltd.uk/advisories/wp-04-0001.txt). Unter bestimmten Bedingungen war es möglich, auf Cookies aus anderen Domänen zuzugreifen (Lese- / Schreibzugriff). Und es war einer der wenigen Fälle, in denen viele Browser anfällig waren: IE, Mozilla, Opera, Konqueror.
Also CDS ist derzeit eine sehr häufige Angriffsart, und es werden ständig neue Möglichkeiten zur Ausnutzung dieser Sicherheitsanfälligkeiten („Angriffsvektor“) entdeckt.

CDS-Beispiele

Betrachten Sie einige Beispiele für echte CDS-Schwachstellen, um alles oben Beschriebene klarer zu machen. Alle wurden im Internet Explorer gefunden und ermöglichen es Ihnen, Ihren Java-Code in den Kontext anderer Domänen einzufügen. Dies wird normalerweise verwendet, um Cookies zu stehlen oder willkürliche Aktionen während der aktuellen Benutzersitzung auszuführen.

Beispiel 1. Ähnliche Sicherheitsanfälligkeit bezüglich domänenübergreifender Umleitung von Methodennamen - CAN-2004-0727 (MS04-038)

Diese Sicherheitsanfälligkeit wurde im Juli 2004 entdeckt und steht im Zusammenhang mit einem Sicherheitsfehler im objektorientierten Modell des Internet Explorers (oben diskutierte CDS-Sicherheitsanfälligkeiten der ersten Klasse).
Sein Wesen ist wie folgt. Wie Sie wissen, können Sie zum Laden einer anderen Seite (möglicherweise von einer anderen Domain) in das aktuelle Browserfenster die Eigenschaft location.href oder die Methode location.assign () verwenden. Nach dem Laden der erforderlichen Seite ist jedoch keine weitere Ausführung des Java-Codes des aktuellen Skripts möglich. Andernfalls 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 zum exakt gleichen, aber unterschiedlichen Fenster umgeleitet wurde (schließlich haben wir ein objektorientiertes Modell und können die Methoden verschiedener Objekte einander zuordnen). Als Ergebnis wurde es möglich, Java-Code im Kontext des aktuellen Fensters auszuführen, aber nach dem Laden 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;} catch (e) {location.assign ('jvascript: alert (document.cookie)'); window.close ();}}, 100) ");
w.location.assign = location.assign;
location.href = "/ click? http: // localhost";


Zunächst öffnet sich ein neues Fenster, das darauf wartet, dass die Seite (in unserem Fall von localhost) in das Hauptfenster (aktuell) geladen wird. In der Zwischenzeit weist das Skript die location.assign () -Methoden neu zu und beginnt, die erforderliche Seite (localhost) in das Hauptfenster zu laden. Sobald der Download beendet ist, wird in der Schleife des neuen Fensters ein Trigger ausgelöst, der Java-Code wird von der Methode assign () eingefügt (aufgrund der Neuzuordnung der Methoden erfolgt die Einfügung im Kontext des Hauptfensters) und das neue Fenster wird sofort geschlossen. Durch die Ausführung des Skripts im Kontext localhost wird docking.cookie ausgeführt.
Anscheinend haben die Microsoft-Entwickler die Möglichkeit der Umleitung von Funktionen nicht vorausgesehen und in dieses Ereignis keine (oder falsch eingefügte) Sicherheitsüberprüfung eingefügt. Um diese Sicherheitsanfälligkeit auszunutzen, muss Active Scripting im Browser aktiviert sein. Weitere Informationen zu dieser Sicherheitsanfälligkeit finden Sie hier: http://greyhatsecurity.org/similarmethodnameredir-discussion.htm.

Beispiel 2. Domänenübergreifende Sicherheitsanfälligkeit im ActiveX-Steuerelement der DHTML-Bearbeitungskomponente CAN-2004-1319 (MS05-013)

Diese Sicherheitsanfälligkeit wurde Ende letzten Jahres entdeckt, jedoch erst im Februar behoben. Es bezieht sich auf den zweiten Typ von CDS-Angriffen von den oben betrachteten, d.h. Verwendet ein Intermediate (DHTML ActiveX), um einen Angriff durchzuführen. Um eine Sicherheitsanfälligkeit erfolgreich auszunutzen, müssen Sie die folgenden Aktionen ausführen:
1.Herunterladen von DHTML ActiveX. Dies geschieht mit einem Tag.




2. Laden Sie in das ActiveX-Objekt die Seite, die Sie benötigen (beliebige Domain). Dies geschieht durch Ausführen unseres Skripts im DHTML-ActiveX-Kontext.

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

3. Nun, danach können Sie bereits unseren HTML- und Java-Code einfügen. Es wird im Kontext der geladenen Domain ausgeführt. Alles ist einfach bis hässlich :) !

exploit.DOM.S Script.exec Script ("alert (document.cookie)");

Was sind die Ursachen dieser Sicherheitsanfälligkeit? Ich würde zwei davon herausgreifen:
Erstens die Möglichkeit, beliebige Skripte von außen aus dem ActiveX-Objekt heraus auszuführen - das ist meiner Meinung nach zu viel Freiheit!
Zweitens, wenn die Seite in DHTML ActiveX geladen wird, wird ALLES dort geladen - sogar Cookies! Frage: Warum? Dieses ActiveX-Objekt kann zum Bearbeiten von Seiten verwendet werden. Es ist nicht klar, warum Cookies dort benötigt werden.
Um diese Sicherheitsanfälligkeit auszunutzen, muss der Browser natürlich die ActiveX-Ausführung zulassen. Weitere Informationen zu dieser Sicherheitsanfälligkeit finden Sie hier: http://greyhatsecurity.org/abusiveparent-discussion.htm.

Wie können Sie sich schützen?

Der Schutz vor domänenübergreifendem Scripting ist nicht so einfach. Weil Die Ausnutzungsmöglichkeiten („Angriffsvektor“) dieser Sicherheitsanfälligkeiten sind sehr unterschiedlich, die meisten Maßnahmen werden sehr begrenzt und vorübergehend sein. Es ist fast unmöglich, alle "Angriffsvektoren" zu überschreiben. Daher werde ich einige Empfehlungen geben, die das Risiko eines erfolgreichen Angriffs nur verringern, aber nicht vollständig schützen können.
1. Beachtung der Sorgfalt beim Surfen im Internet.
Damit fast alle CDS-Varianten erfolgreich ausgeführt werden können, müssen Sie den ahnungslosen Benutzer zunächst auf die Exploit-Seite locken. Anschließend wird dieser Angriff ausgeführt. Sie können den Links nicht wie zufällig vertrauen, um die Konversation, die verschiedenen "Homepages" usw. einzuschalten. Dies ist wahrscheinlich die Hauptempfehlung von allen. Leider kann gut angewendetes XSS jede Vorsicht beseitigen.
2. Operative Installation von Patches für das Betriebssystem und den Browser.
In der Regel für alle im Internet veröffentlichten Schwachstellen des Herstellers (auch Microsoft :) ) gibt in kurzer Zeit eine Korrektur (Patch) frei. Es schützt vor dieser besonderen Sicherheitsanfälligkeit, jedoch nicht vor anderen, die noch nicht gefunden wurden (oder solchen, die entdeckt, aber nicht veröffentlicht wurden). Die in den Beispielen besprochenen Schwachstellen wurden natürlich schon lange von Microsoft behoben, und wer es will, hat sich bereits um seine Sicherheit gekümmert.
3. Deaktivieren Sie ActiveX und Active Scripting im Browser.
Diese Maßnahme macht es unmöglich, im ActiveX-Browser auszuführen und Java- oder VBS-Skripts auszuführen. Dadurch werden die meisten CDS-Angriffe ineffektiv, obwohl dies die Funktionalität der besuchten Websites erheblich beeinträchtigen kann. CDS erfordert jedoch nicht immer die Unterstützung von ActiveX oder Active Scripting für einen erfolgreichen Angriff - und dies ist kein Allheilmittel für alle Übel!
4. Arbeiten Sie im Internet nur mit eingeschränkten Rechten.
Die Umsetzung dieser Empfehlung ermöglicht es, auch im Falle eines erfolgreichen Angriffs den möglichen Schaden dadurch zu reduzieren. Wie Sie wissen, wird der Browser (und damit alle darin enthaltenen Skripte) mit den Rechten des aktuellen Benutzers ausgeführt. Lassen Sie den Hacker Vasya nicht cmd.exe mit Administratorrechten bekommen :) !
Das Befolgen all dieser Empfehlungen wird dazu beitragen, dass es schwierig wird, für Cross-Domain-Scripting anfällig zu werden!