EN

Reflektierte Cross-Site-Scripting-Schwachstelle

In diesem Artikel:

Reflected XSS, auch bekannt als nicht-persistente Angriffe, ist einer der unkompliziertesten Cross-Site-Scripting-Angriffe. In diesem Artikel wird erläutert, was Reflected XSS ist, welche typischen Beispiele es für solche Angriffe gibt und welche bewährten Verfahren zur Vermeidung der zugrunde liegenden Schwachstellen eingesetzt werden können. 

Was ist ein XSS-Angriff?

Cross-Site-Scripting ist eine Sicherheitslücke in clientseitigen Anwendungen, die es dem Angreifer ermöglicht, Benutzerinteraktionen mit dem Webserver/der Anwendung zu manipulieren. Unter Verletzung der Same-Origin-Policy nutzen Angreifer unsichere Eingabeschnittstellen und Clientseitiges Scripting aus, um Schadcode auszuführen. Dabei wird das Opfer dazu verleitet, die Seite mit dem bösartigen Skript zu besuchen, so dass der ausführbare Code an den Browser des Opfers übermittelt wird. 

Bei solchen Angriffen geben sich Hacker häufig auch als kompromittierte Benutzer aus, um auf die Daten des Opfers zuzugreifen und Aktionen mit dessen Berechtigungen auszuführen. In Fällen, in denen das Opfer ein Benutzer mit privilegiertem Zugang ist, können Angreifer die Daten und Funktionen der Anwendung vollständig kompromittieren. Jede Anwendung, die bei der Generierung von Skriptausgaben die Benutzereingaben nicht validiert, ist anfällig für XSS-Angriffe. 

XSS-Angriffe werden im Allgemeinen in folgende Kategorien eingeteilt:

Was ist ein Reflected Cross-Site Scripting-Angriff?

Reflektierte (nicht persistente) XSS-Angriffe treten auf, wenn die schadhafte Payload in der an die angreifbare Webanwendung gesendeten Anfrage enthalten ist und dann reflektiert wird, so dass die HTTP-Antwort des Servers aus der Payload besteht. Die Angreifer nutzen Social-Engineering-Techniken wie Phishing-Angriffe, um das Opfer dazu zu bringen, den Schadcode in seine Anfrage an den Webserver aufzunehmen. Der Browser des Opfers führt dann den Schadcode als HTTP-Antwort aus. 

Reflektierte XSS-Angriffe sind nicht persistent, so dass jedes Opfer die Anfrage mit einer schadhaften Payload senden muss. Daher neigen die Angreifer dazu, so viele Benutzer wie möglich auszutricksen, um den Angriff erfolgreich durchzuführen. Solche Angriffe zielen oft auf die Eingabe von Formularen in Nachrichtenforen, Fehlermeldungen oder Suchmaschinenergebnisseiten ab, da es dort einfacher ist, eine bösartige E-Mail-Nachricht zu erstellen, auf die viele Benutzer klicken können. Als eine der häufigsten Arten von XSS-Angriffen erfordert reflektiertes XSS nicht, dass der Angreifer eine anfällige Webanwendung ausfindig macht und darauf zugreift, um bösartige Skripte dauerhaft einzuschleusen.

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

Wie man Reflected XSS verhindert und wie wichtig es für die Sicherheit ist

Ein reflektierter XSS-Angriff ist eine häufig genutzte Form der XSS-Schwachstelle. Im Folgenden finden Sie einige gängige Präventionsmechanismen, die Unternehmen nutzen sollten, um reflektierte Cross-Site-Scripting-Schwachstellen in Webanwendungen zu verhindern.

Prävention von reflektiertem Cross-Site Scripting

Beim Schutz vor reflektiertem XSS geht es in erster Linie darum, die Verwendung dynamischer schadhafter Inhalte aus HTTP-Anfragen in eine angreifbare Anwendung zu vermeiden. Einige Ansätze, um dies zu erreichen, sind:

Validierung von Benutzereingaben

Die Validierung von Benutzereingaben bzw. die Filterung von Inhalten bildet die erste Verteidigungslinie gegen die meisten XSS-Angriffe, einschließlich reflektiertem XSS. Es ist wichtig, Benutzereingaben aus beliebigen Quellen als nicht vertrauenswürdig zu behandeln und Mechanismen zur Überprüfung der semantischen und grammatikalischen Anforderungen zu formulieren. 

