Was ist Cross-Site-Scripting? Wie kann man XSS-Angriffe verhindern?

Wenn wir an Cyberangriffe denken, denken wir an Datenverletzungen, Viren und Malware, aber haben Sie schon einmal von Cross-Site-Scripting, auch bekannt als XSS-Angriffe, gehört? Wahrscheinlich nicht. Obwohl es eine der berüchtigtsten und häufigsten Bedrohungen in den Webanwendungen ist, die wir heute nutzen. Was ist es also?

Webanwendungen lassen Benutzer oft mit ihnen interagieren, indem sie Daten über Formulare oder andere Eingabefelder einreichen. Hacker können diese Schwachstelle ausnutzen, um bösartige Skripte einzufügen, wenn die Anwendung diese Benutzereingaben nicht ausreichend validiert und bereinigt.

XSS-Angriffe stellen erhebliche Risiken dar, einschließlich finanzieller Verluste, Datenverletzungen, kompromittierter Systeme, beschädigter Ruf und rechtlicher Konsequenzen. Entwickler und Website-Besitzer müssen robuste Sicherheitsmaßnahmen implementieren und Tools wie Webanwendungs-Firewalls und Software für einheitliches Bedrohungsmanagement einrichten, um XSS-Schwachstellen zu verhindern.

Wie funktioniert Cross-Site-Scripting (XSS)?

Beginnen wir mit dem Lernen über die Same-Origin-Policy, um zu verstehen, wie Cross-Site-Scripting-Angriffe funktionieren.

Same-Origin-Policy

Die Same-Origin-Policy ist ein eingebauter Sicherheitsmechanismus in Webbrowsern, der Datendiebstahl verhindert. Zum Beispiel wird Inhalt von einer Website die Erlaubnis erteilt, Cookies und andere Ressourcen im Webbrowser eines Benutzers zu verwenden. Gemäß der Same-Origin-Policy teilt Inhalt von jeder URL mit demselben Uniform Resource Identifier (URI), Hostnamen und Portnummer auch diese Berechtigungen. Wenn sich diese drei Attribute unterscheiden, benötigt die Seite eine separate Erlaubnis.

Wenn die Same-Origin-Policy nicht strikt durch Websicherheitsmaßnahmen wie Validierung und Bereinigung von Benutzereingaben durchgesetzt wird, entstehen Schwachstellen in Webanwendungen.

Cross-Site-Scripting-Angriffe verwenden typischerweise JavaScript, aber auch andere clientseitige Programmiersprachen wie PHP, Hypertext Markup Language (HTML) und .NET funktionieren.

Die Anatomie eines Cross-Site-Scripting-Angriffs

Gehen wir ein Beispiel durch, um zu verstehen, wie ein XSS-Angriff funktioniert:

Angenommen, es gibt eine Webanwendung mit einem Kommentarbereich, in dem Benutzer Nachrichten posten können, die auf der Website angezeigt werden. Der Kommentarbereich der Anwendung hat jedoch eine Schwachstelle, die Benutzereingaben nicht ordnungsgemäß validiert oder bereinigt, bevor sie angezeigt werden.

Ein Angreifer identifiziert dies und nutzt die Schwachstelle aus, indem er schädlichen JavaScript-Code in einen der Kommentarbereiche der Webseite injiziert. Sie posten einen Kommentar mit folgendem Inhalt:

Nun, anstatt den injizierten Code als reinen Text zu behandeln, zeigt die ungeschützte Anwendung den Kommentar auf der Website ohne ordnungsgemäße Codierung oder Validierung an. Wenn andere Benutzer die Webseite besuchen, die diesen Kommentar enthält, interpretieren ihre Browser den injizierten JavaScript-Code als Teil des Website-Inhalts und führen ihn aus.

Infolgedessen erscheint ein Warnfenster, das die Nachricht anzeigt, "Dies ist ein bösartiger Cross-Site-Scripting (XSS) Angriff, Vorsicht!" 

