Coders Conquer Security: Teilen & Lernen - Cross-Site Scripting

Veröffentlicht am 06. Dez. 2018
von Jaap Karan Singh
FALLSTUDIE

Coders Conquer Security: Teilen & Lernen - Cross-Site Scripting

Veröffentlicht am 06. Dez. 2018
von Jaap Karan Singh
Ressource anzeigen
Ressource anzeigen

Webbrowser mögen unser Tor zu all den tollen Dingen im Internet sein, aber leider gibt es nicht nur gute Nachrichten. Das inhärente Verhalten von Webbrowsern kann ein Katalysator für Sicherheitslücken sein. Zu Beginn vertrauten die Browser auf das Markup, das sie sahen, und führten es ohne Fragen aus. Das ist alles schön und gut, bis diese Funktionalität für unappetitliche Zwecke ausgenutzt wird... und natürlich haben Angreifer irgendwann Wege gefunden, diese Tendenz für ihre bösen Zwecke auszunutzen.

Cross-Site-Scripting (XSS) nutzt das Vertrauen von Browsern und die Unwissenheit von Benutzern, um Daten zu stehlen, Konten zu übernehmen und Websites zu verunstalten; es ist eine Schwachstelle, die sehr schnell sehr hässlich 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 werden, aber als ausführbarer Code fehlinterpretiert werden. Ein Angreifer kann bösartigen ausführbaren Code (HTML-Tags, JavaScript usw.) innerhalb eines Eingabeparameters platzieren, der - wenn er an den Browser zurückgegeben wird - dann ausgeführt wird, anstatt als Daten angezeigt zu werden.

Wie bereits erwähnt, trat die Schwachstelle aufgrund des grundlegenden Funktionsverhaltens von Browsern auf, bei dem es schwierig ist, Daten von ausführbarem Code zu unterscheiden. Das Funktionsmodell des Webs ist wie folgt:

  1. Benutzer besucht eine Web-Seite
  2. Die Seite teilt dem Browser mit, welche Dateien geladen und was ausgeführt werden soll
  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 Erfahrungen 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 Website hinzufügen, wird es ohne Hinterfragen ausgeführt. Es gibt weder eine tiefere Untersuchung noch Maßnahmen zur Erkennung.

Benutzerdefinierter Javascript-Code könnte in den Browsern Ihrer Nutzer ausgeführt werden

Es gibt drei Arten von XSS:

  • Gespeicherte XSS
  • Reflektiertes 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 Mobiltelefonnummer des Benutzers speichert). Dieses skizzenhafte Skript wird dann jedes Mal an den Browser des Benutzers gesendet, wenn dieses Datenfeld in der Anwendung angezeigt wird.

Diese Art von Angriff wird häufig auf Forenseiten oder Kommentarmaschinen beobachtet. Ein Angreifer gibt das bösartige Skript in einen Kommentar ein, und bam - jeder Benutzer, der diesen Kommentar aufruft, führt das Skript unwissentlich aus.

Reflektiertes XSS tritt auf, wenn Benutzereingaben unverändert an den Browser des Benutzers zurückgesendet werden. Ein Beispiel ist ein Suchfeld, das dem Benutzer beim Abrufen der Suchergebnisse anzeigt: "Sie haben gesucht nach ...".

Nun stellen Sie sich vor, dass 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 einem bösartigen Skript senden, das in eben diesen Parametern eingebettet ist, und ehrlich gesagt würden die meisten Webbenutzer dies kaum bemerken.

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

DOM XSS ist eine relativ neue Variante dieser Sicherheitslücke. Sie nutzt die komplexen Template-Strukturen, die in vielen UI-Frameworks wie Angular und React zu finden sind.

Diese Templates ermöglichen dynamische Inhalte und reichhaltige UI-Anwendungen. Bei unsachgemäßer Verwendung können sie zur Ausführung von XSS-Angriffen verwendet werden.