Sicherheitsteams sollten auch Whitelists/Blacklists für Datenmuster anwenden, die akzeptiert oder abgelehnt werden sollen. Darüber hinaus wird empfohlen, dass QS- und Adminteams Daten sowohl von authentifizierten als auch von öffentlichen Benutzern als nicht vertrauenswürdige Eingaben behandeln und für alle Benutzer die gleichen Techniken zur Bereinigung von Eingaben anwenden. 

Dynamischen Inhalten entgehen

Angenommen, die Anwendung stützt sich auf vom Benutzer eingegebener Daten als Teil ihrer HTTP-Antworten. In diesem Fall sollten die Ausgabedaten so kodiert werden, dass der Server sie nicht als aktive Inhalte interpretiert. Dadurch wird sichergestellt, dass alle Sonderzeichen aus dem Datenspeicher der Anwendung als HTML-Tag-Inhalt und nicht als rohes HTML behandelt werden. 

Es wird empfohlen, alle signifikanten dynamischen Zeichen durch HTML-Entity-Kodierungsschemata zu ersetzen, damit sie sicher interpretiert werden können. Wenn dynamische Inhalte in die <script>- und <style>-Tags eingefügt werden, sollten Entwickler spezielle Tools verwenden, um eine sichere Stylesheet- und Skriptkodierung zu ermöglichen. 

Implementierung einer Sicherheitsrichtlinie für Inhalte

Mit einer robusten Content-Security-Policy (CSP) können Webadministratoren/Entwickler kontrollieren, von wo die Webseite Skripte laden und ausführen kann. Da ein XSS-Angriff darauf beruht, dass der Angreifer bösartige Inhalte in eine Webseite einbettet, verhindern CSPs Angriffe, indem sie die Quellen von Inline-Skripten angeben. 

Die Entwickler geben den Browsern über eine Kopfzeile oder ein Meta-Element für die Content-Security-Policy Anweisungen, einschließlich Richtlinien für Quellen und Senken bestimmter Ressourcen und Aktionen. Webentwickler können die zulässigen Quellen von vertrauenswürdigen Skripten mit einer Direktive der Form „whitelisten“:

Content-Security-Policy: script-src 'self' https://darwin.com

Diese Richtlinie ermöglicht die vertrauenswürdige Ausführung von Skripten des Servers, der die aktuelle Seite hostet, und von Skripten, die von https://darwin.com stammen.

Die meisten modernen Browser unterstützen CSPs, was sie zu einem der wichtigsten Aspekte bei der Verhinderung von reflektierten XSS-Angriffen macht.

Verwenden Sie ein Tool zum Scannen von Sicherheitslücken

Schwachstellen-Scan-Tools testen automatisch Webanwendungen und den zugrunde liegenden Quellcode, um Sicherheitslücken zu identifizieren, die zur erfolgreichen Ausführung von XSS-Angriffen führen können. Die Crashtest Security Suite enthält ein XSS-Tool, das JavaScript und Webanwendungen auf Sicherheitslücken wie XSS scannen kann, ohne dass es zu Fehlalarmen kommt. 

Warum ist die Verhinderung von reflektierten XSS-Schwachstellen wichtig für Ihr Unternehmen?

Reflektierte XSS-Schwachstellen ermöglichen es böswilligen Benutzern, Inline-Skripte und JavaScript zu missbrauchen. Der Schweregrad der Angriffe hängt von den betroffenen Funktionen und Daten ab. Infiziertes JavaScript kann auf alle Sitzungs-Token zugreifen, die für die betroffene Webseite verfügbar sind, so dass Angreifer sich als legitime Benutzer ausgeben können, indem sie deren Sitzungen stehlen. Angreifer können auch eine reflektierte XSS-Schwachstelle ausnutzen, um über HTML5-APIs auf Benutzerdateien, Geolocation, Mikrofon und andere Geräte zuzugreifen. Anwendungsentwickler müssen solche Schwachstellen beheben, um Benutzerdaten und Anwendungsfunktionen zu schützen.

Beispiele für reflektierte XSS-Attacken

