Cross-Site-Scripting (XSS)

Cross-Site-Scripting – auch XSS genannt – ist eine Anwendungsschwachstelle, die bei Anwendungen und Websites verheerenden Schaden anrichten kann. XSS ist so weit verbreitet und potenziell schädlich, dass es immer wieder in die Liste der 10 größten Sicherheitslücken des Open Web Application Security Project (OWASP) aufgenommen wird.

In der Tat ist Cross-Site Scripting die häufigste Schwachstelle, die seit 2014 entdeckt wurde, und im Jahr 2019 erscheint sie weiterhin in den Top 3 der gemeldeten Schwachstellen.

In einigen Fällen können auch browserseitige Skripte diese Schwachstelle einführen, so dass ein Angreifer sie ausnutzen kann, ohne dass der Zielbenutzer eine Anfrage an die Webanwendung stellt.

Angreifer nutzen XSS aus, indem sie bösartigen Code erstellen, der an einen anderen Benutzer weitergeleitet werden kann und dann vom ahnungslosen Browser ausgeführt wird. Da das Skript meist im Inhalt der Antwort der Webanwendung enthalten ist, wird es ausgeführt und hat den gleichen Zugriff, als ob es sich um ein legitimes Skript handelt. Es kann auf Sitzungs-Token, Cookies und sogar auf vertrauliche oder sensible Informationen zugreifen, auf die der Browser auf dieser Website Zugriff hat, und sogar den Inhalt der HTML-Seite umschreiben.

Reflektierte XSS-Angriffe

Bei reflektierten XSS-Angriffen wird das bösartige Skript in eine HTTP-Anfrage eingeschleust (in der Regel durch einen speziell gestalteten Link, der dem Benutzer bereitgestellt wird). In der einfachsten Variante werden Eingabeparameter in der HTTP-Anfrage verwendet, die leicht manipuliert werden können, um den schädlichen Skriptinhalt einzuschließen. Das bösartige Skript wird dann vom Server in einer HTTP-Antwort reflektiert und im Browser des Opfers ausgeführt.

In diesem Fall handelt es sich um einen gespeicherten XSS, ohne dass tatsächlich bösartige Daten auf dem Server gespeichert werden.

Hier ein Beispiel für einen Reflected XSS-Angriff:

Angenommen, example.com/profile enthält einen Namensparameter. Die URL für die Anfrage würde wie folgt aussehen: https://example.com/profile?user=Tammy. Auf der Grundlage dieser Eingabe würde die Webanwendung also mit „Hi Tammy“ am oberen Rand der Seite antworten. Wenn die Parameter nicht validiert werden, um sicherzustellen, dass sie nur erwartete Daten enthalten, könnte ein Angreifer einen Benutzer dazu bringen, eine bösartige Version der URL wie diese zu besuchen: https://example.com/profile?user<script>some_malicious_code</script>.

Wenn die Antwort an den Browser gesendet wird, enthält sie das bösartige Skript, das dann im Browser ausgeführt wird, wahrscheinlich ohne dass der Benutzer es merkt. Dies ist ein Beispiel für einen reflektierten XSS-Angriff, da der bösartige Code sofort an den Benutzer „zurückgespiegelt“ wird, der die Anfrage stellt.

Gespeicherte XSS-Angriffe

Bei einem so genannten gespeicherten oder dauerhaften XSS-Angriff wird der bösartige Inhalt direkt zusammen mit der Antwort des Servers übermittelt, wenn der Benutzer eine Webseite lädt. Der Inhalt ist also bereits in der Datenbank der Website gespeichert (daher der Name für solche Angriffe). Die Benutzer rufen dann einfach die gehackte Webseite auf und werden Opfer solcher Angriffe.

Jeder einzelne Benutzer, der eine solche kompromittierte Webseite öffnet, läuft somit Gefahr, dass seine persönlichen Daten gestohlen werden, weshalb dies als die gefährlichste Art von XSS-Angriffen angesehen werden kann.

