Security-Kolumne

DOMXSS – Angriffe aus dem Nirgendwo
Kommentare

Eine der am meisten unterschätzten und am häufigsten belächelten Klassen an Sicherheitslücken ist ohne Zweifel das DOM-basierte Cross Site Scripting, kurz DOMXSS. Als kleiner Bruder vom „echten“ XSS, der über GET oder POST hereinpoltert und seine Spuren im Client wie auch meist den Serverlogs hinterlässt, hat man es auch nicht leicht. Herkömmliches Cross Site Scripting hat in den letzten Wochen und Monaten viel Presse bekommen – und ist unter Sicherheitsexperten spätestens seit Samy Kamkars mehr oder weniger böswilligen Angriff auf MySpace im Jahre 2005 bekannt.

Viele XSS-Würmer sind seitdem durchs Netz getobt – und spätestens der Ende 2010 grassierende Twitter-Wurm war erneut ausgezeichnetes Beispiel für die mögliche Schlagkraft eines gut durchdachten Cross-Site-Scripting-Angriffs. Wer aufmerksam war und den Ausbruch des Wurms rechtzeitig mitbekommen hatte, konnte in der Twitter-Live-Suche mitverfolgen, wie die Infektionsrate anwuchs und mehr und mehr User den Wurm – glücklicherweise ein harmloses Exemplar ohne echten Payload – unbewusst auf ihrem Profil speicherten und so die Weiterverbreitung unterstützten. Man musste einfach mal direkt auf twitter.com nach onmouseover=“ suchen und schon bekam man den Wurm in Aktion präsentiert.

Von DOMXSS hat man aber wenig bis gar nichts dergleichen gehört. Hier und da taucht in Security-Foren eine kleine Meldung auf. CNN.com soll einen schwer zu fixenden DOMXSS gehabt haben – Twitter war ebenfalls nachgewiesenermaßen anfällig – und das für Monate. Und keiner hat es so wirklich gemerkt. Viel interessanter ist hier, dass Twitter insgesamt drei Anläufe gebraucht hat, um den DOMXSS Bug zu fixen. Der erste Fix – komplett invalide: der DOMXSS-Vektor kam in leichter Variation wieder durch und führte beliebiges JavaScript auf der twitter.com-Domain aus. Zweiter Fix: Besser, aber ebenfalls kaputt &ndahs; diesmal konnte man im Internet Explorer auf verschiedenen Wegen JavaScript einschleusen. Erst mit dem dritten Fix wurden alle bis dahin bekannten Probleme beseitigt – und die Plattform zumindest an dieser Stelle wieder abgesichert.

Wo ist das Problem?

Das Problem an der ganzen Sache ist: DOMXSS funktioniert grundlegend anders als das klassische Cross Site Scripting, das über GET, POST und andere Wege hereinkommt. Klar, es geht nach wie vor darum, Scriptcode auszuführen, jedoch helfen serverseitige Schutzmechanismen gegen DOMXSS wenig bis gar nicht. Die Annahme, DOMXSS sei schwer zu exploiten oder gar weniger gefährlich als klassisches XSS und vergleichbare Angriffstechniken, sind in der Security-Szene bedauerlicherweise verbreitet. Und gute Publikationen auf diesem Feld sind rar. Wenn man es ganz genau nimmt, gibt es derzeit nur eine Publikation zu diesem Thema, der man hohe Qualität zusprechen kann – ein Artikel von Amit Klein aus dem Jahre 2005. Dort wird ausführlich auf das Thema eingegangen und Schritt für Schritt erklärt, was DOMXSS ist – und welche Gefahren lauern. Die OWASP pflegt eine Wiki-Seite zum Thema DOM Based XSS, die aber kaum mehr als eine handvoll Vektoren auflistet und den Leser nicht wirklich schlauer macht. Zumindest sind aber gute Quellen aufgelistet und der mittlerweile dritte Name für diese Lücke angegeben – Type-0 XSS. Aber was ist nun genau DOMXSS – und warum lohnt es sich überhaupt, darüber zu schreiben?

DOMXSS im Überblick

Als DOMXSS-Attacken werden Angriffe bezeichnet, in denen der Bösewicht Daten einschleust, die JavaScript-Variablen oder DOM-Eigenschaften manipulieren und somit die Ausführung von beliebigem JavaScript-Code begünstigen oder ermöglichen. Dabei handelt es sich nicht um die klassischen Wege in die Applikation – wie der für XSS typische „Suchparameter“ (search.php?s=“>alert(1)) oder die für SQL Injections oft und gern genutzte ID (index.php?id=’or1=1). DOMXSS greift dabei die Applikation im Browser an – das Markup, das JavaScript und oft auch geladene Flash-Dateien oder gar Java Applets. DOMXSS-Angriffe richten sich nicht gegen den Server oder nutzen fehlerhafte Implementationen auf den Schichten PHP, Datenbank oder gar Webserver aus, hier geht es nur um den Client. Schutzsysteme, die auf dem Server laufen, nutzen gegen DOMXSS wenig – zumeist kommen die relevanten Informationen über einen Angriff sogar überhaupt nicht erst dort an.

DOMXSS hat viele Einfallstore und mehr oder weniger esoterische Wege, um JavaScript auszuführen. Das frisch begonnene DOMXSS Wiki strebt an, die gängigsten Wege zu enumerieren und zu beschreiben. Bei DOMXSS-Lücken betrachtet man zumeist zwei Komponenten. Einerseits eine „Source“, also die Quelle des Payloads und meist der Wert, den der Angreifer kontrollieren kann. Andererseits die „Sink“, also die Senke, in der die Daten weiterverwendet werden.

Autor

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -