Articles

DOM-basiertes Cross Site Scripting

Posted on

Die weniger bekannte XSS-Technik

  • DOM steht für Document Object Model
  • XSS steht für Cross-Site Scripting
  • Der Hauptunterschied zwischen DOM-basiertem XSS und anderen XSS-Schwachstellen besteht darin, dass die Nutzlast auf der Clientseite und nicht auf der Serverseite eingebettet ist
  • DOM-basierte XSS-Schwachstellen müssen daher auf der Clientseite verhindert werden

Cross-Site Scripting (XSS) Schwachstellen zuerst wurde durch das CERT Advisory CA-2000-02 (Malicious HTML Tags Embedded in Client Web Requests) bekannt, obwohl diese Sicherheitsanfälligkeiten zuvor ausgenutzt wurden. XSS gibt es also schon eine Weile. Und wie zu erwarten, gab es bereits eine Reihe anderer Artikel zu diesem Thema, darunter Cross Site Scripting – Die unterschätzte Gefahr und Cross Site Scripting und Preventing Script Injection – Eine kurze Anleitung. Dieser Artikel konzentriert sich jedoch hauptsächlich auf DOM-basiertes Cross-Site-Scripting, ein Begriff, der erstmals 2005 von Amit Klein geprägt wurde. Er veröffentlichte die Definition von DOM-basiertem Cross-Site-Scripting (XSS) und unterschied sie von anderen Cross-Site-Scripting-Schwachstellen. Um DOM-basiertes Cross-Site-Scripting zu verstehen, benötigen Sie zunächst ein tieferes Verständnis von DOM.

Was ist DOM?

Das Document Object Model ist eine Programmschnittstelle, die die Struktur von Dokumenten definiert. Was für unsere Zwecke relevant ist, ist, dass DOM die objektorientierte Darstellung von HTML-Dokumenten ermöglicht, insbesondere:

  • Wie ein HTML-Element als Objekt dargestellt wird
  • Was sind die Attribute eines HTML-Elements
  • Mit welchen Methoden kann auf ein HTML-Element zugegriffen werden
  • Was sind die Ereignisse eines HTML-Elements

Dies bedeutet, dass DOM angibt, wie HTML-Elemente im Browser gefunden, hinzugefügt, geändert oder gelöscht werden können. Das bedeutet, dass DOM die Möglichkeit bietet, HTML-Seiten zu bearbeiten. Heutzutage wird JavaScript normalerweise für diese Art der Manipulation verwendet.

Es ist zu beachten, dass jeder Browser den DOM-Standard unterschiedlich implementiert. Dies kann sich darauf auswirken, ob ein bestimmter DOM XSS-Angriff in einem bestimmten Browser funktioniert.

Was ist DOM-basiertes XSS?

Eine DOM-basierte XSS-Sicherheitsanfälligkeit tritt auf, wenn das DOM zum Generieren dynamischer Inhalte verwendet wird, die Benutzereingaben enthalten, die ohne Überprüfung verarbeitet werden können. Diese Art von Angriff wird mit JavaScript im Browser des Benutzers ausgeführt. Hier werden die Orte, die (böswillige) Benutzereingaben in das DOM bringen, als Quelle bezeichnet. Die Orte, an denen (böswillige) Benutzereingaben im DOM ausgeführt werden können, werden als Sink bezeichnet.

Ein Beispiel für eine einfache Cross-Site Scripting Schwachstelle:

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

Die Sicherheitsanfälligkeit kann beispielsweise mit der folgenden GET-Anforderung ausgelöst werden:

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

Wir können sehen, dass dieses Beispiel die Verwendung der decodeURIComponent -Methode erfordert. Dies liegt daran, dass moderne Browser Sonderzeichen in der URL kodieren und der Angriff ohne die Dekodierung dieser Sonderzeichen nicht funktionieren würde. Der Inhalt der Variablen source wird dem div-Element mit innerHTML hinzugefügt. Dies ist das problematische Element im Code, da seine Zuweisung zu innerHTML dazu führt, dass der darin enthaltene Wert als HTML interpretiert wird. Wenn der Wert JavaScript enthält, wird dies ebenfalls ausgeführt.

