Von Benutzern bereitgestellte Profil-Biografien werden unescaped gerendert, und eine enthält ein `<script>`-Tag. Was ist die korrekte Behebung?
Kurzantwort
Stored XSS wird behoben, indem Daten für den genauen Kontext kodiert werden, in dem sie gerendert werden (HTML-Body, Attribut, JavaScript, URL), sodass der Browser sie als Text behandelt, mit einer Content-Security-Policy als zweiter Schicht. Das Wort „script“ auf eine Blacklist zu setzen, wird trivial über Event-Handler, gemischte Groß-/Kleinschreibung und Kodierungen umgangen. Du kannst deine Benutzer nicht zwingen, JavaScript zu deaktivieren. Benutzer zu bitten, kein HTML einzugeben, ist keine durchsetzbare Maßnahme. Kodiere bei der Ausgabe, bei jedem Rendern.
Die Bio wird gespeichert und später in eine Seite gerendert, ohne kodiert zu werden, sodass ein darin enthaltenes <script>-Tag im Browser jedes Betrachters ausgeführt wird. Das ist Stored (persistentes) Cross-Site-Scripting — eine einzige injizierte Payload trifft jeden Benutzer, der das Profil lädt. Die Grundursache ist, dass Daten beim Rendern als Markup interpretiert werden.
Die korrekte Behebung: kontextbewusstes Output-Encoding
XSS ist ein Rendering-Problem, also behebe es dort, wo die Daten auf die Seite treffen: kodiere bei der Ausgabe, für den jeweiligen Kontext.
- Im HTML-Body-Kontext kodierst du
<,>,&usw., sodass der Browser den Text anzeigt, statt ein Tag zu parsen. - In einem HTML-Attribut-, JavaScript- oder URL-Kontext ist die korrekte Kodierung anders — die falsche zu verwenden lässt die Lücke bestehen.
Moderne Frameworks escapen standardmäßig automatisch; der Bug erscheint meist dort, wo jemand zu einem Raw-HTML-Schlupfloch greift. Füge eine Content-Security-Policy als Defense-in-Depth hinzu, sodass selbst bei einer übersehenen Kodierung Inline- und nicht vertrauenswürdige Skripte blockiert werden.
Warum die Distraktoren falsch sind
- Das Wort „script" entfernen ist eine Eingabe-Blacklist und wird trivial umgangen: ein
img-Tag mit einemonerror-Handler, einsvg-Tag mitonload, gemischte Groß-/Kleinschreibung, HTML-Entities und Dutzende anderer Vektoren enthalten kein wörtliches „script". - Den Benutzern sagen, sie sollen JavaScript deaktivieren ist als Maßnahme absurd — du betreibst nicht die Browser deiner Benutzer, und die Anwendung hängt ohnehin von JS ab.
- Die Benutzer bitten, kein HTML einzugeben ist eine Bitte, keine Durchsetzung; der Angreifer ignoriert sie einfach.
Worauf der Interviewer achtet
Ob du weißt, dass XSS bei der Ausgabe, im richtigen Kontext behoben wird und nicht durch Filtern von Eingaben gegen eine Deny-Liste, und ob du eine CSP darüberlegst, ohne sie mit der Hauptbehebung zu verwechseln. Starke Kandidaten merken an, dass Eingabe-Validierung und Sanitisierung von vertrauenswürdigem HTML ihren Platz haben (für Rich-Text-Felder), aber kontextbezogenes Output-Encoding die verlässliche, universelle Maßnahme ist.
Wahrscheinliche Anschlussfragen
- Warum ist Output-Encoding kontextabhängig — wie unterscheidet sich das Kodieren für ein HTML-Attribut von dem für einen JS-String?
- Was fügt eine Content-Security-Policy hinzu, und warum ist sie kein Ersatz für das Kodieren?
- Wann ist Eingabe-Sanitisierung (z. B. ein HTML-Sanitizer) statt Kodierung angebracht?