Stored XSS
Was ist Stored XSS?
Stored XSSPersistente Cross-Site-Scripting-Schwachstelle: vom Angreifer eingeschleuster Code wird serverseitig gespeichert und im Browser jedes Besuchers ausgeführt.
Stored XSS (auch persistent oder Typ-2) entsteht, wenn eine Anwendung nicht vertrauenswürdige Eingaben akzeptiert, in einer Datenbank, im Dateisystem oder in Logs ablegt und sie später ohne korrekte Ausgabecodierung in HTML einbettet. Da die Payload auf dem Server liegt, führt jeder Besucher der betroffenen Seite das Skript automatisch aus, was diese Schwachstelle besonders gefährlich macht. Typische Angriffsziele sind Kommentare, Profile, Produktbewertungen oder Admin-Dashboards mit Logeinträgen. Schutz bieten kontextabhängiges Output-Encoding, eine strikte Content Security Policy, Eingabevalidierung sowie Sanitizer-Bibliotheken wie DOMPurify.
● Beispiele
- 01
Ein Blog-Kommentar mit <script>fetch('/api/me').then(...)</script>, das bei jedem Leser ausgeführt wird.
- 02
Der Angreifer speichert eine Payload im Profilnamen, die im Admin-Panel ausgeführt wird.
● Häufige Fragen
Was ist Stored XSS?
Persistente Cross-Site-Scripting-Schwachstelle: vom Angreifer eingeschleuster Code wird serverseitig gespeichert und im Browser jedes Besuchers ausgeführt. Es gehört zur Kategorie Angriffe und Bedrohungen der Cybersicherheit.
Was bedeutet Stored XSS?
Persistente Cross-Site-Scripting-Schwachstelle: vom Angreifer eingeschleuster Code wird serverseitig gespeichert und im Browser jedes Besuchers ausgeführt.
Wie funktioniert Stored XSS?
Stored XSS (auch persistent oder Typ-2) entsteht, wenn eine Anwendung nicht vertrauenswürdige Eingaben akzeptiert, in einer Datenbank, im Dateisystem oder in Logs ablegt und sie später ohne korrekte Ausgabecodierung in HTML einbettet. Da die Payload auf dem Server liegt, führt jeder Besucher der betroffenen Seite das Skript automatisch aus, was diese Schwachstelle besonders gefährlich macht. Typische Angriffsziele sind Kommentare, Profile, Produktbewertungen oder Admin-Dashboards mit Logeinträgen. Schutz bieten kontextabhängiges Output-Encoding, eine strikte Content Security Policy, Eingabevalidierung sowie Sanitizer-Bibliotheken wie DOMPurify.
Wie schützt man sich gegen Stored XSS?
Schutzmaßnahmen gegen Stored XSS kombinieren typischerweise technische Kontrollen und operative Praktiken, wie in der Definition oben beschrieben.
Welche anderen Bezeichnungen gibt es für Stored XSS?
Übliche alternative Bezeichnungen: Persistentes XSS, Typ-2-XSS.
● Verwandte Begriffe
- attacks№ 240
Cross-Site-Scripting (XSS)
Web-Schwachstelle, mit der Angreifer bösartige Skripte in Seiten injizieren, die andere Nutzer öffnen, sodass der Code im Browser des Opfers unter der Origin der Seite ausgeführt wird.
- attacks№ 912
Reflected XSS
Nicht-persistente XSS-Variante, bei der angreifergesteuerte Eingaben unmittelbar in der Antwort gespiegelt und im Browser des Opfers ausgeführt werden.
- attacks№ 347
DOM-basierter XSS
XSS-Variante, bei der Injektion und Ausführung vollständig im Browser stattfinden, weil clientseitiges JavaScript ungeprüfte Daten in einen Sink schreibt.
- appsec№ 214
Content Security Policy (CSP)
HTTP-Antwort-Header, der dem Browser mitteilt, welche Quellen für Skripte, Styles, Frames und andere Inhalte erlaubt sind, und so XSS- und Datendiebstahlangriffe begrenzt.
- appsec№ 773
Ausgabeencodierung
Umwandlung unvertrauenswürdiger Daten in eine für einen bestimmten Ausgabekontext (HTML, JavaScript, URL, SQL, Shell) sichere Form, sodass sie nicht ausbrechen und als Code ausgeführt werden.
- appsec№ 538
Eingabevalidierung
Serverseitige Prüfung, ob jede unvertrauenswürdige Eingabe vor der Verarbeitung dem erwarteten Typ, Längen-, Wert-, Format- und Wertebereich entspricht.
● Siehe auch
- № 104Blind XSS