Aber wie gelangt der bösartige Inhalt überhaupt in die Datenbank? In den meisten Fällen wird er über ungeschützte Webseitenformulare eingeführt, in denen die Benutzereingaben nicht ordnungsgemäß validiert und bereinigt werden. Wenn die von einem Hacker eingegebenen Daten nicht sowohl auf der Client- als auch auf der Serverseite validiert werden, werden sie in der Datenbank gespeichert. Solche Eingaben können beispielsweise in einem Kommentar-Textbereich, einem Texteditor für Beiträge, einem Editor für persönliche Daten oder anderen Formularen erfolgen.

Wenn es einem Angreifer gelingt, bösartige Inhalte an den Server zu senden, und diese Inhalte ungefiltert auf einer Webseite erscheinen, werden alle Benutzer zu potenziellen Opfern.

Das übliche Mittel gegen gespeicherte XSS-Angriffe besteht darin, Eingaben sowohl am vorderen Ende als auch am hinteren Ende der Anwendung zu bereinigen. Die Bereinigung umfasst eine Kombination aus der Validierung von Daten und dem Ausblenden von Sonderzeichen oder dem vollständigen Herausfiltern dieser Zeichen und ist eine gängige Best Practice für Web- und JavaScript-Sicherheit.

DOM-basierte XSS-Angriffe

Document Object Model (DOM) ist eine Schnittstelle, die es Anwendungen ermöglicht, die Struktur einer Webseite, ihren Inhalt und Stil zu lesen und zu manipulieren. Bei einem DOM-basierten XSS-Angriff liegt die Schwachstelle im Browser-seitigen Skriptcode und kann ohne jegliche Serverinteraktion ausgenutzt werden, indem die Umgebung im Browser des ahnungslosen Opfers verändert wird.

Gelegentlich ähneln DOM-basierte XSS-Angriffe reflektierten Angriffen. Das obige Beispiel eines reflektierten XSS-Angriffs lässt sich in diesem Fall mit einer einzigen Annahme anwenden: Die Webanwendung liest Daten direkt aus einem Query-String.

Angenommen, die Anwendung verwendet den Query-Parameter „name“, um den Namen des Benutzers sofort auf dem Bildschirm anzuzeigen, während sie darauf wartet, dass der Rest der Seite geladen wird. Ohne ordnungsgemäße Validierung kann dies zu demselben Ergebnis führen wie ein reflektierter Angriff, wenn es dem Hacker gelingt, das Opfer dazu zu bringen, einen verdächtigen Link zu öffnen.

Wie bei gespeichertem XSS sollten Entwickler, um reflektierte und DOM-basierte Angriffe zu verhindern, eine Datenvalidierung implementieren und die Anzeige von rohen Benutzereingaben vermeiden, unabhängig davon, ob eine Kommunikation mit dem Server stattfindet oder nicht.

Welche Angriffsvektoren gibt es für Cross-Site-Scripting?

Es gibt mehrere Vektoren, die häufig bei XSS-Angriffen verwendet werden:

• <script> Tag: Ein Skript-Tag kann verwendet werden, um auf externen JavaScript-Code zu verweisen, wodurch dies der einfachste XSS-Punkt ist. Angreifer können den bösartigen Code auch in den Script-Tag einbetten.
• JavaScript-Ereignisse: Ein weiterer beliebter XSS-Vektor, der von Angreifern genutzt wird, sind Ereignisattribute, die in einer Vielzahl von Tags eingesetzt werden können. Solche Attribute wie „onerror“ und „onload“ sind Beispiele.
• <body> tag: Ereignisattribute können auch die Quelle des Skripts sein, wenn sie über den „body“-Tag bereitgestellt werden.
• <img> tag: Je nach verwendetem Browser kann dieses Attribut von Angreifern genutzt werden, um den JavaScript-Code auszuführen.
• <iframe> tag: Besonders effektiv für Phishing-Angriffe, erlaubt dieser Vektor dem XSS-Angriff, eine andere HTML-Seite in die aktuelle Seite einzubetten.
• <input> tag: Einige Browser erlauben Manipulationen über diesen Vektor, der zur Einbettung eines Skripts verwendet werden kann.
• <link> tag: Dieser Tag kann ein Skript enthalten, anstatt der normalen Verwendung von Links zu externen Stylesheets.
• <table> tag: Wo das Hintergrund-Attribut normalerweise auf ein Bild verweist, könnte dies kompromittiert werden, um auf das anstößige Skript zu verweisen.
• <div> tag: Dieser Tag enthält ebenfalls einen Hintergrundverweis und kann wie <table> verwendet werden, um auf ein Skript zu verweisen.
• <object> tag: Skripte von einer externen Website können mit diesem Tag eingebunden werden.

