Coder meistern Sicherheit: Teilen & Lernen – Cross-Site Scripting (XSS)

Cross-Site Scripting (XSS) ist für Sicherheitsexperten seit den frühen 2000er Jahren ein Ärgernis, und leider zählt es auch Jahrzehnte später noch zu den häufigsten Bedrohungen auf Code-Ebene. Diese Klasse von Software-Schwachstellen plagt uns schon viel zu lange, und ein aktueller Hinweis der CISA – im Rahmen ihrer „Secure-by-Design“-Initiative – zielt darauf ab, sie ein für alle Mal zu unterbinden. Sie verfolgen die globale Mission, Schwachstellenklassen in großem Maßstab zu eliminieren. Dieser Fokus auf entwicklergesteuerte Sicherheit kann wirklich etwas bewegen, erfordert aber das Engagement kluger Unternehmen, die ihre Entwickler auf Erfolgskurs in Sachen Sicherheit bringen.

Was genau ist also XSS?

Webbrowser mögen unser Tor zu all den großartigen Dingen im Internet sein, aber leider ist nicht alles Gold, was glänzt. Das inhärente Verhalten von Webbrowsern kann ein Katalysator für Sicherheitslücken sein. Browser begannen damit, dem Markup, das sie sahen, charakteristischerweise zu vertrauen und es ohne Fragen auszuführen. Das ist alles schön und gut, bis diese Funktionalität für zwielichtige Zwecke ausgenutzt wird... und natürlich fanden Angreifer schließlich Wege, diese Tendenz für ihre bösen Absichten zu nutzen.

Cross-Site Scripting nutzt das Vertrauen von Browsern und die Unwissenheit von Nutzern aus, um Daten zu stehlen, Konten zu übernehmen und Websites zu verunstalten; es ist eine Schwachstelle, die sehr schnell sehr unangenehm werden kann.

Werfen wir einen Blick darauf, wie XSS funktioniert, welchen Schaden es anrichten kann und wie man es verhindert:

Wie funktioniert XSS?

XSS tritt auf, wenn nicht vertrauenswürdige Eingaben (oft Daten) als Ausgabe auf einer Seite gerendert, aber fälschlicherweise als ausführbarer Code interpretiert werden. Ein Angreifer kann bösartigen ausführbaren Code (HTML-Tags, JavaScript usw.) in einen Eingabeparameter einfügen, der – wenn er an den Browser zurückgegeben wird – ausgeführt statt als Daten angezeigt wird.

Wie oben erwähnt, entstand die Schwachstelle aufgrund des grundlegenden Funktionsverhaltens von Browsern, bei dem es schwierig ist, Daten von ausführbarem Code zu unterscheiden. Das Betriebsmodell des Webs sieht wie folgt aus:

1. Der Nutzer besucht eine Webseite
2. Die Seite weist den Browser an, welche Dateien geladen und ausgeführt werden sollen
3. Der Browser führt aus, was auf der Seite steht, ohne Fragen zu stellen

Diese Funktionalität hat zu einigen der großartigsten, interaktiven Erlebnisse geführt, die wir im Web genießen. Die Kehrseite der Medaille ist, dass sie auch zu kostspieligen Exploits und Schwachstellen geführt hat.

Wenn Angreifer ihr bösartiges Skript zu einer anfälligen Seite hinzufügen, wird es ohne Rückfragen ausgeführt. Es gibt keine tiefergehende Untersuchung oder Erkennungsmaßnahmen.

Es gibt drei Arten von XSS:

• Stored XSS
• Reflected XSS
• DOM XSS

Stored XSS tritt auf, wenn ein Angreifer das bösartige Skript dauerhaft in einem Datenfeld der Anwendung speichern kann (z. B. in einem Feld, das die Mobilfunknummer des Nutzers speichert). Dieses zwielichtige Skript wird dann jedes Mal an den Browser des Nutzers gesendet, wenn dieses Datenfeld in der Anwendung angezeigt wird.

Diese Art von Angriff ist häufig auf Forenseiten oder in Kommentarbereichen zu beobachten. Ein Angreifer gibt das bösartige Skript in einen Kommentar ein, und zack – jeder Nutzer, der diesen Kommentar ansieht, führt das Skript unwissentlich aus.

Reflected XSS tritt auf, wenn Nutzereingaben unverändert an den Browser des Nutzers zurückgegeben werden. Ein Beispiel ist ein Suchfeld, das dem Nutzer „Sie haben nach ... gesucht“ anzeigt, während die Suchergebnisse abgerufen werden.

Stellen Sie sich nun vor, die Suche funktioniert, indem der Suchbegriff als Abfrageparameter in die URL eingefügt wird. Ein bösartiger Angreifer könnte dem Opfer einen Link mit dem eingebetteten bösartigen Skript in genau diesen Parametern senden, und ehrlich gesagt würden die meisten Webnutzer das kaum bemerken.

Das Opfer klickt auf den Link und wird auf eine Phishing-Seite weitergeleitet, wo es unwissentlich sein Passwort für die Seite eingibt. Das Opfer ahnt nicht, dass ein Angreifer gerade den Schlüssel zu seinem Konto gestohlen hat.

DOM XSS ist eine relativ neue Variante dieser Schwachstelle. Sie nutzt komplexe Templating-Strukturen aus, die in vielen UI-Frameworks wie Angular und React zu finden sind.