Nachfolgend sind einige gängige Ansätze aufgeführt, mit denen Angreifer reflektierte XSS-Angriffe durchführen.

1. Reflektierter XSS-Angriff auf eine Suchanfrage

Angenommen, eine Webanwendung akzeptiert einen Suchstring von Benutzern über einen Suchparameter innerhalb eines Abfrage-Strings:

http://darwin.com/aform.html?search=Hacker1

In diesem Fall verwendet der Anwendungsserver PHP, um den vom Benutzer eingegebenen Wert auf der Ergebnisseite anzuzeigen, indem er ihn aus der URL zieht und dann das resultierende HTML generiert:

<?php echo 'You Searched:' .$_GET["search"];?>

Der Webserver parst den vom Benutzer eingegebenen Wert in der URL direkt in HTML, ohne Eingabevalidierung oder Ausgabecodierung. In solchen Fällen können Angreifer beliebigen Code erstellen, der im Browser ausgeführt wird, wenn das Opfer auf die URL klickt:

http://darwin.com/aform.html?search=<script>alert('XSS by Product1');</script>

Dieses Skript verschafft den Hackern Zugriff auf das Sitzungs-Cookie des Benutzers und ermöglicht es ihnen, die Identität eines rechtmäßigen Benutzers anzunehmen.

2. Reflektierter XSS-Angriff auf eine Fehlermeldung

Angenommen, eine Webseite akzeptiert einen Eingabeparameter, der den in einer Fehlermeldung angezeigten Text enthält, und zeigt ihn direkt in ihrer Antwort an. In diesem Fall nutzen Angreifer solche Schwachstellen, um XSS-Angriffe zu inszenieren. 

Angenommen, die URL, die die Fehlermeldung zurückgibt, lautet:

http://darwin.com/error/5/Error.ashx?message=Sorry%20+some+error+message

Die zurückgegebene Fehlerseite kopiert direkt die Werte des Parameters der URL und zeigt sie dann in geeigneter Weise auf der Seite an:

<p>Sorry, some error message</>

Ohne Sanitization oder angemessene Validierung können Angreifer eine bösartige Nutzlast erstellen, um einen Popup-Bildschirm zu erzeugen:

http://darwin.com/error/5/Error.ashx?message=<script>alert("XSS by Hacker1")</script>

Wenn ein ahnungsloser Benutzer diese Seite aufruft, führt der Browser das bösartige Skript aus und leitet den Benutzer zu einer HTML-Seite mit folgendem Inhalt anstelle des eigentlichen Inhalts weiter:

<p><script>alert("XSS by Hacker1");</script></p>

Lesen Sie unseren Leitfaden zur Vermeidung von XSS-Schwachstellen

Reflektierte XSS-Schwachstelle – FAQs

Die Unterschiede: Gespeicherte XSS VS Reflektierte XSS

Beim persistenten/gespeicherten Cross-Site-Scripting speichert die Webanwendung die ungültige Eingabe, die dann später im Browser des Clients auf unsichere Weise ausgeführt wird. Bei dieser Art von Angriff muss der Angreifer potenzielle Schwachstellen in der Webanwendung identifizieren und dann die bösartige Nutzlast in den Server injizieren. 

Bei reflektiertem/nicht-persistentem XSS wird der Schadcode in eine HTTP-Anfrage eingebettet, so dass er vom Client-Browser als Teil der HTTP-Antwort des Servers zur Ausführung zurückgesendet wird. 

Wie kann ich auf reflektierte XSS-Sicherheitslücken testen?

Es ist zwar möglich, solche Schwachstellen manuell zu testen, aber es wird empfohlen, automatische Scanner wie die Crashtest Security Suite zu verwenden, um reflektierte XSS-Schwachstellen zu finden und zu beheben. Entwickler und QA-Teams sollten zunächst die Vektoren für Benutzereingaben identifizieren, in der Regel mithilfe eines Web-Proxys oder eines HTML-Editors. 

Anschließend können sie die von OWASP zur Verfügung gestellte Liste von Testeingabedaten verwenden, um die Eingabevektoren auf reflektierte XSS-Schwachstellen zu analysieren. Diese Analyseergebnisse werden verwendet, um festzustellen, ob die Website anfällig ist und welche Schwachstellen die größten Auswirkungen haben könnten.

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.