Wenn das nicht schon schlimm genug wäre, könnten die Folgen des Angriffs je nach den Absichten des Cyberkriminellen noch viel schwerwiegender sein. Bedrohungsakteure könnten das ausgeführte Skript nutzen, um sensible Informationen zu stehlen, Benutzer auf Phishing-Websites umzuleiten, Tastenanschläge zu protokollieren, Formulareingaben zu erfassen oder das System zu kompromittieren, indem sie Malware herunterladen und ausführen.

XSS-Angriff vs. CSRF vs. SQL-Injektion

Es ist leicht, XSS mit SQL-Injektion und Cross-Site-Request-Forgery (CSRF) zu verwechseln, da alle drei Schwachstellen in Webanwendungen ausnutzen. Sie sind jedoch unterschiedliche Bedrohungen für die Websicherheit und unterscheiden sich in ihrer Natur und der Art der Angriffe, die sie hervorrufen.

• XSS-Angriffe injizieren bösartige Codes in eine vertrauenswürdige Website und verursachen, dass der Webbrowser des Benutzers sie unbeabsichtigt ausführt.
• Cross-Site-Request-Forgery täuscht einen autorisierten Benutzer, indem es Social-Engineering-Techniken wie Phishing verwendet, um bösartige Anfragen im Namen des Benutzers zu stellen.
• SQL-Injektionsangriffe injizieren bösartigen SQL-Code in die Datenbankschicht einer Webanwendung, um auf Daten zuzugreifen, die nicht angezeigt werden sollten.

Geschichte der XSS-Angriffe

XSS-Schwachstellen reichen bis in die frühen Tage des Internets zurück. Als Webseiten mit der Einführung von JavaScript im Jahr 1995 interaktiver wurden, begannen Entwickler, Benutzereingaben über Formulare und andere kooperative Elemente auf Webseiten zu akzeptieren.

Die Entwickler validierten und bereinigten die Benutzereingaben jedoch nicht effektiv und legten Schwachstellen offen, die Angreifer ausnutzen konnten – und taten. Ein Team von Microsoft-Sicherheitsingenieuren prägte erstmals den Begriff „Cross-Site-Scripting“ für diese Angriffe, und im Laufe der Zeit erweiterte sich seine Definition, um andere Arten von Code-Injektionsangriffen einzuschließen.

Vor 2005 konzentrierten sich die meisten Sicherheitsforscher auf andere Bedrohungen für die Websicherheit wie Buffer-Overflow-Angriffe, Würmer, Botnets oder Viren. Das war bis zum berüchtigten Samy-Wurm auf MySpace, der über eine Million Benutzer in 24 Stunden mit einem XSS-Angriff infizierte und sein potenzielles Ausmaß und seine Auswirkungen demonstrierte.

Nach dem verheerenden Schlag unternahm die Cybersicherheitsgemeinschaft lobenswerte Anstrengungen, um die XSS-Schwachstellen zu beheben. Aber selbst dann bleibt es eine anhaltende Bedrohung für die Sicherheit von Webanwendungen. Große Websites wie Orkut, Youtube, Yahoo Mail, eBay, Amazon, Twitter und Facebook haben im Laufe der Jahre XSS-Angriffe erlebt.

3 Haupttypen von XSS-Angriffen mit Beispielen

XSS-Angriffe werden im Allgemeinen in drei Hauptkategorien eingeteilt:

• Gespeicherte Cross-Site-Scripting-Angriffe (persistent)
• Reflektierte Cross-Site-Scripting-Angriffe (nicht persistent)
• Document Object Model (DOM)-basierte XSS-Angriffe

1. Gespeicherte XSS-Angriffe (persistent)

Gespeichertes oder persistentes Cross-Site-Scripting tritt auf, wenn ein bösartiges Skript dauerhaft auf dem Server der Ziel-Webanwendung gespeichert und Benutzern präsentiert wird, die auf eine bestimmte Seite zugreifen. Dies geschieht normalerweise, wenn Benutzereingaben nicht ordnungsgemäß validiert und bereinigt werden, bevor sie gespeichert werden.

