Aus einer hohen Perspektive betrachtet, kann Cross-Site Scripting (kurz: XSS) als das Einbetten von fremdem Code in einen vertrauenswürdigen Kontext zur Ausführung beschrieben werden. Technisch gesehen handelt es sich bei XSS um einen clientseitigen Injection-Angriff, bei dem ein Angreifer versucht, bösartigen Code im Webbrowser des Opfers auszuführen, indem er meist schädliches JavaScript in eine legitime Webseite oder Webanwendung einschleust. Der eigentliche Angriff erfolgt, wenn das Opfer die Ziel-Webanwendung besucht, die den bösartigen Code ausführt. Es ist wichtig zu verstehen, dass die Webanwendung lediglich als Vehikel dient, um den schädlichen Code an den Benutzer zu liefern – die Webanwendung selbst wird nicht angegriffen. Typischerweise suchen Angreifer nach XSS-Schwachstellen in Webanwendungen, die Kommentare, Foren, Nachrichtenboards oder andere Komponenten ermöglichen, bei denen Benutzereingaben in den Seiteninhalt eingebettet werden.
Beim Verifizieren von XSS-Schwachstellen lösen Angreifer üblicherweise Alert-Boxen aus, um die Code-Ausführung im Browser zu demonstrieren. Eine solche Alert-Box nach einem erfolgreichen XSS-Angriff könnte folgendermaßen aussehen:
Diese Alert-Box wurde auf einer Demo-Webanwendung durch Aufruf des folgenden Links erzeugt:
https://x.x.x.x/search.php?keyword=cats<script>alert('XSS demo by e2 Security!')</script>
Wenn dies eine echte, für XSS-Angriffe anfällige Webanwendung wäre, könnte ein Angreifer nun den obigen Link an ein ausgewähltes Opfer senden, in der Hoffnung, dass dieses den Link aufruft. Da die Webanwendung die Benutzereingabe offenbar ohne jegliche Bereinigung oder Kodierung in ihren eigenen Kontext einbettet, wird ein bösartiges JavaScript wahrscheinlich im Browser des Opfers ausgeführt.
Was ist das Risiko?
Wenn eine XSS-Schwachstelle identifiziert wurde, wird ein Angreifer höchstwahrscheinlich versuchen, JavaScript einzuschleusen, da die Möglichkeiten enorm vielfältig sind. Dadurch könnte ein Angreifer versuchen:
- Session-Informationen zu stehlen, um selbst auf die Webanwendung zuzugreifen
- Aktionen innerhalb derselben oder einer anderen Webanwendung im Namen des Benutzers auszulösen – auch bekannt als Cross-Site Request Forgery (kurz: CSRF)
- Zugängliche Informationen zu exfiltrieren (z.B. persönliche Daten des angegriffenen Benutzers, Tastatureingaben (via Keylogger) etc.)
- Das System des Benutzers direkt anzugreifen, indem potenziell vorhandene Schwachstellen im verwendeten Webbrowser ausgenutzt werden
Während das Risiko, Opfer eines Cross-Site-Scripting-Angriffs zu werden, somit hauptsächlich bei den Nutzern von Webanwendungen liegt, könnte ein betroffenes Unternehmen potenziell Reputationsschäden und Datenschutzprobleme erleiden, wenn ihre Webanwendungen anfällig sind. Wenn ein XSS-Angriff jedoch Benutzer mit erweiterten Rechten innerhalb der Ziel-Webanwendung erreicht (z.B. Administrator-Konten) oder sogar Benutzer mit Zugang zum internen Unternehmensnetzwerk, könnte der verursachte Schaden erheblich höher sein.
Wie kann man das Problem beheben?
Die Organisation OWASP bietet Anleitungen für verschiedene Software- und Anwendungssicherheits-Anwendungsfälle. In ihrer Serie von Cheatsheets werden speziell entwickelte Regeln zur Vermeidung von XSS-Schwachstellen genannt. Bitte beachten Sie, dass wir hier nur einige davon kurz erwähnen, während die vollständige Liste auf der entsprechenden Website [1] zugänglich ist:
- Regel #0: Fügen Sie niemals nicht vertrauenswürdige Daten ein, außer an erlaubten Stellen
- Regel #1: HTML-Kodierung vor dem Einfügen nicht vertrauenswürdiger Daten in HTML-Element-Inhalte
- Regel #2: Attribut-Kodierung vor dem Einfügen nicht vertrauenswürdiger Daten in gewöhnliche HTML-Attribute
- Regel #6: HTML-Markup mit einer dafür konzipierten Bibliothek bereinigen
- Bonus-Regel #1: HTTPOnly Cookie-Flag verwenden
- Bonus-Regel #2: Content Security Policy implementieren
Obwohl in einigen Fällen eine Web Application Firewall beim Schutz gegen XSS-Angriffe unterstützen kann, gelten die von OWASP präsentierten Regeln langfristig als effektiver. Diese Regeln sind dazu gedacht, auf der Ebene der Webserver-Konfiguration und des Quellcodes der Webanwendung angewendet zu werden.
Beispiele aus der Praxis
Da XSS vergleichsweise einfach zu identifizieren ist, werden täglich viele Schwachstellen gemeldet. An dieser Stelle stellen wir zwei aktuelle Beispiele zu XSS-Schwachstellen vor, die nicht nur demonstrieren, wie man Alert-Boxen auslöst, sondern auch die Schwere und Komplexität bei der Ausführung und Behebung dieser Schwachstellen zeigen:
- Wie ein XSS-Bug in Google Chrome 2,5 Jahre zur Behebung brauchte [2]
- Verkettung mehrerer Schwachstellen (einschließlich XSS) zur Erreichung einer kritischen Remote Code Execution [3]
[1] https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html
[3] https://portswigger.net/daily-swig/pandora-monitoring-system-pwned-by-chained-vulnerability-exploit