Cross-Site-Scripting (XSS) und CSRF

Cross-Site Scripting (XSS) ist eine clientseitige Injection-Schwachstelle, bei der ein Angreifer schädliche Skripte in Webseiten einschleust, die von anderen Benutzern aufgerufen werden. Im Gegensatz zu SQL-Injection, die auf den Server abzielt, richtet sich XSS gegen den Browser des Opfers. Wenn der Browser das Skript des Angreifers rendert, wird es mit denselben Berechtigungen wie legitime Seitenskripte ausgeführt. Dadurch werden Session-Hijacking, der Diebstahl von Zugangsdaten und die Verbreitung von Malware ermöglicht.

Reflected XSS tritt auf, wenn ein schädliches Skript in eine URL eingebettet und vom Server ohne ordnungsgemäße Kodierung sofort in der HTTP-Antwort „reflektiert“ wird. Das Opfer wird (häufig über einen Phishing-Link) dazu gebracht, die manipulierte URL anzuklicken, wodurch sein Browser das Skript des Angreifers ausführt. Reflected XSS ist nicht persistent – es wird nur ausgeführt, wenn das Opfer auf den schädlichen Link klickt.

Stored XSS (persistentes XSS) bettet ein schädliches Skript in die Datenbank der Anwendung ein, beispielsweise in einen Kommentar oder Forenbeitrag. Bei jedem Benutzer, der diesen Inhalt aufruft, wird das Skript im Browser ausgeführt. Dadurch ist Stored XSS wesentlich gefährlicher als Reflected XSS. DOM-basiertes XSS tritt vollständig im Browser auf, wenn clientseitiges JavaScript von einem Angreifer kontrollierte Daten aus dem DOM (z. B. dem URL-Fragment) liest und sie unsicher zurück in die Seite schreibt.

Die wichtigste Schutzmaßnahme gegen XSS ist die Ausgabekodierung: Wandeln Sie Sonderzeichen vor ihrer Darstellung im Browser in die entsprechenden HTML-Entitäten (<, >, &) um. Ein Header mit einer Content Security Policy (CSP) schränkt ein, welche Skripte ausgeführt werden dürfen, und bietet eine wichtige zusätzliche Schutzmaßnahme. Auch auf der Serverseite sollte eine Eingabevalidierung (Allowlist) eingesetzt werden.

Cross-Site Request Forgery (CSRF) nutzt das Vertrauen aus, das eine Website dem Browser eines authentifizierten Benutzers entgegenbringt. Ein Angreifer bringt den Browser des Opfers dazu, eine unerwünschte authentifizierte Anfrage an eine Website zu senden, bei der das Opfer angemeldet ist. Da der Browser Sitzungscookies automatisch anhängt, hält der Zielserver die Anfrage für legitim. Bei gängigen CSRF-Angriffen werden Geldbeträge überwiesen, E-Mail-Adressen geändert oder Kontoeinstellungen angepasst.

Stellen Sie sich vor, ein Benutzer ist bei seiner Bank unter bank.com angemeldet. Ein Angreifer sendet ihm eine E-Mail mit einem versteckten Bild-Tag: <img src='https://bank.com/transfer?to=attacker&amount=1000'>. Beim Öffnen der E-Mail lädt der Browser die Bild-URL automatisch und sendet dabei die Überweisungsanfrage zusammen mit dem Sitzungscookie des Opfers. Die Bank verarbeitet sie als legitime Anfrage.

Die wirksamste CSRF-Schutzmaßnahme ist ein CSRF-Token – ein eindeutiger, nicht vorhersehbarer Wert, der in jedes Formular eingebettet und serverseitig überprüft wird. Da der Angreifer das Token aufgrund der Same-Origin-Policy nicht von einer anderen Origin auslesen kann, enthalten gefälschte Anfragen kein gültiges Token und werden abgelehnt. Das SameSite-Cookie-Attribut (SameSite=Strict oder Lax) verhindert außerdem, dass Browser Cookies bei Cross-Site-Anfragen senden.

XSS und CSRF werden häufig verwechselt, zielen jedoch auf unterschiedliche Elemente. XSS schleust ein schädliches Skript ein, das im Browser des Opfers ausgeführt wird, und nutzt das Vertrauen des Benutzers in die Website aus. CSRF fälscht Anfragen vom Browser des Opfers an eine vertrauenswürdige Website und nutzt das Vertrauen der Website in den Browser des Benutzers aus. XSS kann zum Diebstahl von CSRF-Tokens verwendet werden, wodurch sich die beiden Schwachstellen effektiv miteinander verketten lassen.

Cookie-Flags bieten wichtige Schutzmaßnahmen gegen XSS. Das HttpOnly-Flag verhindert, dass JavaScript über document.cookie auf das Cookie zugreift, und erschwert so den Diebstahl von Sitzungstokens, selbst wenn XSS vorhanden ist. Das Secure-Flag stellt sicher, dass Cookies nur über HTTPS übertragen werden, und verhindert so das Abfangen über unverschlüsselte Verbindungen. Beide Flags sollten als Defense-in-Depth-Maßnahme für alle Sitzungscookies gesetzt werden.

Sicherheitstester identifizieren XSS, indem sie Test-Payloads in jedes Eingabefeld, jeden URL-Parameter, jeden HTTP-Header und jedes JSON-Feld einschleusen. Ein einfacher Test ist <script>alert(1)</script> – wird ein Warnfenster angezeigt, ist XSS bestätigt. Tools wie Burp Suite automatisieren XSS-Scans, und OWASP ZAP bietet aktive Scans kostenlos an. Für DOM-basiertes XSS ist eine Analyse des browserseitigen JavaScripts erforderlich, nicht lediglich die Untersuchung der Serverantwort.

XSS-Angriffe haben in der Praxis erheblichen Schaden verursacht. Der Samy-Wurm (2005) verbreitete sich innerhalb von 20 Stunden über MySpace, indem er Stored XSS ausnutzte, um sich selbst auf mehr als eine Million Profile zu verbreiten. XSS-Angriffe können Sitzungstokens stehlen und dadurch Konten vollständig übernehmen, Benutzer auf Phishing-Websites umleiten, Browser-Exploits ausliefern (Drive-by-Downloads) und Seiteninhalte so verändern, dass ausgewählten Benutzern falsche Informationen angezeigt werden.

Testen Sie Ihr Verständnis der CompTIA-Security+-Konzepte (SY0-701) aus dieser Lektion.

In dieser Lektion haben Sie gelernt: XSS schleust Skripte in Seiten ein, die von anderen Benutzern aufgerufen werden, CSRF bringt authentifizierte Browser dazu, gefälschte Anfragen zu senden und Ausgabekodierung, CSP, CSRF-Tokens sowie das SameSite-Cookie-Attribut sind die wichtigsten Schutzmaßnahmen. Als Nächstes befassen wir uns mit fehlerhafter Authentifizierung und unsicherer Deserialisierung.