Das schädliche Skript wird automatisch ausgeführt, wenn andere Benutzer die injizierte Seite laden. Da die Nutzlast vom Webserver gespeichert und dann in eine HTML-Seite eingebettet wird, die dem Benutzer bereitgestellt wird, wird dies als gespeicherter XSS-Angriff bezeichnet.

Das häufigste Beispiel für einen gespeicherten XSS-Angriff sind nicht bereinigte HTML-Codes, die als Nachrichten in Online-Foren, Besucherprotokollen oder Kommentarfeldern gepostet werden. Jeder Benutzer, der auf die Seite klickt, auf der der Kommentar erscheint, ist von dem Angriff betroffen, ohne zum Kommentarbereich scrollen oder sogar darauf klicken zu müssen.

2. Reflektierte XSS-Angriffe (nicht persistent)

App-Entwickler müssen am häufigsten auf diese achten. Bei einem reflektierten XSS-Angriff gibt ein Benutzer einer App eine Eingabe, und dann macht der nicht persistente Angriff, dass serverseitige Skripte diese Daten sofort verwenden. Die Skripte nutzen diese Informationen, um dem Benutzer eine Webseite anzuzeigen, aber die Eingabe wurde nicht ordnungsgemäß bereinigt.

Es wird als reflektierter Cross-Site-Scripting-Angriff bezeichnet, weil der Server die bösartige Nutzlast sofort als Antwort auf eine HTTP-Anfrage des ahnungslosen Opfers zurückgibt.

Zum Beispiel hat eine vertrauenswürdige Webanwendung namens mybank.com eine Suchfunktion. Sie zeigt die Suchanfrage der Benutzer auf der Ergebnisseite an, ohne ordnungsgemäße Validierung und Ausgabe-Codierung. Ein Angreifer könnte die folgende bösartige URL konstruieren, um diese Schwachstelle auszunutzen:

Der Angreifer wird dann diese legitim aussehende URL über E-Mail oder andere neutrale Websites an Benutzer senden. Da sie denken, dass sie von ihrer Bank-Website stammt, klickt einer der Benutzer auf den erstellten Link, und das Skript des Hackers wird ausgeführt, und das Opfer merkt nichts davon. 

3. DOM-basierte XSS-Angriffe

DOM-basierte XSS-Angriffe wurden erstmals 2005 vom Webanwendungssicherheitsforscher Amit Klein definiert. Das Document Object Model ist die objektorientierte Darstellung einer Webseite, die dynamische Inhalte unterstützt. DOM-basierte XSS-Angriffe treten auf, wenn Hacker DOM-Schwachstellen ausnutzen. Die Webseite ändert sich nicht, aber der clientseitige Code mit der schädlichen Nutzlast im DOM wird im Browser des Benutzers ausgeführt.

DOM-basierte XSS-Angriffe erfolgen vollständig auf der Client-Seite, im Gegensatz zu gespeicherten und reflektierten XSS-Angriffen, die aufgrund von Schwachstellen auf der Server-Seite auftreten.

Andere Arten von XSS-Angriffen

Abgesehen von den drei oben genannten Hauptkategorien von XSS-Angriffen gibt es mehrere andere Variationen von XSS-Angriffen, die spezifische Schwachstellen ausnutzen.

Self-XSS

Self-Cross-Site-Scripting ist eher ein Social-Engineering-Angriff, bei dem der Eindringling den Benutzer dazu verleitet, selbst ein bösartiges JavaScript in seinen eigenen Browser einzufügen. Sie locken die Opfer typischerweise an, indem sie eine Nachricht posten, die besagt, dass der Benutzer eine Belohnung erhalten kann, indem er einen bestimmten Code kopiert und ausführt. In Wirklichkeit ermöglicht der Code dem Angreifer, das Konto des Opfers zu kapern.

