Erkläre Stored-, Reflected- und DOM-basiertes XSS.
Kurzantwort
Jedes XSS schleust vom Angreifer kontrolliertes Skript in den Browser eines Opfers ein. Stored XSS speichert die Payload dauerhaft auf dem Server (z. B. einen Kommentar) und trifft jeden, der sie ansieht; Reflected XSS spiegelt die Payload in einer einzelnen Antwort vom Server zurück, meist über einen präparierten Link; DOM-basiertes XSS erreicht nie die Serverlogik — verwundbares clientseitiges JavaScript schreibt nicht vertrauenswürdige Eingaben in die Seite.
Cross-Site-Scripting (XSS) ist die Fehlerklasse, bei der ein Angreifer sein JavaScript in der Browser-Sitzung eines anderen Nutzers ausführen lässt, innerhalb des vertrauenswürdigen Origins deiner Website. Sobald das geschieht, kann das Skript Cookies, das DOM und Tokens lesen, authentifizierte Anfragen stellen und das Opfer imitieren. Die drei Varianten unterscheiden sich darin, wo die Payload lebt und wie sie zur Ausführung gelangt — und dieser Unterschied bestimmt sowohl die Erkennung als auch die Behebung.
Stored (persistent)
Die Payload wird auf dem Server gespeichert — in einer Datenbank, einem Kommentarfeld, einem Profilnamen — und an jeden Nutzer zurückgeliefert, der diesen Inhalt lädt. Dies ist die gefährlichste Form, weil sie keine Interaktion pro Opfer benötigt und sich wie ein Wurm ausbreiten kann. Ein einziges eingeschleustes <script> in einem Forenbeitrag kann Tausende von Sitzungen treffen.
Reflected (nicht persistent)
Die Payload ist in einer Anfrage enthalten (ein Query-Parameter, ein Formularfeld) und wird sofort in der Antwort zurückgespiegelt, ohne gespeichert zu werden. Der Angreifer muss jedes Opfer dazu verleiten, einen präparierten Link anzuklicken oder ein bösartiges Formular abzuschicken. Es ist ein Einmaleffekt pro Opfer, aber verheerend beim Phishing.
DOM-basiert
Hier kann der Server völlig unschuldig sein. Verwundbares clientseitiges JavaScript liest vom Angreifer kontrollierbare Eingaben (wie location.hash) und schreibt sie in eine gefährliche Senke wie innerHTML, document.write oder eval. Die Payload taucht möglicherweise in keinem HTTP-Anfragekörper auf, den der Server verarbeitet, weshalb serverseitige WAFs und Protokolle sie übersehen können. Das eingeschleuste Skript selbst stammt aus denselben Familien von XSS-Payloads, unabhängig davon, wie es die Senke erreicht.
Warum die Unterscheidung wichtig ist
Stored und Reflected werden weitgehend durch kontextbezogene Ausgabecodierung auf dem Server und eine starke Content-Security-Policy abgemildert. DOM-XSS muss im Client-Code behoben werden — mit sicheren APIs wie textContent und setAttribute statt innerHTML.
Prüfer achten auf das Wo/Wie-Schema, auf das Nennen einer konkreten Senke für DOM-XSS und auf das Bewusstsein, dass Stored XSS aufgrund seines Schadensradius meist die höchste Priorität hat.
Wahrscheinliche Anschlussfragen
- Warum ist DOM-basiertes XSS für eine serverseitige WAF manchmal unsichtbar?
- Welche Senken (innerHTML, document.write) machen DOM-XSS möglich?
- Wie würdest du das Beheben von Stored- vs. Reflected-XSS priorisieren?