XSS (Cross-Site Scripting) fuer Unternehmer erklaert

Was ist XSS, ohne Fachjargon

Cross-Site Scripting, allgemein als XSS abgekuerzt, ist eine Art von Angriff, bei dem jemand schadhaften JavaScript-Code in eine Website einschleust, sodass er in den Browsern anderer Personen ausgefuehrt wird. Wenn ein Besucher die betroffene Seite laedt, fuehrt sein Browser den Code des Angreifers aus, als waere er ein legitimer Teil der Website.

Denken Sie es sich so: Ihre Website ist ein Dokument, das die Browser Ihrer Besucher lesen und anzeigen. Wenn ein Angreifer seine eigenen Anweisungen in dieses Dokument einschleusen kann, wird der Browser jedes Besuchers diese Anweisungen befolgen. Der Browser kann nicht zwischen Ihrem legitimen Code und dem eingeschleusten Code des Angreifers unterscheiden. Er fuehrt alles aus.

XSS steht seit ueber zwanzig Jahren auf der OWASP Top 10 Liste der Sicherheitsrisiken fuer Webanwendungen. Trotzdem bleibt es eine der haeufigsten Schwachstellen. Der Grund ist einfach: XSS zu verhindern erfordert Disziplin an jedem einzelnen Punkt, an dem Daten in Ihre Anwendung ein- und ausgehen, und die meisten Entwickler halten diese Disziplin nicht konsequent ein.

Wie XSS funktioniert: Ein konkretes Beispiel

Das Szenario

Stellen Sie sich vor, Ihre Unternehmenswebsite hat eine Suchfunktion. Ein Benutzer tippt "Buerostuehle" in das Suchfeld, und die Seite zeigt an: "Sie haben gesucht nach: Buerostuehle" zusammen mit den Ergebnissen. Der Suchbegriff wird auf der Seite zurueckgespiegelt.

Wenn der Entwickler diese Eingabe nicht bereinigt oder kodiert hat, kann ein Angreifer eine spezielle Suchanfrage erstellen, die JavaScript-Code enthaelt. Wenn ein Opfer auf einen Link mit dieser praeparierten Suchanfrage klickt, fuehrt der Browser des Opfers den Code aus und sendet Session-Cookies an den Server des Angreifers. Mit diesen Cookies kann der Angreifer das Opfer imitieren.

Drei Arten von XSS

1. Reflektiertes XSS

Das schaedliche Skript ist Teil der Anfrage (normalerweise in einem URL-Parameter) und wird in der Antwort zurueckgespiegelt. Der Angriff erfordert, dass das Opfer auf einen speziell praeparierten Link klickt.

Persistenz: Keine. Der Angriff funktioniert nur, wenn das Opfer auf den spezifischen Link klickt.

2. Gespeichertes XSS

Dies ist die gefaehrlichere Variante. Das schaedliche Skript wird in der Datenbank der Website gespeichert und jedem Besucher angezeigt, der die betroffene Seite aufruft. Haeufige Injektionspunkte sind Kommentarfelder, Forenbeitraege, Benutzerprofile und Produktbewertungen.

Persistenz: Dauerhaft, bis der schaedliche Inhalt aus der Datenbank entfernt wird.

Schwere: Hoch bis kritisch. Jeder Besucher ist betroffen.

3. DOM-basiertes XSS

Dieser Typ tritt vollstaendig im Browser auf, ohne dass der schaedliche Payload an den Server gesendet wird. Die Schwachstelle liegt im clientseitigen JavaScript-Code, der URL-Fragmente oder andere browserseitige Datenquellen unsicher verarbeitet.

Was Angreifer mit XSS tun koennen

• Session-Hijacking: Der Angreifer stiehlt den Session-Cookie des Opfers und nutzt ihn, um es zu imitieren. Wenn das Opfer als Administrator eingeloggt ist, hat der Angreifer nun Admin-Zugang.
• Credential-Harvesting: Das Skript modifiziert die Login-Seite, um Zugangsdaten an einen externen Server zu senden, wenn sich der Benutzer anmeldet.
• Keylogging: Das injizierte Skript erfasst jeden Tastendruck des Benutzers, einschliesslich Passwoerter und Kreditkartennummern.
• Seitenverunstaltung: Das Skript kann den sichtbaren Inhalt der Seite aendern, Preise manipulieren, Produktbeschreibungen veraendern.
• Umleitung auf schaedliche Websites: Das Skript leitet den Besucher stillschweigend auf eine Phishing-Seite oder Malware-Verteilungsseite um.
• Kryptowaehrungs-Mining: Das Skript nutzt den Browser des Besuchers, um im Hintergrund Kryptowaehrung zu schuerfen.

Reale Beispiele von XSS in beliebten CMS-Plugins

• CVE-2024-4345 (Starter Templates von Brainstorm Force): Gespeichertes XSS, das ueber 1 Million WordPress-Installationen betrifft.
• CVE-2024-1071 (Ultimate Member Plugin): Gespeichertes XSS in Benutzerprofil-Feldern.
• CVE-2023-6961 (WP Meta SEO): Reflektiertes XSS in der Plugin-Einstellungsseite.
• Contact Form 7 (verschiedene CVEs): Mehrere XSS-Schwachstellen in einem der beliebtesten WordPress-Plugins mit ueber 5 Millionen aktiven Installationen.

Wie man XSS testet (sicher)

Einfacher manueller Test

Versuchen Sie, diese Zeichenkette in ein beliebiges Eingabefeld auf Ihrer Website einzugeben:

<script>alert('XSS')</script>

Wenn ein Popup-Fenster erscheint, ist diese Eingabe anfaellig fuer XSS. Wenn der Text als Klartext auf der Seite angezeigt wird, wird die Eingabe korrekt kodiert.

Probieren Sie auch diese Varianten:

• <img src=x onerror=alert('XSS')>
• <svg onload=alert('XSS')>

Kostenlose automatisierte Tools

• OWASP ZAP: Ein kostenloses Open-Source-Sicherheits-Scanning-Tool.
• Nikto: Ein Open-Source-Webserver-Scanner.

Praevention: Wie man XSS stoppt

1. Output-Encoding

Das ist die primaere Verteidigung. Jedes Mal, wenn benutzerdefinierte Daten in eine HTML-Seite eingefuegt werden, muessen sie kodiert werden, damit der Browser sie als Text behandelt, nicht als Code. Die meisten modernen Web-Frameworks bieten automatisches Output-Encoding standardmaessig an (React, Angular, Vue.js, Twig, Blade).

2. Input-Validierung

Validieren Sie alle Eingaben serverseitig. Wenn ein Feld eine E-Mail-Adresse enthalten soll, ueberpruefen Sie, ob sie dem E-Mail-Format entspricht, und lehnen Sie alles andere ab.

3. Content Security Policy (CSP)

Content Security Policy ist ein HTTP-Header, der dem Browser mitteilt, welche JavaScript-Quellen vertrauenswuerdig sind. Eine gut konfigurierte CSP kann die Ausfuehrung von XSS verhindern, selbst wenn es erfolgreich injiziert wird. Weitere Informationen zu Sicherheitsheadern finden Sie in unserem Artikel ueber HTTP-Sicherheitsheader fuer Websites.

4. HttpOnly- und Secure-Cookie-Flags

Das Setzen des HttpOnly-Flags auf Session-Cookies verhindert, dass JavaScript sie lesen kann. Das Secure-Flag stellt sicher, dass Cookies nur ueber HTTPS gesendet werden.

Warum die meisten Webentwickler in der Schweiz nicht auf XSS testen

• Sicherheit ist nicht Teil der Ausbildung. Die meisten Webentwickler lernen, Dinge zum Laufen zu bringen, nicht sie sicher zu machen.
• Sicherheitstests brauchen Zeit und sind nicht sichtbar. Eine sicherheitsgetestete Website sieht identisch aus wie eine ungetestete, hat aber mehr Stunden in der Entwicklung gekostet.
• CMS-Plugins werden als sicher angenommen. Diese Annahme ist weit oefter falsch, als sie sein sollte.
• Niemand fragt danach. Unternehmer fragen selten "Haben Sie auf XSS getestet?" waehrend eines Webprojekts.

Die geschaeftlichen Auswirkungen von XSS-Schwachstellen

Datendiebstahl

Wenn Ihre Website personenbezogene Daten verarbeitet, kann XSS zum Diebstahl dieser Daten verwendet werden. Gemaess dem Schweizer revDSG und der EU-DSGVO sind Sie fuer den Schutz personenbezogener Daten mit angemessenen technischen Massnahmen verantwortlich.

Rechtliche Haftung

Wenn Kundendaten ueber Ihre Website aufgrund einer bekannten Schwachstellenklasse gestohlen werden, die Sie nicht getestet haben, ist Ihre rechtliche Haftung erheblich.

Kundenvertrauen

Wenn Kunden entdecken, dass Ihre Website genutzt wurde, um ihre Zugangsdaten zu stehlen, ist der Vertrauensschaden schwer und langanhaltend.

SEO und Reputation

Google kennzeichnet aktiv Websites, die schaedliche Inhalte ausliefern. Ein XSS-Angriff, der Besucher umleitet, loest Google-Safe-Browsing-Warnungen aus.

Was Sie als Naechstes tun sollten

1. Fragen Sie Ihren Entwickler: "Welche Massnahmen haben Sie ergriffen, um XSS auf unserer Website zu verhindern? Koennen Sie mir die Testergebnisse zeigen?"
2. Pruefen Sie Ihre Sicherheitsheader: Besuchen Sie securityheaders.com und geben Sie Ihre Domain ein. Suchen Sie nach dem Content-Security-Policy-Header.
3. Lassen Sie eine Sicherheitsbewertung durchfuehren: Eine professionelle Sicherheitsbewertung identifiziert XSS-Schwachstellen und andere Probleme.
4. Implementieren Sie CSP: Selbst wenn Sie nicht sofort jede XSS-Schwachstelle beheben koennen, bietet eine Content Security Policy ein Sicherheitsnetz.
5. Ueberpruefen Sie Ihre Cookie-Einstellungen: Stellen Sie sicher, dass Session-Cookies die HttpOnly- und Secure-Flags gesetzt haben.

XSS ist eine jener Schwachstellen, die abstrakt erscheinen, bis sie Ihnen passieren. Aber die Ausnutzung ist real, der Schaden ist messbar, und die Praevention ist gut etabliert. Es gibt keinen Grund, warum eine Unternehmenswebsite im Jahr 2025 anfaellig fuer XSS-Angriffe sein sollte.

Wenn Sie Hilfe bei der Bewertung der XSS-Gefaehrdung Ihrer Website oder bei der Implementierung von Schutzmassnahmen benoetigen, kontaktieren Sie uns. Wir helfen Schweizer Unternehmen, Schwachstellen in Webanwendungen zu identifizieren und zu beheben, bevor Angreifer sie finden.