So, da haben Sie es. Sie haben den Umfang von XSS in einer Nussschale bekommen. Lassen Sie uns nun tiefer eintauchen, wie es destruktiv eingesetzt werden kann.

Warum ist XSS so gefährlich?

XSS kann dazu verwendet werden, Benutzer auf bösartige Seiten umzuleiten, Cookies zu stehlen und Jagd auf Sitzungsdaten zu machen. Grundsätzlich gilt: Alles, was JavaScript kann, können auch XSS-Angriffe.

Hier sind drei Beispiele für XSS-Angriffe:

  1. Yahoo-E-Mail-Benutzern wurden 2015 ihre Sitzungscookies per XSS gestohlen.
  2. Der Samy-Wurm wurde über eine XSS-Schwachstelle in MySpace verbreitet. Er ist nach wie vor die sich am schnellsten verbreitende Malware aller Zeiten, die in nur 20 Stunden eine Million Benutzer befallen hat.
  3. eBay erlaubte die Einbindung von bösartigen Skripten in Produktbeschreibungen. Dies führte zu XSS-Angriffen gegen eBay-Benutzer.

XSS-Angriffe sind täuschend einfach und sehr schwerwiegend. Sie können zum Diebstahl von Sitzungen, Benutzeranmeldeinformationen oder sensiblen Daten führen. Reputationsschäden und Umsatzeinbußen sind die größten Fallstricke dieser Angriffe. Selbst die bloße Verunstaltung einer Website kann zu unerwünschten Konsequenzen für ein Unternehmen führen.

XSS kann jedoch von einem versierten Sicherheitskämpfer wie Ihnen besiegt werden. Die Lösung ist nicht kompliziert und die Industrie hat einen langen, langen Weg zurückgelegt, seit XSS zu einem häufig genutzten Exploit wurde.

Sie können XSS besiegen.

Der Schlüssel zum Besiegen von XSS ist das Verständnis des Kontexts. Genauer gesagt, der Kontext, in dem Ihre Benutzereingaben an den Client zurückgesendet werden, und wo sie zurückgesendet werden. Innerhalb des HTML-Codes oder innerhalb eines JavaScript-Snippets.

Wenn die Benutzereingabe nicht an den Browser zurückgesendet werden muss, umso besser. Aber wenn doch, sollte sie oft HTML-kodiert sein. Die HTML-Kodierung der Ausgabe weist den Browser an, den Inhalt so zu rendern, wie er ist, und ihn nicht auszuführen.

Die Validierung von Eingaben ist ebenfalls wichtig. Validierung und Whitelisting sind jedoch keine narrensicheren Lösungen. Die Kodierung geht ein paar Schritte weiter und verhindert, dass der Browser ein bösartiges Skript ausführt. Was auch immer mit Validierungs- und Whitelisting-Strategien nicht abgefangen wird, wird durch Kodierung aufgefangen.

Viele Frameworks kodieren die HTML-Ausgabe inzwischen automatisch.
Angular, ASP.NET MVC und React.js sind Frameworks, bei denen standardmäßig HTML-Kodierung verwendet wird. Sie müssen diesen Frameworks ausdrücklich sagen, dass sie nicht kodieren sollen, indem Sie eine spezielle Methode aufrufen.

Die meisten anderen Frameworks (z.B. Django und Spring) haben Standardbibliotheken für die XSS-Prävention, die Sie einfach in Ihren Code einbauen können.

Die größte Herausforderung besteht darin, sich beizubringen, alle Wege zu analysieren, auf denen Benutzereingaben in ein System gelangen können, damit Sie die Augen danach offen halten können. Abfrageparameter können Angriffe tragen, ebenso wie Postparameter. Verfolgen Sie den Datenfluss in Ihrer Anwendung und vertrauen Sie keinen Daten, die von außen kommen.