Mutation XSS

Mutation XSS oder mXSS werden durch eine Schwachstelle in der DOM-Eigenschaft namens innerHTML und die Art und Weise, wie der HTML-Code beim Bereitstellen dynamischer Inhalte geparst wird, ermöglicht. Hacker injizieren speziell gestaltete bösartige Codes, die sicher erscheinen, sich aber im Browser in XSS-Angriffsvektoren verwandeln und mutieren.

Blind XSS

Eine Variante von persistenten XSS-Angriffen, bei denen blinde Cross-Site-Scripting-Angriffe dazu führen, dass bösartige Nutzlasten in einem Webanwendungsserver gespeichert werden, um nur vom Backend-Benutzer oder dem Anwendungsadministrator ausgeführt zu werden.

7 XSS-Angriffspräventionsmaßnahmen

Schwachstellen bestehen weiterhin in vielen unserer Web-Apps, aber Forscher haben mehrere XSS-Lösungen vorgeschlagen, von einfacher statischer Analyse bis hin zu komplexen Laufzeitschutzmechanismen. Einige davon werden hier besprochen.

1. Web-Frameworks und sichere Codierungsbibliotheken

Moderne Web-Frameworks und sichere Codierungsbibliotheken bieten eine standardisierte Möglichkeit, Webanwendungen im Internet zu entwickeln und bereitzustellen, ohne sicherheitsrelevante Design- und Implementierungsfehler. Ein Entwickler hat möglicherweise nicht alle Ressourcen, um Sicherheitsfunktionen ordnungsgemäß zu implementieren, wenn er eine App von Grund auf neu erstellt. Die Arbeit mit sicheren Codierungsbibliotheken und Web-Framework-Tools hilft, Sicherheitslücken oder Fehler im Code zu vermeiden.

2. Eingabevalidierung und Ausgabe-Codierung

Eingabevalidierung und Ausgabe-Codierung sind wichtige Verteidigungstechniken gegen XSS-Angriffe. Die Eingabevalidierung stellt sicher, dass benutzergenerierter Inhalt im erwarteten Format vorliegt und lehnt oder neutralisiert alle Daten ab, die nicht den Kriterien entsprechen.

Die Ausgabe-Codierung bereinigt alle Sonderzeichen in der unbekannten benutzergenerierten Eingabe, sodass sie als reiner Text interpretiert werden. Dies bestätigt, dass der Webbrowser Benutzereingaben unter keinen Umständen als Markup oder JavaScript-Code registriert. Beide Techniken verhindern Sicherheitslücken, die XSS ausnutzen kann.

3. HTML-Bereinigung

Eine Reihe von Webanwendungsentwicklern verwenden What You See Is What You Get (WYSIWYG)-Editoren, um Text- und Videoinhalte für ihre Webseiten in HTML-Sprache zu erstellen. In diesen Fällen wird es wichtig, die HTML-Codes zu bereinigen, um sich gegen XSS-Angriffe zu schützen.

Die HTML-Bereinigung erlaubt grundlegende HTML-Tags wie <b>, <i>, <u>, <em> und <strong>. Gleichzeitig entfernt sie fortgeschrittenere Tags wie <script>, <object>, <embed> und <link>, die verwendet werden können, um bösartige Codes einzufügen.

Die Open Source Foundation for Application Security (OWASP), eine führende Sicherheitsgemeinschaft, empfiehlt die Verwendung von DOMPurify zur HTML-Bereinigung.

4. Cookie-Sicherheit

Da XSS und andere Cyberangriffe auf Web-Cookies abzielen, ist es wichtig, eine ordnungsgemäße Cookie-Sicherheit zu implementieren. Sie können dies tun, indem Sie Cookie-Attribute wie das „secure“-Flag und „HttpOnly“ verwenden, um zu bestätigen, dass die Cookies nur über eine sichere Verbindung übertragen werden.

