Testen von Cross-Site-Scripting
Cross-Site Scripting (XSS) wird immer dann ausgeführt, wenn eine Anwendung nicht vertrauenswürdige Daten aufnimmt und diese ohne Validierung an den Client (Browser) sendet. Auf diese Weise können Angreifer schädliche Skripts im Browser des Opfers ausführen, was dazu führen kann, dass Benutzersitzungen entführt, Websites verunstaltet oder der Benutzer auf schädliche Websites umgeleitet wird.
Lassen Sie uns anhand eines einfachen Diagramms die Bedrohungsagenten, Angriffsmethoden, Sicherheitsschwächen, technischen Auswirkungen und geschäftlichen Auswirkungen dieses Fehlers verstehen.
Arten von XSS
Stored XSS - Gespeichertes XSS, auch als beständiges XSS bezeichnet, tritt auf, wenn Benutzereingaben auf dem Zielserver gespeichert sind, z. B. Datenbank / Nachrichtenforum / Kommentarfeld usw. Anschließend kann das Opfer die gespeicherten Daten aus der Webanwendung abrufen.
Reflected XSS - Reflektiertes XSS, auch als nicht persistentes XSS bezeichnet, tritt auf, wenn Benutzereingaben von einer Webanwendung sofort in einer Fehlermeldung / einem Suchergebnis oder den vom Benutzer im Rahmen der Anforderung bereitgestellten Eingaben zurückgegeben werden, ohne dass die vom Benutzer bereitgestellten Daten dauerhaft gespeichert werden.
DOM Based XSS - DOM-basiertes XSS ist eine Form von XSS, wenn sich die Datenquelle im DOM befindet, sich die Senke ebenfalls im DOM befindet und der Datenfluss den Browser niemals verlässt.
Beispiel
Die Anwendung verwendet nicht vertrauenswürdige Daten in der Konstruktion ohne Validierung. Die Sonderzeichen sollten maskiert werden.
http://www.webpage.org/task/Rule1?query=tryDer Angreifer ändert den Abfrageparameter in seinem Browser auf -
http://www.webpage.org/task/Rule1?query=<h3>Hello from XSS"</h3>Hände an
Step 1- Melden Sie sich bei Webgoat an und navigieren Sie zum Abschnitt Cross-Site Scripting (XSS). Lassen Sie uns einen XSS-Angriff (Stored Cross-Site Scripting) ausführen. Unten ist der Schnappschuss des Szenarios.
Step 2- Melden Sie sich gemäß dem Szenario als Tom mit dem Kennwort 'tom' an, wie im Szenario selbst angegeben. Klicken Sie auf "Profil anzeigen" und wechseln Sie in den Bearbeitungsmodus. Da Tom der Angreifer ist, lassen Sie uns Java-Skript in diese Bearbeitungsfelder einfügen.
<script>
alert("HACKED")
</script>
Step 3 - Sobald das Update beendet ist, erhält Tom eine Warnmeldung mit der Meldung "gehackt", was bedeutet, dass die App anfällig ist.
Step 4 - Jetzt müssen wir uns gemäß dem Szenario als Jerry (HR) anmelden und prüfen, ob Jerry vom injizierten Skript betroffen ist.
Step 5 - Nachdem Sie sich als Jerry angemeldet haben, wählen Sie "Tom" und klicken Sie wie unten gezeigt auf "Profil anzeigen".
Während er Toms Profil von Jerrys Konto aus anzeigt, kann er dasselbe Meldungsfeld erhalten.
Step 6 - Dieses Meldungsfeld ist nur ein Beispiel, aber der eigentliche Angreifer kann viel mehr als nur das Anzeigen eines Meldungsfelds.
Vorbeugende Mechanismen
Entwickler müssen sicherstellen, dass sie allen nicht vertrauenswürdigen Daten entkommen, die auf dem HTML-Kontext basieren, z. B. Body, Attribut, JavaScript, CSS oder URL, in die die Daten gestellt werden.
Für Anwendungen, die Sonderzeichen als Eingabe benötigen, sollten robuste Validierungsmechanismen vorhanden sein, bevor sie als gültige Eingaben akzeptiert werden.