Denken Sie wie eine Grenzpatrouille. Halten Sie jedes Stück Daten an, inspizieren Sie es und lassen Sie es nicht herein, wenn es bösartig aussieht. Verschlüsseln Sie dann beim Rendern, um sicherzustellen, dass die übersehenen bösartigen Daten trotzdem keine Probleme verursachen.

Führen Sie diese Strategien aus, und Ihre Benutzer werden vor Angriffen über XSS sicher sein. Werfen Sie einen Blick auf das OWASP Cheat Sheet für noch mehr Tipps, um Ihre Daten unter Kontrolle zu halten.

Verhindern Sie XSS und verbessern Sie Ihre Sicherheitsfähigkeiten.

XSS befindet sich auf Platz sieben der OWASP Top 10 Liste 2017 der Web-Sicherheitsrisiken. Es gibt sie schon eine Weile, aber sie können immer noch auftreten und Probleme mit Ihrer Anwendung verursachen, wenn Sie nicht aufpassen.

Schulungen sind für Entwickler sehr wichtig, um eine sicherheitsorientierte Denkweise zu entwickeln, während sie Code erstellen. Und dieses Training ist immer dann am effektivsten, wenn es reale Anwendungen simuliert, und zwar in den Sprachen, die Entwickler aktiv verwenden. Schauen Sie sich in diesem Sinne unsere Lernressourcen an, um mehr über XSS zu erfahren. Danach können Sie mit dem Training und der Praxis beginnen, die zu Ihrer Beherrschung führen.

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

Ressource anzeigen
Ressource anzeigen

Autor

Jaap Karan Singh

Sie wollen mehr?

Tauchen Sie ein in unsere neuesten Erkenntnisse über sichere Kodierung im Blog.

Unsere umfangreiche Ressourcenbibliothek zielt darauf ab, die menschliche Herangehensweise an eine sichere Weiterbildung im Bereich der Programmierung zu stärken.

Blog ansehen
Sie wollen mehr?

Holen Sie sich die neuesten Forschungsergebnisse zur entwicklergesteuerten Sicherheit

Unsere umfangreiche Ressourcenbibliothek ist voll von hilfreichen Ressourcen, von Whitepapers bis hin zu Webinaren, die Ihnen den Einstieg in die entwicklungsorientierte sichere Programmierung erleichtern. Erforschen Sie sie jetzt.

Ressourcendrehscheibe

Coders Conquer Security: Teilen & Lernen - Cross-Site Scripting

Veröffentlicht am 06. Dez. 2018
Von Jaap Karan Singh

Webbrowser mögen unser Tor zu all den tollen Dingen im Internet sein, aber leider gibt es nicht nur gute Nachrichten. Das inhärente Verhalten von Webbrowsern kann ein Katalysator für Sicherheitslücken sein. Zu Beginn vertrauten die Browser auf das Markup, das sie sahen, und führten es ohne Fragen aus. Das ist alles schön und gut, bis diese Funktionalität für unappetitliche Zwecke ausgenutzt wird... und natürlich haben Angreifer irgendwann Wege gefunden, diese Tendenz für ihre bösen Zwecke auszunutzen.

Cross-Site-Scripting (XSS) nutzt das Vertrauen von Browsern und die Unwissenheit von Benutzern, um Daten zu stehlen, Konten zu übernehmen und Websites zu verunstalten; es ist eine Schwachstelle, die sehr schnell sehr hässlich 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 werden, aber als ausführbarer Code fehlinterpretiert werden. Ein Angreifer kann bösartigen ausführbaren Code (HTML-Tags, JavaScript usw.) innerhalb eines Eingabeparameters platzieren, der - wenn er an den Browser zurückgegeben wird - dann ausgeführt wird, anstatt als Daten angezeigt zu werden.

