Oft gibt es mehr als einen Weg die Challenges zu lösen. Damit der Juice Shop die Challenge im Score Board als gelöst erkennen kann, erfordert es den genauen Angriffsvektor einzufügen.
Mögliche Angriffsvektoren:
<iframe src="javascript:alert(`xss`)">
<script>alert(`xss`)</script>
Reflektiertes Cross-Site Scripting (XSS) tritt auf, wenn der Angriffsvektor innerhalb eines Requests gespiegelt wird. Der Angriff wird nicht in der Anwendung selbst gespeichert. Der Angriff ist nicht persistent und betrifft nur Benutzer, die einen in böser Absicht erstellten Link oder eine Webseite eines Drittanbieters öffnen. Der Angriffsstring wird als Teil der manipulierten URL- oder HTTP-Parameter eingefügt und an das Opfer zurückgegeben.
Suchen Sie nach einem Eingabefeld welches in einer HTML-Response gespiegelt wird.
Versuchen Sie, nach XSS-Sicherheitslücken zu suchen, indem Sie Text mit einem HTML-Tag versehen.
Eine DOM-basierte XSS-Schwachstelle tritt auf, wenn ein DOM-Element, beispielsweise über eine JavaScript Funktion von einem Angreifer gesteuert werden kann.
Diese Challenge ist fast nicht von einen reflektierten XSS-Angriff zu unterscheiden.
In der Architekturübersicht wurde Ihnen mitgeteilt, dass der Juice Shop ein modernes Single Page Application Frontend verwendet. Das war nicht ganz richtig.
Finden Sie eine Seite in der Anwendung, die im Vergleich zu allen anderen seltsam aussieht.
Was ist noch besser als eine selbst erstellte Validierung auf Basis eines RegEx? Eigene sanitization auf Basis einer RegEx!
Diese Challenge beruht auf einer sehr häufigen Sicherheitslücke bei Webanwendungen, bei der die Entwickler die folgende goldene Regel der Eingabevalidierung ignorierten:
"Stellen Sie sicher, dass jede auf dem Client durchgeführte Eingabevalidierung auch auf dem Server ausgeführt wird."
POST – Request an /api/Users senden.
Nicht alle Eingabefelder werden validiert.
Noch weniger dieser Felder werden so beibehalten, dass ihr Inhalt auf einem anderen Bildschirm angezeigt wird.
Wie kann das Umgehen der clientseitigen Validierung erfolgen?
Deaktivieren Sie die Validierung auf dem Browser.
Oder Sie ignorieren es und agieren stattdessen direkt mit dem Backend.
Für diese Challenge ist es erforderlich, direkt mit der serverseitigen API zu arbeiten.
Die HTTP-Methoden (PUT, POST) für die API können Ihnen helfen.
Unvorsichtige Entwickler haben möglicherweise API-Methoden verfügbar gemacht, die der Client nicht einmal benötigt.
Dies ist eine der schweren XSS-Challenges, da sie nicht durch das Umgehen der clientseitigen Validierung gelingt. Wann immer es eine serverseitige Validierung gibt, sollten Sie untersuchen, wie diese genau funktioniert. Möglicherweise deckt die Validierung nicht alle Angriffsfälle ab.
Ihr Fokus sollte auf dem Kontaktfeld liegen.
Suchen Sie nach möglichen Abhängigkeiten in Bezug auf die Eingabeverarbeitung in der Datei package.json.bak