Programmierer erobern die Sicherheit: 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 der Browser und die Unwissenheit der Benutzer, um Daten zu stehlen, Konten zu übernehmen und Websites zu verunstalten. Es handelt sich um eine Sicherheitslücke, die sehr schnell sehr hässlich werden kann. Schauen wir uns an, wie XSS funktioniert, welcher Schaden angerichtet werden kann und wie man ihn verhindern kann.
Jaap Karan Singh ist ein Secure Coding Evangelist, Chief Singh und Mitbegründer von Secure Code Warrior.
Secure Code Warrior für Ihr Unternehmen da, um Ihnen zu helfen, Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder jemand anderes sind, der sich mit Sicherheit befasst, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Eine 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 untenstehenden Link und laden Sie das PDF dieser Ressource herunter.
Secure Code Warrior für Ihr Unternehmen da, um Ihnen zu helfen, Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder jemand anderes sind, der sich mit Sicherheit befasst, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Bericht ansehenEine 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 .
Inhaltsverzeichnis
Jaap Karan Singh ist ein Secure Coding Evangelist, Chief Singh und Mitbegründer von Secure Code Warrior.
Secure Code Warrior für Ihr Unternehmen da, um Ihnen zu helfen, Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder jemand anderes sind, der sich mit Sicherheit befasst, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Eine Demo buchenHerunterladenRessourcen für den Einstieg
Themen und Inhalte der Securecode-Schulung
Unsere branchenführenden Inhalte werden ständig weiterentwickelt, um der sich ständig ändernden Softwareentwicklungslandschaft unter Berücksichtigung Ihrer Rolle gerecht zu werden. Themen, die alles von KI bis XQuery Injection abdecken und für eine Vielzahl von Rollen angeboten werden, von Architekten und Ingenieuren bis hin zu Produktmanagern und QA. Verschaffen Sie sich einen kleinen Einblick in das Angebot unseres Inhaltskatalogs nach Themen und Rollen.
Die Kamer van Koophandel setzt Maßstäbe für entwicklergesteuerte Sicherheit in großem Maßstab
Die Kamer van Koophandel berichtet, wie sie sicheres Codieren durch rollenbasierte Zertifizierungen, Trust Score-Benchmarking und eine Kultur der gemeinsamen Verantwortung für Sicherheit in die tägliche Entwicklungsarbeit integriert hat.
%20(1).avif)
.avif)
Bedrohungsmodellierung mit KI: So wird jeder Entwickler zum Bedrohungsmodellierer
Sie werden besser gerüstet sein, um Entwicklern dabei zu helfen, Ideen und Techniken zur Bedrohungsmodellierung mit den KI-Tools zu kombinieren, die sie bereits verwenden, um die Sicherheit zu erhöhen, die Zusammenarbeit zu verbessern und von Anfang an widerstandsfähigere Software zu entwickeln.
Ressourcen für den Einstieg
Cybermon ist zurück: Beat the Boss KI-Missionen jetzt auf Abruf verfügbar
Cybermon 2025 Beat the Boss ist jetzt das ganze Jahr über in SCW verfügbar. Setzt fortschrittliche KI/LLM-Sicherheitsanforderungen ein, um die sichere KI-Entwicklung in einem großen Maßstab zu stärken.
Cyber-Resilienz-Gesetz erklärt: Was das für die Entwicklung von Secure by Design-Software bedeutet
Erfahren Sie, was der EU Cyber Resilience Act (CRA) verlangt, für wen er gilt und wie sich Entwicklungsteams mit sicheren Methoden, der Vorbeugung von Sicherheitslücken und dem Aufbau von Fähigkeiten für Entwickler darauf vorbereiten können.
Enabler 1: Definierte und messbare Erfolgskriterien
Enabler 1 eröffnet unsere zehnteilige Reihe „Enabler of Success“ und zeigt, wie sichere Codierung mit Geschäftsergebnissen wie Risikominderung und Geschwindigkeit verbunden werden kann, um eine langfristige Programmreife zu erreichen.
