XSS-Angriffe: die unsichtbare Bedrohung im Browser

XSS einfach erklärt

Von Cross-Site-Scripting spricht man, wenn es ein Angreifer schafft, dass eine Website schädlichen Code in eine Seite einbettet, die andere Besucher aufrufen. Der Browser vertraut dem Skript, weil es von einer eigentlich seriösen Domain kommt. Es läuft dann mit den Rechten des Opfers und kommt so an Cookies, Session-Tokens, Seiteninhalte oder DOM-Elemente.

Eine Analogie für alle, die nicht beruflich Code schreiben: Stell dir einen Zettel am schwarzen Brett einer Firma vor. Wenn niemand das Brett kontrolliert, kann jeder dort gefälschte Anweisungen anheften, denen Kolleginnen und Kollegen dann folgen. XSS ist die digitale Variante davon. Fremder Inhalt, der in einen vertrauten Rahmen eingeschmuggelt wird.

Drei Haupttypen (plus ein paar Sonderfälle)

Wer die Varianten kennt, ordnet Schwachstellen schneller ein. Drei Typen tauchen am häufigsten auf, dazu noch eine Handvoll Sonderfälle, die in echten Angriffen weiterhin vorkommen.

Stored XSS. Der Schadcode liegt auf dem Server (in einer Datenbank, einem CMS oder Ähnlichem) und wird an jeden Besucher ausgeliefert. Klassische Schauplätze sind Kommentarspalten und Support-Ticket-Systeme. Der Schaden fällt meist gross aus, weil jeder Mitlesende die Payload mit auslöst.

Reflected XSS. Der Schadcode wird vom Server direkt in der Antwort zurückgespielt, meist über URL-Parameter. Das Opfer klickt einen präparierten Link, der Server kippt die Eingabe in die Seite, und die Payload läuft.

DOM-basiertes XSS. Die Payload erreicht den Server überhaupt nicht. Sie wird vollständig im Browser ausgeführt und manipuliert dort das DOM. Der Server bekommt davon oft gar nichts mit, was die Erkennung erschwert und erklärt, warum dieser Typ in Vorfallsberichten immer wieder auftaucht.

Self-XSS (Nutzer dazu bringen, Skripte in die Konsole zu kopieren) und XS-Search (Suchformulare ausnutzen, um Zustände abzuleiten) zeigen sich auch in aktuellen Angriffen. Die Schutzmassnahmen sind im Kern dieselben wie gegen klassisches XSS.

So läuft ein XSS-Angriff Schritt für Schritt

Wer die typische Exploit-Kette einmal durchgeht, sieht schnell, an welchen Stellen sich gegensteuern lässt.

1. 1

   Einen Einstiegspunkt finden

   Der Angreifer sucht ein Formular, einen URL-Parameter oder ein gespeichertes Feld, das Eingaben ohne vernünftige Bereinigung zurückgibt.
2. 2

   Payload bauen

   Er schreibt JavaScript, das Cookies abgreift, DOM-Elemente manipuliert, Malware nachlädt oder Traffic umleitet.
3. 3

   Payload ausliefern

   Über einen präparierten Link, ein gekapertes Konto oder bereits gespeicherte Inhalte.
4. 4

   Im Browser des Opfers ausführen

   Der Browser vertraut der Payload, weil sie von der echten Domain kommt.
5. 5

   Daten abziehen oder nachsetzen

   Skripte schicken die Beute an Endpunkte des Angreifers oder ziehen weitere Malware nach.

Was Angreifer erreichen

XSS bedeutet längst mehr als nur Defacement. Moderne Kampagnen nutzen es für Angriffe mit echter Wucht, und vier Muster tauchen besonders oft auf.

Session-Hijacking. Authentifizierungs-Tokens werden gestohlen, um sich in Banking-Portalen, Admin-Dashboards oder SaaS-Plattformen als jemand anderes auszugeben. Der Nutzer merkt vom Diebstahl nichts.

Zugangsdaten abgreifen. Gefälschte Login-Formulare werden eingeschleust oder bestehende so manipuliert, dass Benutzername und Passwort schon im Browser abgefangen werden, bevor das echte Formular überhaupt abgeschickt ist.

Malware ausliefern. Über externe Skripte werden Ransomware oder Krypto-Miner nachgeladen. Das funktioniert besonders gut bei Lieferkettenangriffen, wenn ein bisher vertrauenswürdiges Drittanbieter-Skript kompromittiert wird.

Soziale Manipulation. Inhalte werden umgeschrieben oder Chat-Nachrichten eingeschleust, um Nutzer zu riskanten Aktionen oder Überweisungen zu bewegen. Wenn die vertraute Seite zur Überweisung auffordert, wird überwiesen.

Fünf Fälle aus verschiedenen Branchen

Die folgenden Vorfälle (zusammengetragen aus öffentlichen Berichten und Fachpresse) zeigen, wie breit das Schadenspotenzial von XSS gefächert ist.

