Freitag, 20. April 2012


Topthema

Mittwoch, 17. Oktober 2007 | Topthema

About Security #127: Cross-Site Request Forgery: Einführung

(Link zum Artikel: http://www.entwickler.de/php/kolumnen/038733)
  • Teilen
  • kommentieren
  • empfehlen
  • Bookmark and Share

Beim Cross-Site Request Forgery (CSRF) wird anders als beim Cross-Site Scripting (XSS), bei dem das Vertrauen des Benutzers in eine Webseite ausgenutzt wird, das Vertrauen einer Webanwendung in den Benutzer ausgenutzt: Bestimmte Aktionen werden durch den Aufruf eines bestimmten URL ausgelöst und dabei im Kontext des eingeloggten Benutzers ausgeführt. Bei einem CSRF-Angriff wird das Opfer dazu gebracht, einen präparierten HTTP-Request abzuschicken, der dann eine Aktion in seinem Namen ausführt. Werden dabei Informationen über eine gültige Session des Opfers verwendet, spricht man manchmal auch von Session Riding.

CSRF – Ein alter Hut?

Die Probleme, die sich durch das Vertrauen einer Anwendung in einen Benutzer ergeben, wurden erstmals bereits 1988 unter dem Namen "Confused Debuty" von Norm Hardy beschrieben. 2000 wurde eine entsprechende Schwachstelle in ZOPE gefunden, 2001 von Peter Watkins der Begriff "Cross Site Request-Forgery" geprägt. Der Begriff "Session Riding" (PDF) wurde 2004 von Thomas Schreiber das erste Mal verwendet.

Wie funktioniert CSRF?

Webanwendungen, die eine Authentifizierung erfordern, fragen in der Regel nicht bei jedem HTTP-Request das Passwort ab, sondern merken sich den Status des Benutzers mithilfe von Tokens wie Session Cookies oder der HTTP Basic Authentication. Diese Tokens werden vom Browser bei jedem HTTP-Request mitgeschickt. Auch wenn dieser Request nicht vom Benutzer, sondern von eingeschleustem Schadcode ausgelöst wird.

N E U ! Security aktuell
Täglich aktuelle Security-Infos!

Als einfachstes Beispiel wird häufig das Abmelden eines Benutzers bei einer Webanwendung genannt. Dazu soll als Beispiel folgender URL verwendet werden:

http://www.server.example/user/index.php?aktion=abmelden

Der Benutzer soll dabei durch einen Session ID Cookie erkannt werden. Klickt ein angemeldeter Benutzer diesen Link an, wird er dadurch abgemeldet. Den benötigten Cookie sendet der Webbrowser automatisch mit. Angenommen, die Webanwendung ist eine Forensoftware, die das Speichern von Links erlaubt. Dann könnte der Angreifer z.B. einen Eintrag wie folgenden hinterlassen:

Für eine kostenlose Dose Spam
<a href="http://www.server.example/user/index.php?aktion=abmelden">hier</a>
klicken.

Klickt ein Benutzer den Link an, bekommt er keinen kostenlosen Spam, sondern ist im Forum abgemeldet.

Dieses Beispiel hat einen schwerwiegenden Nachteil: Der Benutzer muss den präparierten Link anklicken. Das Ganze geht aber auch ohne Aktion des Benutzers, das Laden einer präparierten Webseite reicht, wie folgendes Beispiel zeigt:

Ein neuer Benutzer kann angelegt werden, indem ein durch einen Cookie authentifizierter Administrator den URL

http://www.server.example/admin/adduser.php?name=[Der Name]&pass=[Das Passwort]

aufruft. Ein Angreifer kann dem Administrator nun eine Seite mit folgendem Tag darin unterschieben:

<img src="http://www.server.example/admin/adduser.php?name=boese&pass=boese">

Ruft der (eingeloggte) Administrator die Seite auf, passiert Folgendes: Der Browser sendet einen GET-Request zum Laden des angegebenen Bilds – und auf dem Server wird der Befehl zum Anlegen des Benutzers ausgeführt. Den Cookie, mit dem der eingeloggte Administrator erkannt wird, hat der Browser gehorsam mitgeschickt.

Auch ein Angriff gegen ein Formular, das statt eines GET- einen POST-Request verwendet, ist möglich. Ein Formular für obiges Beispiel könnte so aussehen:

<form method="post" action="http://www.server.example/admin/adduser.php">
Name: <input name="benutzername"> <br>
Passwort: <input name="passwort"> <br>
<input type=submit value="Benutzer anlegen">
</form>

Die übertragenen Daten werden im Request verborgen und tauchen nicht in dem URL auf. Aber ein Angreifer kann dem Benutzer einfach eine Seite mit einem sich selbst absendenden Formular darin unterschieben:

<form name="CSRF" method="post" action="http://www.server.example/admin/adduser.php">
<input type="hidden" name="benutzername" value="boese">
<input type="hidden" name="passwort" value="boese">
</form>
<script>document.CSRF.submit()</script>

Ruft der (eingeloggte) Administrator die Seite auf, wird das Formular abgesendet, als hätte der Benutzer auf den (nicht vorhandenen) Submit-Button geklickt. Den Cookie zur Erkennung des Administrators sendet der Browser wieder automatisch mit.

About Security: Die komplette Serie

Ein letztes Beispiel: Ein Benutzer sitzt hinter einer Firewall, deren webbasiertes Administrationstool durch eine HTTP-Basic-Authentication geschützt ist. Die Regeln der Firewall lassen sich durch folgenden GET-Request löschen:

http://192.168.1.1/admin/delrule?rule=[Nummer der Regel]

Wird statt einer Zahl ein * eingegeben, werden alle Regeln gelöscht. Dem angemeldeten Benutzer wird nun ein entsprechender Link untergeschoben, z.B. in einer Webseite mit folgendem Tag darin:

<script src="http://192.168.1.1/admin/delrule?rule=*">

Beim Laden der Seite versucht der Browser, das gewünschte Skript zu laden und sendet dabei den GET-Request zum Löschen aller Regeln an die Firewall. Den zugehörigen HTTP Authorisation Header sendet der Browser automatisch mit. Danach kann der Angreifer, von der Firewall ungestört, das lokale Netz angreifen.

Statt der Firewall-Regeln könnte so auch z.B. die Verschlüsselung und Authentifizierung eines WLAN-Access-Points ausgeschaltet werden, wenn dessen Weboberfläche eine entsprechende Schwachstelle enthält. Das Bemerkenswerte daran: Der Angreifer kann Anwendungen angreifen, die hinter einer Firewall vor ihm verborgen sind. Nur das Opfer muss Zugriff auf die Anwendungen haben.

In der nächsten Folge werden u.a. Gegenmaßnahmen gegen CSRF-Angriffe vorgestellt.

Wenn Sie Fragen oder Themenvorschläge haben, können Sie diese gerne an die angegebene E-Mail-Adresse senden oder im Security-Forum einbringen!

Carsten Eilers

About Security – Übersicht zum aktuellen Thema "Sichere Webanwendungen – Cross-Site-Request-Forgery"

Kommentare

Folgende Links könnten Sie auch interessieren