5. Content Security Policy (CSP)

CSP ist eine zusätzliche Verteidigungsschicht für Website-Besitzer gegen XSS und andere Cyberbedrohungen wie Clickjacking und Code-Injektionsangriffe. Es definiert und beschränkt die Quellen, von denen Webbrowser Inhalte laden können, wie Skripte, Stylesheets oder Bilder, und die URLs, von denen sie geladen werden können. CSP verhindert, dass bösartige Codes ausgeführt werden, indem vertrauenswürdige Quellen angegeben und Inhalte blockiert oder eingeschränkt werden.

6. Sicherheitstests

Regelmäßige Sicherheitstests, einschließlich Schwachstellenscans und Penetrationstests, klassifizieren und adressieren XSS-Schwachstellen. Manuelle Codeüberprüfungen, Schwachstellenscanner und Software-Test-Tools mit Automatisierung können Teil Ihrer Routine sein, um potenzielle Schwächen zu erkennen und die Wirksamkeit von Präventionstechniken gegen XSS zu messen.

7. Webanwendungs-Firewalls (WAF)

WAFs sind die am häufigsten verwendete Cybersicherheitssoftware zum Schutz von Web-Apps vor XSS und SQL-Injektionen. Sie überwachen und filtern eingehenden Datenverkehr und verwenden Analysen, um abnormale Anfragen an die Anwendung zu blockieren und die Injektion bösartiger Skripte zu verweigern.

Sicherheitssoftware wie Plattformen für einheitliches Bedrohungsmanagement (UTM) schützt auch effektiv vor XSS-Angriffen, indem sie mehrere Sicherheitsfunktionen integriert.

Cross-Site-Scripting: Häufig gestellte Fragen (FAQs)

1. Was ist Cross-Site-Scripting?

Cross-Site-Scripting (XSS) greift Schwachstellen in der Sicherheit von Webanwendungen an, die es Hackern ermöglichen, bösartige Skripte in Webseiten einzufügen. Diese Skripte stehlen sensible Informationen, manipulieren Benutzerinteraktionen oder liefern Malware.

2. Welche Sprache wird bei Cross-Site-Scripting-Angriffen verwendet?

Jede clientseitige Programmiersprache wie Javascript, HTML, VBScript oder Flash kann verwendet werden, um bösartige Codes in Cross-Site-Scripting-Angriffen zu schreiben. Aber Javascript und HTML werden am häufigsten für XSS-Angriffe verwendet.

3. Was sind die drei Arten von Cross-Site-Scripting-Angriffen?

Drei Haupttypen von XSS sind gespeichertes XSS, reflektiertes XSS und DOM-basiertes XSS. 

4. Was ist der Unterschied zwischen XSS und CSRF?

XSS injiziert und führt bösartige Skripte im Browser eines Benutzers aus, während CSRF darauf abzielt, das Vertrauen in die authentifizierte Sitzung eines Benutzers auszunutzen, um unbefugte Aktionen in seinem Namen auszuführen.

5. Was ist der Unterschied zwischen XSS und SQL-Injektion?

XSS-Angriffe zielen auf die Benutzer der Website ab. SQL-Injektion konzentriert sich auf die Datenablage- und Abrufmechanismen der Website.

Verteidigung des digitalen Bereichs

Heute läuft die Welt auf Apps. Cross-Site-Scripting bleibt eine gefährliche Sicherheitslücke. Es setzt Webbenutzer Fernzugriff, Datendiebstahl und finanziellen Verlusten aus. Aber mit dem richtigen Bewusstsein und Präventionsmaßnahmen kann seine Wirkung gemildert werden, wenn Sie helfen können, ein sichereres Web zu skripten, wenn Sie die hier geteilten Präventionsmaßnahmen umsetzen.

Möchten Sie sicherere Codes schreiben? Erfahren Sie mehr über sichere Code-Trainingssoftware und wie sie Entwicklern und Programmierern hilft.