Medienplattform (2024). Ein XSS in der Kommentarmoderation erlaubte es Angreifern, automatisch Scam-Kanäle zu liken. Der Reputationsschaden war spürbar: sieben Prozent weniger Vertrauen bei den Abonnenten und eine Woche Aufräumarbeit.

E-Commerce-Marktplatz (2023). Ein Reflected XSS in Gutscheincodes lenkte Käufer auf gefälschte Checkout-Seiten um. Schaden: 4,1 Mio. Dollar an betrügerischen Buchungen, bis das Team das Muster durchschaute.

Patientenportal im Gesundheitswesen (2022). Ein Stored XSS im Patientenmessaging griff Session-Cookies ab und legte Laborergebnisse offen. Folge: eine HIPAA-Meldung und ein Vergleich über 1,2 Mio. Dollar.

Banking-App (2021). DOM-basiertes XSS in Widgets schleuste nicht autorisierte Überweisungsanträge ein. Eine schnelle SOC-Reaktion verhinderte den finanziellen Schaden, der Vorfall zog jedoch ein monatelanges aufsichtsrechtliches Audit nach sich.

Behörden-CMS (2020). Eine alte XSS-Lücke in einem Legacy-CMS machte das Defacement kommunaler COVID-19-Mitteilungen möglich. Der Schaden liess sich mitten in einer Krise nicht in Dollar messen, sondern im verlorenen öffentlichen Vertrauen.

Warum XSS 2025 immer noch funktioniert

Trotz moderner Frameworks steht XSS Jahr für Jahr in den OWASP Top 10. Die Gründe sind strukturell, nicht technisch.

In riesigen Codebasen wird weiterhin mit String-Verkettung und veralteten Template-Engines gearbeitet. Drittanbieter-Widgets (Marketing-Pixel, Chatbots, Analytics) bringen Angriffsfläche mit, die das Security-Team gar nicht kontrollieren kann. Neue Engineering-Teams übernehmen unsichere Muster, ohne die Vorfälle zu kennen, die den Code geformt haben. Automatisierte Scanner übersehen DOM-basierte Payloads, weil sie die serverseitig gerenderte Ausgabe prüfen und nicht das lebende DOM, und manuelle Pentests schauen meist woandershin.

Schutz im Alltag

Das Internet lässt sich nicht patchen, aber du kannst den möglichen Schaden klein halten. Vier Gewohnheiten decken den Grossteil des realen Risikos ab.

Öffne fragwürdige Links in Browser.lol, damit erst gar kein Skript auf deinem Rechner läuft. Deaktiviere Browser-Erweiterungen, die du nicht wirklich brauchst, denn viele vergrössern die XSS-Angriffsfläche. Halte deinen Browser aktuell; eine moderne Content Security Policy (CSP) blockiert Inline-Skripte und viele klassische XSS-Techniken. Melde dich aus sensiblen Diensten ab, wenn du sie gerade nicht brauchst. Gestohlene Cookies sind wertlos, sobald die Session abgelaufen ist.

Checkliste für Entwickler und Security-Teams

Wer Web-Apps baut oder pflegt, bekommt mit fünf Massnahmen den grössten Hebel.

Ausgaben kontextabhängig escapen. HTML, JavaScript, URL und CSS verlangen jeweils eigene Escaping-Regeln. Eine generische "Sanitize"-Funktion lässt fast immer eine Kategorie ungeschützt.

Frameworks mit eingebauter Bereinigung nutzen. React, Vue und Angular reduzieren direkte DOM-Manipulation und machen den sicheren Weg zum Default.

Content Security Policy umsetzen. Beschränke die zulässigen Skript-Quellen und untersage Inline-Skripte, wo es geht. CSP gehört zu den wirksamsten Schutzmechanismen, die je in einen Browser eingezogen sind.

Security-Linter und SAST-Tools einsetzen. ESLint-Security-Plugins, Semgrep und SonarQube finden typische Muster früh, wenn die Korrektur noch günstig ist.

Regelmässige Security-Reviews einplanen. Nimm XSS-Payload-Labs in QA und Bug-Bounty-Scope auf. Wer Browser.lol in die QA integriert, kann unsichere Proof-of-Concept-Payloads gefahrlos ausführen, ohne die Entwicklerrechner aufs Spiel zu setzen.

Skripte eindämmen, Risiko in den Griff bekommen

XSS wird nicht verschwinden. Mit jedem Widget, jedem Marketing-Pixel und jeder Drittanbieter-Integration wächst die Angriffsfläche weiter. Machtlos bist du deshalb aber nicht. Sauberer Code verhindert Lücken, proaktive Hygiene begrenzt die Angriffsfläche, und virtuelle Browser sorgen dafür, dass selbst ein ausgeführtes Schadskript deine Hardware nie zu sehen bekommt.

Behandle jede unbekannte Seite als möglichen XSS-Vektor. Surfe in einer isolierten Umgebung, halte Zugangsdaten und Cookies sauber getrennt, und dränge dein Team dazu, die Ursachen wirklich zu beheben. So verhinderst du, dass aus unsichtbaren Skripten Millionenschäden werden.