DOM-based Cross Site Scripting - Clientseitige Angriffe im Browser

DOM-based Cross Site Scripting

Clientseitige Angriffe im Browser

Andrea Hauser
von Andrea Hauser
am 14. Dezember 2017
Lesezeit: 7 Minuten

Keypoints

Die unterschätzte XSS-Technik

  • DOM steht für Document Object Model
  • XSS steht für Cross Site Scripting
  • DOM based XSS unterscheidet sich zu den restlichen XSS Schwachstellen vor allem durch die Tatsache, dass die Payload auf der Clientseite eingebettet wird und nicht auf der Serverseite
  • Das Verhindern von DOM-based XSS Schwachstellen muss entsprechend auf dem Client geschehen

Bekannt geworden sind Cross Site Scripting (XSS) Schwachstellen durch das CERT Advisory CA-2000-02 (Malicious HTML Tags Embedded in Client Web Requests), ausgenutzt wurden die Schwachstellen allerdings schon zuvor. XSS besteht also schon seit einer Weile. Dementsprechend wurden schon mehrere Labs-Artikel zu diesem Thema veröffentlicht, unter anderem Cross Site Scripting – Die stets unterschätzte Gefahr sowie Cross-Site-Scripting und Script Injection verhindern – Ein kurzer Leitfaden. Der folgende Artikel konzentriert sich allerdings hauptsächlich auf DOM-based Cross Site Scripting, welches erst im Jahr 2005 durch Amit Klein geprägt wurde. Er veröffentlichte die Definition von DOM-based Cross Site Scripting (XSS) und dessen Abgrenzung zu anderen Cross Site Scripting Schwachstellen. Damit DOM based Cross Site Scripting verstanden werden kann, muss zuerst genauer darauf eingegangen werden, was das DOM ist.

Was ist das DOM

Beim Document Object Model handelt es sich um eine Programmierschnittstelle, welche die Struktur von Dokumenten vorgibt. In unserem Fall relevant ist, dass das DOM eine objektorientierte Repräsentation des HTML Dokuments vorgibt, die folgendes vorschreibt:

Damit gibt das DOM vor, wie HTML-Elemente im Browser gefunden, hinzugefügt, verändert oder gelöscht werden können. Das DOM bietet also die Möglichkeit HTML-Seiten zu manipulieren. Diese Manipulationen werden heutzutage in den allermeisten Fällen mithilfe von JavaScript durchgeführt.

Es ist zu erwähnen, dass verschiedene Browser in ihrer Implementation jeweils unterschiedlich vom DOM-Standard abweichen. Dies kann Auswirkungen darauf haben, ob ein spezifischer DOM-XSS-Angriff in einem Browser funktioniert.

Was ist DOM-based XSS

Eine DOM-based XSS Schwachstelle liegt vor, wenn mit Hilfe des DOMs dynamischer Inhalt generiert wird, welcher Benutzereingaben beinhält, die ungeprüft weiterverarbeitet werden. Ein entsprechender Angriff spielt sich im JavaScript im Browser des Benutzers ab. Dabei werden die Orte welche (bösartige) Benutzereingaben ins DOM übernehmen als Source bezeichnet. Die Orte an denen die (bösartigen) Benutzereingaben im DOM ausgeführt werden, werden Sink genannt.

Beispiel einer einfachen Cross Site Scripting-Schwachstelle:

<!DOCTYPE html>
<html>
    <body>
        <script>
            var source = "Hello " + decodeURIComponent(location.hash.split("#")[1]);  //Source
            var divElement = document.createElement("div");
            divElement.innerHTML = source;  //Sink
            document.body.appendChild(divElement);
        </script>
    </body>
</html>

Die Schwachstelle kann zum Beispiel mit der folgenden GET-Request ausgelöst werden:

GET www.vulnerable-website.example#<img src="test" onerror="alert('XSS')">

