Cross-Site Scripting (XSS) ermöglicht es Angreifern, schädlichen JavaScript-Code in Webseiten einzuschleusen, der dann im Browser anderer Benutzer ausgeführt wird. Die Folgen reichen von Session-Diebstahl über Datenexfiltration bis hin zur vollständigen Übernahme von Benutzerkonten. XSS gehört seit Jahren zu den häufigsten Sicherheitslücken in Webanwendungen.
Die drei Typen von XSS
| Typ | Beschreibung | Gefährlichkeit | Beispiel |
|---|---|---|---|
| Reflected XSS | Schadcode wird über einen URL-Parameter eingeschleust und sofort zurückgegeben | Mittel | Suchfeld ohne Eingabevalidierung |
| Stored XSS | Schadcode wird in der Datenbank gespeichert und bei jedem Aufruf ausgeführt | Sehr hoch | Kommentarfeld in einem Forum |
| DOM-based XSS | Manipulation des DOM im Browser ohne Serverbeteiligung | Mittel | JavaScript liest URL-Fragment und fügt es unsicher ins DOM ein |
Schutzmaßnahmen gegen XSS
- Output Encoding: Alle Benutzereingaben bei der Ausgabe HTML-kodieren. In PHP:
htmlspecialchars($input, ENT_QUOTES, 'UTF-8') - Content Security Policy (CSP): HTTP-Header, der dem Browser vorschreibt, welche Skripte ausgeführt werden dürfen. Inline-Skripte können damit vollständig blockiert werden.
- Input Validation: Eingaben serverseitig validieren und nur erwartete Formate akzeptieren
- Template-Engines mit Auto-Escaping: Moderne Template-Engines wie Twig escapen alle Variablen automatisch
- HttpOnly-Flag für Cookies: Verhindert, dass JavaScript auf Session-Cookies zugreifen kann
XSS in der Praxis: Warum es immer noch passiert
Trotz bekannter Gegenmaßnahmen werden XSS-Schwachstellen immer wieder entdeckt. Die häufigsten Ursachen: Entwickler vergessen das Escaping an einzelnen Stellen, Template-Engines werden mit Raw-Output-Funktionen umgangen, oder JavaScript-Frameworks manipulieren das DOM unsicher. Regelmäßige Security-Reviews sind daher unverzichtbar.
Erfahren Sie mehr über Web-Sicherheit in unserer Artikelserie zu IT-Security-Reviews. Kontaktieren Sie uns für eine Sicherheitsprüfung Ihrer Webanwendung.
Fazit
XSS ist eine der häufigsten und gefährlichsten Schwachstellen in Webanwendungen. Die Kombination aus konsequentem Output Encoding, Content Security Policy und regelmäßigen Sicherheitsüberprüfungen bietet den besten Schutz. Verlassen Sie sich nicht auf eine einzelne Maßnahme, sondern setzen Sie auf Defense-in-Depth.