Module
XSS und DOM-Sinks, Content Security Policy (CSP), Trusted Types, Cookie- und Storage-Grenzen, Subresource Integrity (SRI), Clickjacking. Die Aufgaben 1 bis 6 sind XSS, Aufgabe 7 ist Validierung nur im Client, Aufgabe 8 ist ein Bonus-Payload auf demselben DOM-XSS-Sink wie Aufgabe 2.
Oft gibt es mehr als einen Weg. Damit der Juice Shop die Aufgabe auf dem Score Board als gelöst erkennt, muss genau der erwartete Marker im Payload stecken.
Mögliche Marker, die der Shop auswertet:
<iframe src="javascript:alert(`xss`)"><script>alert(`xss`)</script>Bis auf die DOM-XSS-Aufgabe sind diese Lücken unter Docker nur simuliert. Mit --env NODE_ENV=unsafe beim Docker-Run werden sie tatsächlich ausnutzbar – wie bei M04 und M09.
Einen reflektierten XSS-Angriff mit diesem Payload ausführen:
<iframe src="javascript:alert(`xss`)">Einen URL-Parameter suchen, dessen Wert auf der Zielseite wieder auftaucht.
Zum Testen reicht oft Text in einem HTML-Tag, der auf dem Bildschirm sofort sichtbar ist.
Einen DOM-XSS-Angriff mit diesem Payload ausführen:
<iframe src="javascript:alert(`xss`)">Ein Eingabefeld suchen, dessen Inhalt nach dem Absenden im HTML der Seite landet.
Die Aufgabe ist kaum von reflektiertem XSS zu unterscheiden, ohne nachzuschauen, was die Anwendung mit der Eingabe macht.
Darauf achten, ob die Ausgabe erst im Browser zusammengesetzt wird – ohne dass der Server den Payload spiegeln muss.
Die Content Security Policy umgehen und XSS auf einer Legacy-Seite in der Anwendung ausführen:
<script>alert(`xss`)</script>In der Architekturübersicht heißt es, der Juice Shop habe ein modernes Single-Page-Application-Frontend. Das ist nicht die ganze Wahrheit.
Eine Seite finden, die im Vergleich zum Rest merkwürdig altmodisch wirkt.
Bevor XSS versucht wird: schauen, wie die Seite ihre Content Security Policy setzt.
Was ist noch besser als eine selbst gebaute Validierung per RegEx? Eine selbst gebaute Bereinigung per RegEx – auf derselben Seite, die schon CSP-Probleme hat.
Persistentes XSS mit diesem Payload ausführen und dabei einen clientseitigen Schutz umgehen:
<iframe src="javascript:alert(`xss`)">Eine sehr häufige Lücke: Prüfung nur im Client. Jede Prüfung, die der Client macht, muss der Server ebenfalls machen.
Nur wenige Formularfelder prüfen ihre Eingabe überhaupt.
Noch weniger Felder werden so gespeichert, dass ihr Inhalt später auf einem anderen Bildschirm landet.
Clientseitige Validierung so umgehen: Validierung im Browser abschalten (DOM manipulieren) oder das Backend direkt ansprechen und die Oberfläche ignorieren.
Persistentes XSS mit diesem Payload ausführen – ohne das Frontend überhaupt zu benutzen:
<iframe src="javascript:alert(`xss`)">Direkt mit der serverseitigen API arbeiten. Verschiedene HTTP-Methoden auf den über die API sichtbaren Entitäten ausprobieren.
Eine Übersicht aus bekannten Datenobjekten und den dafür erlaubten HTTP-Verben hilft weiter.
Unvorsichtige Entwicklung hat oft API-Methoden freigegeben, die der Client gar nicht braucht.
Persistentes XSS mit diesem Payload ausführen und dabei einen serverseitigen Schutz umgehen:
<iframe src="javascript:alert(`xss`)">Fokus auf dem Kommentarfeld unter Kontakt / Customer Feedback.
Der Validator lehnt den Payload nicht ab – er wird vor dem Speichern aus dem Kommentar gestrippt.
In package.json.bak nach Abhängigkeiten suchen, die mit der Eingabeverarbeitung zu tun haben.
Erscheint ein XSS-Alert, die Aufgabe auf dem Score Board aber nicht als gelöst: dann steht vermutlich nicht exakt der erwartete Marker in der Datenbank.
Unter Kontakt / Customer Feedback ist eine Abgabe erst mit Kommentar und 1 bis 5 Sternen vorgesehen. Feedback mit 0 Sternen durchbringen.
Bevor die API umgangen wird, erst an der Oberfläche spielen.
Die Regel „mindestens ein Stern“ lebt nur im Browser. Der Server prüft sie nie nach.
Kürzeste Demo dafür, dass eine Prüfung im Client noch keine Durchsetzung ist.
Denselben DOM-XSS-Sink wie in Aufgabe 2 nutzen – diesmal mit dem Bonus-Payload:
<iframe width="100%" height="166" scrolling="no" frameborder="no" allow="autoplay" src="https://w.soundcloud.com/player/?url=https%3A//api.soundcloud.com/tracks/771984076&color=%23ff5500&auto_play=true&hide_related=false&show_comments=true&show_user=true&show_reposts=false&show_teaser=true"></iframe>Zuerst Aufgabe 2 (DOM-XSS) lösen. Danach denselben Eingabepunkt verwenden.
Den Bonus-Payload exakt einfügen – kein eigener Marker nötig.
Lautstärke vorher hochdrehen. Der Payload bettet einen Player ein.