Wie bereits erwähnt, trat die Schwachstelle aufgrund des grundlegenden Funktionsverhaltens von Browsern auf, bei dem es schwierig ist, Daten von ausführbarem Code zu unterscheiden. Das Funktionsmodell des Webs ist wie folgt:

  1. Benutzer besucht eine Web-Seite
  2. Die Seite teilt dem Browser mit, welche Dateien geladen und was ausgeführt werden soll
  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 Erfahrungen 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 Website hinzufügen, wird es ohne Hinterfragen ausgeführt. Es gibt weder eine tiefere Untersuchung noch Maßnahmen zur Erkennung.

Benutzerdefinierter Javascript-Code könnte in den Browsern Ihrer Nutzer ausgeführt werden

Es gibt drei Arten von XSS:

  • Gespeicherte XSS
  • Reflektiertes 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 Mobiltelefonnummer des Benutzers speichert). Dieses skizzenhafte Skript wird dann jedes Mal an den Browser des Benutzers gesendet, wenn dieses Datenfeld in der Anwendung angezeigt wird.

Diese Art von Angriff wird häufig auf Forenseiten oder Kommentarmaschinen beobachtet. Ein Angreifer gibt das bösartige Skript in einen Kommentar ein, und bam - jeder Benutzer, der diesen Kommentar aufruft, führt das Skript unwissentlich aus.

Reflektiertes XSS tritt auf, wenn Benutzereingaben unverändert an den Browser des Benutzers zurückgesendet werden. Ein Beispiel ist ein Suchfeld, das dem Benutzer beim Abrufen der Suchergebnisse anzeigt: "Sie haben gesucht nach ...".

Nun stellen Sie sich vor, dass 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 einem bösartigen Skript senden, das in eben diesen Parametern eingebettet ist, und ehrlich gesagt würden die meisten Webbenutzer dies kaum bemerken.

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

DOM XSS ist eine relativ neue Variante dieser Sicherheitslücke. Sie nutzt die komplexen Template-Strukturen, die in vielen UI-Frameworks wie Angular und React zu finden sind.

Diese Templates ermöglichen dynamische Inhalte und reichhaltige UI-Anwendungen. Bei unsachgemäßer Verwendung können sie zur Ausführung von XSS-Angriffen verwendet werden.

So, da haben Sie es. Sie haben den Umfang von XSS in einer Nussschale bekommen. Lassen Sie uns nun tiefer eintauchen, wie es destruktiv eingesetzt werden kann.

Warum ist XSS so gefährlich?

XSS kann dazu verwendet werden, Benutzer auf bösartige Seiten umzuleiten, Cookies zu stehlen und Jagd auf Sitzungsdaten zu machen. Grundsätzlich gilt: Alles, was JavaScript kann, können auch XSS-Angriffe.

Hier sind drei Beispiele für XSS-Angriffe:

  1. Yahoo-E-Mail-Benutzern wurden 2015 ihre Sitzungscookies per XSS gestohlen.
  2. Der Samy-Wurm wurde über eine XSS-Schwachstelle in MySpace verbreitet. Er ist nach wie vor die sich am schnellsten verbreitende Malware aller Zeiten, die in nur 20 Stunden eine Million Benutzer befallen hat.
  3. eBay erlaubte die Einbindung von bösartigen Skripten in Produktbeschreibungen. Dies führte zu XSS-Angriffen gegen eBay-Benutzer.

XSS-Angriffe sind täuschend einfach und sehr schwerwiegend. Sie können zum Diebstahl von Sitzungen, Benutzeranmeldeinformationen oder sensiblen Daten führen. Reputationsschäden und Umsatzeinbußen sind die größten Fallstricke dieser Angriffe. Selbst die bloße Verunstaltung einer Website kann zu unerwünschten Konsequenzen für ein Unternehmen führen.

XSS kann jedoch von einem versierten Sicherheitskämpfer wie Ihnen besiegt werden. Die Lösung ist nicht kompliziert und die Industrie hat einen langen, langen Weg zurückgelegt, seit XSS zu einem häufig genutzten Exploit wurde.

Sie können XSS besiegen.

