Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03515.jsonl.gz/2508

IT-Sicherheitstipps
Andrea Hauser
Die unterschätzte XSS-Technik
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.
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.
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.
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.
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.
Unsere Spezialisten kontaktieren Sie gern!
Andrea Hauser
Andrea Hauser
Andrea Hauser
Unsere Spezialisten kontaktieren Sie gern!
Weitere Artikel im Archiv