In diesem Beitrag zu unserer Reihe zur OWASP Top Ten, den häufigsten Sicherheitslücken in Webapplikationen, wird das sogenannte Cross-Site-Scripting (kurz XSS) näher erläutert.
XSS bezeichnet eine Angriffsmethode, bei der eine Webapplikation Benutzereingaben wiedergibt, ohne diese zu überprüfen. Dadurch kann ein Angreifer Schadcode an den Browser eines Benutzers übermitteln, wobei es sich um JavaScript-Code handelt. JavaScript wird clientseitig, d.h. im Browser des Benutzers, interpretiert bzw. ausgeführt und häufig in interaktiven Webapplikationen verwendet. Im Prinzip handelt es sich daher um einen Injection-Angriff, wobei der injizierte Schadcode nicht vom Webserver, sondern vom Browser ausgeführt wird.
Mit dem in einer XSS-Attacke übermittelten Schadcode können z.B. sensible Cookies mit Session-Informationen ausgelesen oder auch Sicherheitslücken im Browser ausgenutzt werden, um auf das System des Benutzers vorzudringen.
XSS-Beispiel
Eine Webapplikation fordert den Benutzer zur Eingabe eines Namens und einer Adresse auf:
Diese Daten werden nach Abschicken des Formulars durch den Benutzer auf einer Website dargestellt. Der entsprechende HTML-Code kann z.B. so aussehen:
<h1>Ihre Daten:</h1>
<p>Name: Erika Mustermann<p>
<p>Straße: Heidestr. 17<p>
<p>PLZ und Ort: 51147 Köln<p>
Die Darstellung dieses Codes im Browser sieht folgendermaßen aus:
Ein potentieller Angreifer kann jetzt JavaScript-Code in diesem Formular unterbringen, in der Hoffnung, dass der entsprechende Schadcode nach dem Abschicken vom Browser des aufrufenden Benutzers ausgeführt wird:
Der Angreifer gibt dabei als Namen die Codezeile <script>alert(‚XSS‘)</script> ein. Sofern die Webanwendung, welche die Kontaktdaten darstellt, für XSS verwundbar ist, würde der resultierende HTML-Code folgendermaßen aussehen:
<h1>Ihre Daten:</h1>
<p>Name: <script>alert(‚XSS‘)</script><p>
<p>Straße: Heidestr. 17<p>
<p>PLZ und Ort: 51147 Köln<p>
Wird dieser von einem Browser interpretiert, führt er den JavaScript-Befehl alert(‚XSS‘) aus, welcher eine kleine Dialogbog erzeugt:
Die Darstellung einer Dialogbox ist dabei zwar keine große Gefahr, ein realer Angreifer könnte jedoch beliebigen Schadcode übermitteln, welcher wie oben angesprochen bis zur kompletten Kompromittierung des Benutzersystems führen kann.
Reflected vs. Stored XSS
Bei XSS-Angriffen wird zwischen zwei Angriffsarten unterschieden. Sofern ein temporärer Parameter, wie z.B. ein Suchbegriff, betroffen ist und der Angriff somit vom Benutzer selbst durch den Aufruf eines präparierten Links initiiert werden muss, spricht man von sogenannten „reflected XSS-Angriffen“. Wenn, wie in dem oben gezeigten Beispiel, die manipulierten Parameter persistent im Webauftritt gespeichert sind (z.B. über eine XSS-verwundbare Kommentarfunktion) und von jedem Besucher einer Webseite ausgeführt werden, handelt es sich um einen „stored XSS-Angriff“.
Gegenmaßnahmen
Analog zu Injection-Angriffen gilt auch hier der Grundsatz: Vertraue niemals Benutzerdaten. Die Eingabe von XSS-Schadcode kann wirkungsvoll verhindert werden, indem Benutzereingaben zum einen bei der Eingabe validiert und zum anderen alle Sonderzeichen bei der Ausgabe korrekt zu sogenannten HTML-Entitäten encodiert werden. HTML-Entitäten werden vom Browser nicht als Code interpretiert bzw. ausgeführt, sondern stellen lediglich das entsprechende Zeichen dar. Der HTML Code mit encodierten Entitäten sähe dann z.B. so aus:
<h1>Ihre Daten:</h1>
<p>Name: <script>alert('XSS')</script><p>
<p>Straße: Heidestr. 17<p>
<p>PLZ und Ort: 51147 Köln<p>
Weitere, detaillierte Gegenmaßnahmen finden sich in den OWASP Top Ten Dokumenten zu XSS.
Zusammenfassung
XSS ist eine der häufigsten Sicherheitslücken in Webapplikationen, die aufgrund der fehlenden Filterung von Benutzereingaben für weiterführende Angriffe verwendet werden kann, wie z.B. die Umleitung des Browsers auf schadhafte Webseiten, das Auslesen und Übermitteln von Session Cookies oder die Kompromittierung eines unsicheren Browsers. In unseren Webapplikations-Penetrationstests prüfen wir daher sowohl stored als auch reflected XSS-Lücken.