Der Schlüssel zum Besiegen von XSS ist das Verständnis des Kontexts. Genauer gesagt, der Kontext, in dem Ihre Benutzereingaben an den Client zurückgesendet werden, und wo sie zurückgesendet werden. Innerhalb des HTML-Codes oder innerhalb eines JavaScript-Snippets.

Wenn die Benutzereingabe nicht an den Browser zurückgesendet werden muss, umso besser. Aber wenn doch, sollte sie oft HTML-kodiert sein. Die HTML-Kodierung der Ausgabe weist den Browser an, den Inhalt so zu rendern, wie er ist, und ihn nicht auszuführen.

Die Validierung von Eingaben ist ebenfalls wichtig. Validierung und Whitelisting sind jedoch keine narrensicheren Lösungen. Die Kodierung geht ein paar Schritte weiter und verhindert, dass der Browser ein bösartiges Skript ausführt. Was auch immer mit Validierungs- und Whitelisting-Strategien nicht abgefangen wird, wird durch Kodierung aufgefangen.

Viele Frameworks kodieren die HTML-Ausgabe inzwischen automatisch.
Angular, ASP.NET MVC und React.js sind Frameworks, bei denen standardmäßig HTML-Kodierung verwendet wird. Sie müssen diesen Frameworks ausdrücklich sagen, dass sie nicht kodieren sollen, indem Sie eine spezielle Methode aufrufen.

Die meisten anderen Frameworks (z.B. Django und Spring) haben Standardbibliotheken für die XSS-Prävention, die Sie einfach in Ihren Code einbauen können.

Die größte Herausforderung besteht darin, sich beizubringen, alle Wege zu analysieren, auf denen Benutzereingaben in ein System gelangen können, damit Sie die Augen danach offen halten können. Abfrageparameter können Angriffe tragen, ebenso wie Postparameter. Verfolgen Sie den Datenfluss in Ihrer Anwendung und vertrauen Sie keinen Daten, die von außen kommen.

Denken Sie wie eine Grenzpatrouille. Halten Sie jedes Stück Daten an, inspizieren Sie es und lassen Sie es nicht herein, wenn es bösartig aussieht. Verschlüsseln Sie dann beim Rendern, um sicherzustellen, dass die übersehenen bösartigen Daten trotzdem keine Probleme verursachen.

Führen Sie diese Strategien aus, und Ihre Benutzer werden vor Angriffen über XSS sicher sein. Werfen Sie einen Blick auf das OWASP Cheat Sheet für noch mehr Tipps, um Ihre Daten unter Kontrolle zu halten.

Verhindern Sie XSS und verbessern Sie Ihre Sicherheitsfähigkeiten.

XSS befindet sich auf Platz sieben der OWASP Top 10 Liste 2017 der Web-Sicherheitsrisiken. Es gibt sie schon eine Weile, aber sie können immer noch auftreten und Probleme mit Ihrer Anwendung verursachen, wenn Sie nicht aufpassen.

Schulungen sind für Entwickler sehr wichtig, um eine sicherheitsorientierte Denkweise zu entwickeln, während sie Code erstellen. Und dieses Training ist immer dann am effektivsten, wenn es reale Anwendungen simuliert, und zwar in den Sprachen, die Entwickler aktiv verwenden. Schauen Sie sich in diesem Sinne unsere Lernressourcen an, um mehr über XSS zu erfahren. Danach können Sie mit dem Training und der Praxis beginnen, die zu Ihrer Beherrschung führen.

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

Wir bitten Sie um Ihre Erlaubnis, Ihnen Informationen über unsere Produkte und/oder verwandte Themen der sicheren Codierung zuzusenden. Wir werden Ihre persönlichen Daten immer mit äußerster Sorgfalt behandeln und sie niemals zu Marketingzwecken an andere Unternehmen verkaufen.

Um das Formular abzuschicken, aktivieren Sie bitte "Analytics"-Cookies. Sie können die Cookies wieder deaktivieren, sobald Sie fertig sind.