Es sollte darauf hingewiesen werden, dass dies die Serverantwort nicht ändert. Die böswillige Änderung tritt nur auf, wenn der JavaScript-Code auf der Clientseite ausgeführt wird, den das DOM anschließend ändert.

Die bekanntesten Quellen und Senken sind unten aufgeführt. Es sei darauf hingewiesen, dass dies keineswegs eine erschöpfende Liste ist.

Quellen

  • Dokument.URL
  • Dokument.referrer
  • Standort
  • Standort.href
  • Ort.suche
  • Standort.hash
  • Ort.pfadname

Senken

  • eval
  • setTimeout
  • setInterval
  • Dokument.schreiben
  • Element.innerHTML

DOM-basiertes XSS verhindern

Da es Fälle gibt, in denen die Nutzlast den Server nie erreicht, ist das Verhindern dieser Sicherheitsanfälligkeit keine Aufgabe für die Serverseite. Das obige Beispiel ist ein solcher Fall. Der Grund dafür ist, dass Inhalte, die nach einem # -Zeichen angezeigt werden, vom Browser nicht an den Server gesendet werden.

Die erste und wichtigste Empfehlung ist, möglichst keine nutzergesteuerten Daten für die dynamische Generierung von Inhalten zu verwenden. Wenn dies völlig unvermeidlich ist, ist der beste Weg, DOM-basiertes XSS zu verhindern, die Verwendung sicherer Ausgabemethoden (Sink), die die Ausführung von böswillig eingebettetem Code verhindern. Im obigen Codeausschnitt besteht die einzige Möglichkeit, den Code sicher zu machen, darin, .innerHTML durch .textContent zu ersetzen. Dies liegt daran, dass – im Gegensatz zu innerHtml – HTML-Elemente in der textContent -Methode nicht ausgeführt werden.

Der DOM based XSS Prevention Cheat Sheet von OWASP enthält viele nützliche Tipps für die Entwicklung sicherer dynamischer Websites mit JavaScript. Dort finden Sie auch Beschreibungen der kontextabhängigen Codierung, die immer dann erforderlich ist, wenn es unmöglich ist, zu einer sicheren Ausgabemethode zu wechseln.

Unterschiede zu anderen XSS-Schwachstellen

Der wichtigste Unterschied besteht darin, wo der Angriff in den Code eingebettet ist. Im Gegensatz zu anderen Cross-Site-Scripting-Schwachstellen ist der Code nicht auf der Serverseite, sondern auf der Clientseite eingebettet. Dies bedeutet, dass die Nutzlast nicht im Antwortcode gefunden werden kann. DOM-basierte XSS-Schwachstellen können daher nur zur Laufzeit oder durch Überprüfung des Doms der Website erkannt werden.

In den meisten Fällen ist es nicht einfach, DOM-basierte XSS-Schwachstellen zu finden. Ein hilfreicher Ansatz, der den Ansatz der statischen Codeanalyse verwendet, wird im Artikel Burp based-xss beschrieben.

Über den Autor

 Andrea Hauser

Andrea Hauser schloss ihr Studium mit einem Bachelor of Science FHO in Informationstechnologie an der Fachhochschule Rapperswil ab. Sie konzentriert ihre offensive Arbeit auf Web Application Security Testing und die Realisierung von Social Engineering Kampagnen. Ihr Forschungsschwerpunkt ist die Erstellung und Analyse von Deepfakes. (ORCID 0000-0002-5161-8658)

Links

  • http://www.webappsec.org/projects/articles/071105.html
  • https://support.portswigger.net/customer/portal/articles/2325926-using-burp-scanner-to-test-for-dom
  • https://www.cert.org/historical/advisories/CA-2000-02.cfm
  • https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet
  • https://www.w3.org/DOM/

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.