In diesem Beispiel ist zu beachten, dass die Methode decodeURIComponent eingesetzt werden muss. Dies hat damit zu tun, dass moderne Browser die Sonderzeichen in der URL codieren und der Angriff ohne die Decodierung der Sonderzeichen nicht mehr funktionieren würde. Der Inhalt der Variable source wird mit Hilfe von innerHTML dem div-Element hinzugefügt. Dies ist das problematische Element im Code, denn durch die Zuweisung an innerHTML wird der mitgegebene Wert als HTML interpretiert. Beinhaltet der Wert JavaScript, so wird dieses ebenfalls ausgeführt.

Es ist hervorzuheben, dass die Response des Servers nicht verändert wird. Die bösartige Modifikation entsteht erst dann, wenn auf der Clientseite JavaScript-Code ausgeführt wird, der den DOM nachträglich verändert.

Nachfolgend sind die bekanntesten Sources und Sinks aufgeführt. Es ist zu beachten, dass es sich dabei allerdings um keine vollständige Liste handelt.

Sources

Sinks

Verhindern von DOM-based XSS

Da es Fälle gibt, in denen der Payload gar nie bis zum Server gelangt, kann die Verhinderung dieser Schwachstelle nicht auf der Serverseite geschehen. Das Beispiel, welches weiter oben genutzt wurde, stellt genau einen solchen Fall dar. Grund dafür ist, dass Browser Inhalte, welche in der URL nach einem #-Zeichen auftreten, nicht an den Server senden.

Die erste und wichtigste Empfehlung ist, für das dynamische Erstellen von Inhalten so weit wie möglich keine vom Benutzer kontrollierten Daten zu verwenden. Falls dies allerdings nicht möglich ist, ist der beste Weg um DOM-based XSS zu verhindern, sichere Output-Methoden (Sink) zu benutzen, welche den allenfalls böswillig eingefügten Code nicht ausführen. Im oben aufgeführten Codestück ist das einzige was zu machen ist, um den Code sicher zu machen, das Ersetzen von .innerHTML durch .textContent. Denn bei der Methode textContent werden im Gegensatz zu innerHtml die HTML-Elemente nicht ausgeführt.

Im DOM based XSS Prevention Cheat Sheet von OWASP sind noch viele weitere gute Tipps für das Entwickeln von sicheren dynamischen Webseiten mit JavaScript aufgeführt. Dort werden auch die kontextabhängigen Codierungen beschrieben, welche benötigt werden, falls man nicht auf eine sichere Output-Methode ausweichen kann.

Unterschied zu restlichen XSS Schwachstellen

Der wichtigste Unterschied ist der Ort, an dem der Angriff in den Code eingefügt wird. Im Gegensatz zu den restlichen Cross Site Scripting-Schwachstellen wird der Code nicht serverseitig eingebettet, sondern auf der Seite des Clients. Das heisst, der Payload kann nicht im Response Code gefunden werden. Das Auffinden einer DOM-based XSS Schwachstelle kann also nur zur Laufzeit geschehen oder indem das DOM einer Seite untersucht wird.

Das Auffinden von DOM-based XSS-Schwachstellen ist in den meisten Fällen nicht trivial. Unterstützung hierbei bietet unter anderem Burp, welches dabei den Ansatz von statischer Codeanalyse verfolgt.

Über die Autorin

Andrea Hauser

Andrea Hauser hat ihren Bachelor of Science FHO in Informatik an der Hochschule für Technik Rapperswil abgeschlossen. Sie setzt sich im offensiven Bereich in erster Linie mit Web Application Security Testing und der Umsetzung von Social Engineering Kampagnen auseinander. Zudem ist sie in der Forschung zum Thema Deepfakes tätig. (ORCID 0000-0002-5161-8658)

Links

Sie wollen mehr als einen simplen Security Test mit Nessus und Nmap?

Unsere Spezialisten kontaktieren Sie gern!

×
GraphQL

GraphQL

Andrea Hauser

Server-Side-Request-Forgery

Server-Side-Request-Forgery

Andrea Hauser

Policy Analyzer

Policy Analyzer

Andrea Hauser

Sie wollen mehr?

Weitere Artikel im Archiv

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

Sie wollen mehr?

Weitere Artikel im Archiv