Spring GDS 25. Jubiläum
Ein Logistikunternehmen, das in 190 Länder versendet, hat etwas gebaut, um an sich selbst zu liefern.
Cross-Site-Scripting ist eine Web-Schwachstelle, bei der ein Angreifer schädlichen Code in eine Seite einschleust, die andere Menschen dann in ihrem Browser laden. Der Browser vertraut der Seite und führt das Skript aus, als hätte die Seite es selbst geschrieben. Von dort kann ein Angreifer Session-Cookies stehlen, mitlesen, was ein Nutzer tippt, oder als dieser Nutzer handeln. XSS zielt auf die Besucher einer Seite, und genau das unterscheidet es von einem serverseitigen Angriff.
Es gibt drei gängige Formen. Stored XSS sitzt in der Datenbank, eingeschleust etwa über ein Kommentarfeld, und feuert bei jedem Besucher, der es lädt. Reflected XSS prallt über einen präparierten Link vom Server zurück, oft in einem Suchergebnis, das die Eingabe direkt zurückwirft. DOM-basiertes XSS passiert vollständig im Browser, wenn clientseitiger Code mit nicht vertrauenswürdigen Daten unsicher umgeht. Ein klassisches Beispiel ist ein Kommentarfeld, das <script>-Tags speichert und sie jedem Leser wieder vorspielt. Die Grundursache ist fast immer dieselbe. Nicht vertrauenswürdige Eingaben landen ohne Escaping oder Sanitizing auf der Seite.
Die Abwehr ist gut verstanden. Escapen Sie die Ausgabe je nachdem, wo sie landet, validieren Sie die Eingabe beim Eintreffen und setzen Sie eine Content Security Policy ein, die Skripte dort blockiert, wo sie nicht laufen sollen. Moderne Frameworks escapen standardmäßig, was hilft, doch jede Stelle, die rohes HTML einspielt, kann die Tür wieder öffnen.
Wir behandeln jeden Wert, der von einem Nutzer kommt, als feindlich, bis das Gegenteil bewiesen ist. Ausgaben werden standardmäßig escaped, das Einspielen von rohem HTML wird Zeile für Zeile geprüft, und Content-Security-Policy-Header gehören zum Build statt als nachträglicher Einfall. Die Frameworks, in denen wir arbeiten, escapen automatisch, und wir gehen vorsichtig mit den wenigen Schlupflöchern um, die diesen Schutz umgehen.
Das gehört dazu, wie wir QA-Strategie und Governance über Webentwicklung und individuelle Webanwendungen hinweg angehen. Sicherheitsprüfungen sitzen im Review-Prozess, nicht in einer separaten Phase, die bei engen Zeitplänen gestrichen wird. Wir haben öffentlich zugängliche Produkte für Marken gebaut, bei denen ein einziges eingeschleustes Skript schnell ein großes Publikum erreichen würde, und diese Realität hält die Disziplin ab dem ersten Commit straff.
Sie bauen etwas Öffentliches, das Nutzereingaben verarbeitet? Stellen wir sicher, dass es nicht gegen Ihre Besucher verwendet werden kann.
Ein Logistikunternehmen, das in 190 Länder versendet, hat etwas gebaut, um an sich selbst zu liefern.
Eine Marke in ein funktionierendes Geschäft verwandeln.
Eine halbe Million Menschen. Eine App. Null Chaos.