Diese Vorlagen ermöglichen dynamische Inhalte und umfangreiche UI-Anwendungen. Bei falscher Verwendung können sie für XSS-Angriffe missbraucht werden.

Das war es also. Sie kennen nun den Umfang von XSS im Überblick. Lassen Sie uns tiefer eintauchen, wie es destruktiv eingesetzt werden kann.

Warum ist XSS so gefährlich?

XSS kann verwendet werden, um Nutzer auf bösartige Seiten umzuleiten, Cookies zu stehlen und Sitzungsdaten auszuspähen. Im Grunde genommen ist alles, was JavaScript tun kann, auch für XSS-Angriffe möglich.

Hier sind drei Beispiele für XSS-Angriffe:

1. Yahoo-E-Mail-Nutzern wurden 2015 Sitzungs-Cookies gestohlen mittels XSS.
2. Der Samy-Wurm wurde über eine XSS-Schwachstelle bei MySpace verbreitet. Er ist nach wie vor die am schnellsten verbreitete Malware aller Zeiten und betraf eine Million Nutzer in nur 20 Stunden.
3. eBay erlaubte es, bösartige Skripte in Produktbeschreibungen einzubinden. Dies führte zu XSS-Angriffen gegen eBay-Nutzer.

XSS-Angriffe sind täuschend einfach und sehr ernst zu nehmen. Sie können zum Diebstahl von Sitzungen, Nutzerdaten oder sensiblen Informationen führen. Reputationsschäden und Umsatzrückgänge sind große Gefahren dieser Angriffe. Selbst das bloße Verunstalten einer Website kann für ein Unternehmen unerwünschte Folgen haben.

XSS kann jedoch von einem versierten Security Warrior wie Ihnen besiegt werden. Die Lösung ist nicht kompliziert, und die Branche hat seit der Zeit, als XSS zu einem häufig genutzten Exploit wurde, einen sehr weiten Weg zurückgelegt.

Sie können XSS besiegen.

Der Schlüssel zur Bekämpfung von XSS liegt im Verständnis des Kontexts. Insbesondere des Kontexts, in dem Ihre Nutzereingaben an den Client zurückgegeben werden und wo dies geschieht. Innerhalb des HTML-Codes oder innerhalb eines JavaScript-Snippets.

Wenn Nutzereingaben nicht an den Browser zurückgesendet werden müssen, umso besser. Falls doch, sollten sie oft HTML-kodiert werden. Die HTML-Kodierung der Ausgabe weist den Browser an, den Inhalt so anzuzeigen, wie er ist, und ihn nicht auszuführen.

Eingabevalidierung ist ebenfalls wichtig. Validierung und Whitelisting sind jedoch keine narrensicheren Lösungen. Kodierung geht ein paar Schritte weiter und verhindert, dass Browser ein bösartiges Skript ausführen. Was durch Validierungs- und Whitelisting-Strategien nicht erfasst wird, fängt die Kodierung ab.

Viele Frameworks kodieren HTML-Ausgaben mittlerweile automatisch.
Angular, ASP.NET MVC und React.js sind Frameworks, bei denen standardmäßig HTML-Kodierung verwendet wird. Sie müssen diese Frameworks explizit anweisen, nicht zu kodieren, indem Sie eine spezielle Methode aufrufen.

Die meisten anderen Frameworks (z. B. Django und Spring) verfügen über Standardbibliotheken zur XSS-Prävention, die Sie einfach in Ihren Code integrieren können.

Die größte Herausforderung besteht darin, zu lernen, alle Wege zu analysieren, über die Nutzereingaben in ein System gelangen können, damit Sie wachsam bleiben. Abfrageparameter können Angriffe enthalten, ebenso wie Post-Parameter. Verfolgen Sie den Datenfluss durch Ihre Anwendung und vertrauen Sie keinen Daten, die von außen kommen.

Denken Sie wie ein Grenzschutz. Halten Sie jedes Datenelement an, überprüfen Sie es und lassen Sie es nicht zu, wenn es bösartig aussieht. Kodieren Sie dann beim Rendern, um sicherzustellen, dass alles Schädliche, das übersehen wurde, dennoch keine Probleme verursacht.

Setzen Sie diese Strategien um, und Ihre Nutzer sind vor Angriffen durch XSS geschützt. Werfen Sie einen Blick auf das OWASP Cheat Sheet für weitere Tipps, um Ihre Daten unter Kontrolle zu halten.

Wehren Sie XSS ab und verbessern Sie Ihre Sicherheitsfähigkeiten.

XSS steht auf Platz sieben der OWASP Top 10 2017 Liste der Websicherheitsrisiken. Es gibt es schon eine Weile, aber es kann immer noch auftreten und Probleme mit Ihrer Anwendung verursachen, wenn Sie nicht vorsichtig sind.

Schulungen sind für Entwickler so wichtig, um beim Programmieren eine sicherheitsorientierte Denkweise zu entwickeln. Und diese Schulungen sind immer dann am effektivsten, wenn sie reale Anwendungen in den Sprachen simulieren, die Entwickler aktiv nutzen. Warum schauen Sie sich vor diesem Hintergrund nicht unsere Lernressourcen an, um mehr über XSS zu erfahren? Danach können Sie mit dem Training und der Praxis beginnen, die zu Ihrer Meisterschaft führen.

Denken Sie, Sie sind bereit, XSS-Schwachstellen sofort zu finden und zu beheben? Fordern Sie sich selbst heraus auf der Secure Code Warrior Plattform.