Coders Conquer Security: Teilen und Lernen - Cross-Site Scripting (XSS)
Cross-Site-Scripting (XSS) ist seit den frühen 2000er Jahren ein Ärgernis für Sicherheitsexperten, und leider gehört es auch nach Jahrzehnten noch zu den häufigsten Bedrohungen auf Code-Ebene. Diese Art von Software-Schwachstelle hat uns schon viel zu lange geplagt, und eine aktuelle Warnung der CISA - als Teil ihrer Secure-by-Design-Bewegung - versucht, sie ein für alle Mal zu beseitigen. Die CISA befindet sich auf einer globalen Mission zur Beseitigung von Schwachstellenklassen im großen Maßstab, und dieses Augenmerk auf die entwicklergesteuerte Sicherheit kann wirklich etwas bewirken, aber dazu bedarf es des Engagements von intelligenten Unternehmen, die ihre Entwickler für den Erfolg in Sachen Sicherheit fit machen.
Was genau ist XSS?
Webbrowser sind vielleicht unser Tor zu all den tollen Dingen im Internet, aber leider gibt es nicht nur gute Nachrichten. Das inhärente Verhalten von Webbrowsern kann ein Katalysator für Sicherheitsschwachstellen sein. Zu Beginn vertrauten die Browser in der Regel auf das Markup, das sie sahen, und führten es ohne zu hinterfragen aus. Das ist alles schön und gut, bis diese Funktionalität für unappetitliche Zwecke ausgenutzt wird... und natürlich haben Angreifer schließlich Wege gefunden, diese Tendenz für ihre bösen Zwecke auszunutzen.
Cross-Site Scripting nutzt das Vertrauen der Browser und die Unwissenheit der Benutzer, 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 verhindern kann:
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:
- Benutzer besucht eine Web-Seite
- Die Seite teilt dem Browser mit, welche Dateien geladen und was ausgeführt werden soll
- 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.
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:
- Yahoo-E-Mail-Benutzern wurden 2015 ihre Sitzungscookies per XSS gestohlen.
- 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.
- 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 .
Cross-Site-Scripting (XSS) nutzt das Vertrauen von Browsern und die Unwissenheit der Benutzer aus, um Daten zu stehlen, Konten zu übernehmen und Websites zu verunstalten; es ist eine Schwachstelle, die sehr schnell sehr hässlich werden kann. Lassen Sie uns einen Blick darauf werfen, wie XSS funktioniert, welchen Schaden es anrichten kann und wie man es verhindern kann.
Jaap Karan Singh ist ein Secure Coding Evangelist, Chief Singh und Mitbegründer von Secure Code Warrior.
Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Demo buchen
Jaap Karan Singh ist ein Secure Coding Evangelist, Chief Singh und Mitbegründer von Secure Code Warrior.
Cross-Site-Scripting (XSS) ist seit den frühen 2000er Jahren ein Ärgernis für Sicherheitsexperten, und leider gehört es auch nach Jahrzehnten noch zu den häufigsten Bedrohungen auf Code-Ebene. Diese Art von Software-Schwachstelle hat uns schon viel zu lange geplagt, und eine aktuelle Warnung der CISA - als Teil ihrer Secure-by-Design-Bewegung - versucht, sie ein für alle Mal zu beseitigen. Die CISA befindet sich auf einer globalen Mission zur Beseitigung von Schwachstellenklassen im großen Maßstab, und dieses Augenmerk auf die entwicklergesteuerte Sicherheit kann wirklich etwas bewirken, aber dazu bedarf es des Engagements von intelligenten Unternehmen, die ihre Entwickler für den Erfolg in Sachen Sicherheit fit machen.
Was genau ist XSS?
Webbrowser sind vielleicht unser Tor zu all den tollen Dingen im Internet, aber leider gibt es nicht nur gute Nachrichten. Das inhärente Verhalten von Webbrowsern kann ein Katalysator für Sicherheitsschwachstellen sein. Zu Beginn vertrauten die Browser in der Regel auf das Markup, das sie sahen, und führten es ohne zu hinterfragen aus. Das ist alles schön und gut, bis diese Funktionalität für unappetitliche Zwecke ausgenutzt wird... und natürlich haben Angreifer schließlich Wege gefunden, diese Tendenz für ihre bösen Zwecke auszunutzen.
Cross-Site Scripting nutzt das Vertrauen der Browser und die Unwissenheit der Benutzer, 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 verhindern kann:
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:
- Benutzer besucht eine Web-Seite
- Die Seite teilt dem Browser mit, welche Dateien geladen und was ausgeführt werden soll
- 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.
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:
- Yahoo-E-Mail-Benutzern wurden 2015 ihre Sitzungscookies per XSS gestohlen.
- 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.
- 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 .
Cross-Site-Scripting (XSS) ist seit den frühen 2000er Jahren ein Ärgernis für Sicherheitsexperten, und leider gehört es auch nach Jahrzehnten noch zu den häufigsten Bedrohungen auf Code-Ebene. Diese Art von Software-Schwachstelle hat uns schon viel zu lange geplagt, und eine aktuelle Warnung der CISA - als Teil ihrer Secure-by-Design-Bewegung - versucht, sie ein für alle Mal zu beseitigen. Die CISA befindet sich auf einer globalen Mission zur Beseitigung von Schwachstellenklassen im großen Maßstab, und dieses Augenmerk auf die entwicklergesteuerte Sicherheit kann wirklich etwas bewirken, aber dazu bedarf es des Engagements von intelligenten Unternehmen, die ihre Entwickler für den Erfolg in Sachen Sicherheit fit machen.
Was genau ist XSS?
Webbrowser sind vielleicht unser Tor zu all den tollen Dingen im Internet, aber leider gibt es nicht nur gute Nachrichten. Das inhärente Verhalten von Webbrowsern kann ein Katalysator für Sicherheitsschwachstellen sein. Zu Beginn vertrauten die Browser in der Regel auf das Markup, das sie sahen, und führten es ohne zu hinterfragen aus. Das ist alles schön und gut, bis diese Funktionalität für unappetitliche Zwecke ausgenutzt wird... und natürlich haben Angreifer schließlich Wege gefunden, diese Tendenz für ihre bösen Zwecke auszunutzen.
Cross-Site Scripting nutzt das Vertrauen der Browser und die Unwissenheit der Benutzer, 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 verhindern kann:
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:
- Benutzer besucht eine Web-Seite
- Die Seite teilt dem Browser mit, welche Dateien geladen und was ausgeführt werden soll
- 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.
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:
- Yahoo-E-Mail-Benutzern wurden 2015 ihre Sitzungscookies per XSS gestohlen.
- 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.
- 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 .
Klicken Sie auf den unten stehenden Link und laden Sie die PDF-Datei dieser Ressource herunter.
Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Bericht ansehenDemo buchen
Jaap Karan Singh ist ein Secure Coding Evangelist, Chief Singh und Mitbegründer von Secure Code Warrior.
Cross-Site-Scripting (XSS) ist seit den frühen 2000er Jahren ein Ärgernis für Sicherheitsexperten, und leider gehört es auch nach Jahrzehnten noch zu den häufigsten Bedrohungen auf Code-Ebene. Diese Art von Software-Schwachstelle hat uns schon viel zu lange geplagt, und eine aktuelle Warnung der CISA - als Teil ihrer Secure-by-Design-Bewegung - versucht, sie ein für alle Mal zu beseitigen. Die CISA befindet sich auf einer globalen Mission zur Beseitigung von Schwachstellenklassen im großen Maßstab, und dieses Augenmerk auf die entwicklergesteuerte Sicherheit kann wirklich etwas bewirken, aber dazu bedarf es des Engagements von intelligenten Unternehmen, die ihre Entwickler für den Erfolg in Sachen Sicherheit fit machen.
Was genau ist XSS?
Webbrowser sind vielleicht unser Tor zu all den tollen Dingen im Internet, aber leider gibt es nicht nur gute Nachrichten. Das inhärente Verhalten von Webbrowsern kann ein Katalysator für Sicherheitsschwachstellen sein. Zu Beginn vertrauten die Browser in der Regel auf das Markup, das sie sahen, und führten es ohne zu hinterfragen aus. Das ist alles schön und gut, bis diese Funktionalität für unappetitliche Zwecke ausgenutzt wird... und natürlich haben Angreifer schließlich Wege gefunden, diese Tendenz für ihre bösen Zwecke auszunutzen.
Cross-Site Scripting nutzt das Vertrauen der Browser und die Unwissenheit der Benutzer, 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 verhindern kann:
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:
- Benutzer besucht eine Web-Seite
- Die Seite teilt dem Browser mit, welche Dateien geladen und was ausgeführt werden soll
- 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.
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:
- Yahoo-E-Mail-Benutzern wurden 2015 ihre Sitzungscookies per XSS gestohlen.
- 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.
- 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 .
Inhaltsübersicht
Jaap Karan Singh ist ein Secure Coding Evangelist, Chief Singh und Mitbegründer von Secure Code Warrior.
Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Demo buchenHerunterladenRessourcen für den Einstieg
Die Leistungsfähigkeit von OpenText Fortify + Secure Code Warrior
OpenText Fortify und Secure Code Warrior bündeln ihre Kräfte, um Unternehmen dabei zu helfen, Risiken zu reduzieren, Entwickler zu Sicherheits-Champions zu machen und Kundenvertrauen aufzubauen. Lesen Sie hier mehr darüber.
Benchmarking von Sicherheitskompetenzen: Optimierung von Secure-by-Design im Unternehmen
Die Secure-by-Design-Bewegung ist die Zukunft der sicheren Softwareentwicklung. Erfahren Sie mehr über die wichtigsten Elemente, die Unternehmen berücksichtigen müssen, wenn sie über eine Secure-by-Design-Initiative nachdenken.
Ressourcen für den Einstieg
10 wichtige Vorhersagen: Secure Code Warrior über den Einfluss von KI und Secure-by-Design im Jahr 2025
Unternehmen stehen vor schwierigen Entscheidungen über den Einsatz von KI, um die langfristige Produktivität, Nachhaltigkeit und den Sicherheits-ROI zu unterstützen. In den letzten Jahren ist uns klar geworden, dass KI die Rolle des Entwicklers niemals vollständig ersetzen wird. Von KI + Entwicklerpartnerschaften bis hin zum zunehmenden Druck (und der Verwirrung) rund um die Secure-by-Design-Erwartungen - lassen Sie uns einen genaueren Blick darauf werfen, was wir im nächsten Jahr erwarten können.
OWASP Top 10 für LLM-Bewerbungen: Was ist neu, was hat sich geändert, und wie bleibt man sicher?
Bleiben Sie bei der Absicherung von LLM-Anwendungen mit den neuesten OWASP Top 10 Updates immer einen Schritt voraus. Entdecken Sie, was neu ist, was sich geändert hat und wie Secure Code Warrior Sie mit aktuellen Lernressourcen ausstattet, um Risiken in der generativen KI zu minimieren.
Trust Score zeigt den Wert von Secure-by-Design-Upskilling-Initiativen
Unsere Forschung hat gezeigt, dass Schulungen für sicheren Code funktionieren. Trust Score verwendet einen Algorithmus, der auf mehr als 20 Millionen Lerndaten aus der Arbeit von mehr als 250.000 Lernenden in über 600 Organisationen basiert, und zeigt, wie effektiv die Initiative ist, um Schwachstellen zu beseitigen und wie man sie noch effektiver gestalten kann.
.png)
Reaktive versus präventive Sicherheit: Prävention ist das bessere Heilmittel
Der Gedanke, Legacy-Code und -Systeme zur gleichen Zeit wie neuere Anwendungen mit präventiver Sicherheit auszustatten, kann entmutigend erscheinen, aber ein Secure-by-Design-Ansatz, der durch die Weiterbildung von Entwicklern durchgesetzt wird, kann die besten Sicherheitsverfahren auf diese Systeme anwenden. Dies ist für viele Unternehmen die beste Chance, ihre Sicherheitslage zu verbessern.
Entwicklergesteuerte Kodierung.
Sicher ist sicher.
Setzen Sie sich noch heute mit uns in Verbindung und machen Sie Softwaresicherheit zu einem festen Bestandteil Ihres Entwicklungsprozesses.