Es gibt zwar noch andere Vektoren, die XSS-Angreifer verwenden, um Informationen zu stehlen und Websites zu kompromittieren, aber dies sind einige der am häufigsten verwendeten Methoden. Um sich vor solchen Angriffen zu schützen, müssen die Entwickler angemessene Escape- und Sanitizing-Verfahren einhalten.

Abhängig vom Angreifer und seinen böswilligen Absichten können XSS-Angriffe unterschiedliche Auswirkungen haben, darunter:

• Kapern der Sitzung eines Benutzers, Verwendung von Anmeldeinformationen, um auf andere Websites zuzugreifen oder den Benutzer auf unbeabsichtigte Websites umzuleiten,
• Veränderung von Webseiten oder Einfügen von Abschnitten in eine Webseite,
• Ausführen von Skripten, um sensible Informationen aus Cookies oder Datenbanken zu extrahieren,
• wenn das Opfer über administrative Rechte verfügt, kann sich der Angriff auf die Serverseite ausweiten und weiteren Schaden verursachen oder zusätzliche sensible Informationen abrufen.

Zu den wichtigsten Schritten beim Testen auf XSS-Schwachstellen für kritische Webanwendungen gehören:

• Einsatz eines Code-Scanning-Tools zum Aufspüren von Schwachstellen, die Code-Korrekturen während des Entwicklungsprozesses ermöglichen,
• Implementierung automatisierter Testfunktionen, die potenzielle Schwachstellen gründlich und schnell aufdecken.

Sagen wir, exmple.com/profile enthält einen Namensparameter. Die URL für die Anfrage würde wie https://example.com/profile?user=Tammy aussehen. Die Webanwendung antwortet mit „Hi Tammy“ am Anfang der Seite auf der Grundlage dieser Eingabe.

Wenn der Benutzerparameter nicht validiert wird, um sicherzustellen, dass er nur erwartete Daten enthält, könnte ein Angreifer einen Benutzer dazu bringen, eine bösartige Version der URL zu besuchen, die wie folgt aussieht:
https://example.com/profile?user<script>some_malicious_code</script>.
Wenn die Antwort an den Browser gesendet wird, enthält sie das bösartige Skript, das dann im Browser ausgeführt wird, wahrscheinlich ohne dass der Benutzer es merkt. Dies ist ein Beispiel für einen reflektierten XSS-Angriff. Der bösartige Code wird sofort an den Benutzer „zurückgespiegelt“, der die Anfrage gestellt hat.

• Ausbildung und Bewusstsein: Stellen Sie sicher, dass alle Entwickler, Website-Designer und QA-Teams die Methoden kennen, die Hacker verwenden, um Schwachstellen auszunutzen, und stellen Sie Richtlinien und bewährte Verfahren für die Codierung bereit. Dazu gehört auch die korrekte Escape-/Codierungstechnik für die Anwendungsumgebung (JavaScript, HTML usw.).
• Eingaben bereinigen: Egal, ob es sich um interne Webseiten oder öffentliche Websites handelt, vertrauen Sie niemals auf die Gültigkeit von Benutzereingabedaten. Prüfen und validieren Sie alle Datenfelder, insbesondere wenn sie in die HTML-Ausgabe aufgenommen werden.
• Code scannen: Implementieren Sie Software, die den Code auf Schwachstellen, einschließlich Cross-Site-Scripting, überprüft, um sicherzustellen, dass bewährte Verfahren befolgt werden, und minimieren Sie die Gefährdung durch XSS und andere von OWASP gelistete Schwachstellen.
• Content Security Policy: Verwenden Sie Content Security Policy (CSP), um zu definieren, was eine Website tun kann, und reduzieren Sie dadurch das Risiko eines XSS-Angriffs. Durch die Verwendung von CSP kann XSS vollständig blockiert (durch Blockieren aller Inline-Skripte) oder auf ein wesentlich geringeres Risiko reduziert werden.

OWASP bietet zusätzliche Anleitungen zur Vermeidung von XSS-Schwachstellen mit einem umfassenden Spickzettel.