entwickler.com

Wie angekündigt geht es in dieser Folge weiter um Cross-Site-Request-Forgery (CSRF), und zwar zuerst um die Frage, wie CSRF-Requests so in den Browser eines Benutzers eingeschleust werden können, dass sie ohne weiteres Zutun des Benutzers abgeschickt werden.

Wie wird der CSRF-Request eingeschleust?

Es gibt außer den in About Security #127 genannten Beispielen eine ganze Reihe weiterer Möglichkeiten, einen Benutzer einen HTTP-Request abschicken zu lassen, ohne dass der wie im ersten Beispiel aktiv einen Link anklicken muss. Das Laden einer präparierten Webseite reicht.

Der Parameter [CSRF-URL] in den folgenden Beispielen könnte z.B. die Form
http://www.opfer.example/pfad/zum/skript?aktion=boeses
haben.

• HTML:
  • <img src="[CSRF-URL]">
  • <script src="[CSRF-URL]">
  • <iframe src="[CSRF-URL]">
• JavaScript:
  • Image-Objekt:
    

    <script>
      var foo = new Image();
      foo.src = "[CSRF-URL]";
    </script>
    

  • XMLHttpRequest:
    Mit dem XMLHttpRequest-Request kann auch ein POST-Request ausgelöst werden. Von [CSRF-URL] müssen die Parameter abgetrennt werden: [URL] ist im Folgenden 'http://www.opfer.example/pfad/zum/skript', und [CSRF] ist 'aktion=boeses'.
    

    <script>
      var post_data = '[CSRF]';
      var xmlhttp = new XMLHttpRequest();
      xmlhttp.open("POST", '[URL]');
      xmlhttp.onreadystatechange = function () {
        if (xmlhttp.readyState == 4) { 
           // nichts tun, wir wollen ja nicht auffallen
        } 
      }; 
      xmlhttp.send(post_data);
    </script>
    

• Flash
  Amit Klein hat beschrieben, wie mit Flash beliebige HTTP-Header gesendet werden können: 'Forging HTTP request headers with Flash' (Korrektur dazu). Dabei kann insbesondere auch der Referer-Header gefälscht werden.

Außerdem gibt es etliche weitere Möglichkeiten, einen Webbrowser zum Absenden eines HTTP-Requests zu bewegen. Entsprechende Angriffe sind auch nicht auf Webseiten und Webbrowser beschränkt. Jedes Dokumentenformat, das Skripting erlaubt, kann für einen Angriff ausgenutzt werden. Insbesondere also z.B. E-Mails oder Multimedia-Dateien.

Erkennen von CSRF

Ein Webanwendung ist immer dann über CSRF angreifbar, wenn Aktionen über eine statische URL (GET-Request) oder einen statischen POST-Request ausgeführt werden können, also ein Request, der sich im Laufe der Zeit nicht ändert. Als einfacher Test, ob die eigene Anwendung verwundbar ist oder nicht, können die betroffenen Seiten durchgegangen und alle Requests über einen Proxy wie z.B. Paros aufgezeichnet werden. Später wird das Ganze wiederholt und die aufgezeichneten Requests werden miteinander verglichen. Bleiben die GET- und POST-Requests gleich, ist die Anwendung verwundbar. Änderungen von Cookie-Werten sind unerheblich, da die Cookies vom Webbrowser bei jedem Request automatisch mitgeschickt werden, unabhängig davon, ob der vom Benutzer oder automatisch ausgelöst wurde.

Verhindern von CSRF

Zwei oft genannte Gegenmaßnahmen sind wirkungslos: Das Prüfen des Referer-Headers und das ausschließliche Verwenden von POST-Request. Der Referer kann über Flash (s.o.) und XMLHttpRequests gefälscht werden. Ein POST-Request ist zwar etwas schwerer zu fälschen als der nur aus einem Link bestehende GET-Request, mit etwas JavaScript-Code oder einem einfachen XMLHttpRequest kann aber auch ein gefälschter POST-Request abgeschickt werden.

Eine häufige Schwachstelle sind in diesem Zusammenhang auch Webanwendungen, die nicht darauf achten, wie sie die Daten übermittelt bekommen. Wird z.B. in PHP $_REQUEST['Parameter'] verwendet, kann ein Angreifer die Daten per GET-Request schicken, auch wenn das eigentlich verwendete Formular sie per POST-Request senden würde. Sollen nur Daten aus POST-Requests angenommen werden, muss das durch explizites Verwenden von $_POST['Parameter'] getan werden.

Als wirksame Gegenmaßnahme kann jedes Formular mit einem individuellen, zufällig erzeugten Token versehen werden. Nur Requests mit einem gültigen Token werden ausgeführt. Dadurch kann der Angreifer dem Opfer keinen vorbereiteten gültigen Request unterschieben, sondern muss erst das aktuelle Token ausspähen. In Verbindung mit einer XSS-Schwachstelle in der eigenen Webanwendung oder evtl. einer Schwachstelle im Browser ist aber auch das Ausspähen des Tokens möglich. Sessions sollten daher so kurz wie möglich sein, um das Zeitfenster für einen Angriff zu minimieren. Bei potenziell gefährlichen Aktionen sollte eine Nachfrage ("Aktion ... wirklich ausführen?") oder sogar eine erneute Passwortabfrage erfolgen.

Wichtig ist, dass das Token nicht vorhersagbar ist. Bei einem mit ausreichender Wahrscheinlichkeit vorhersagbaren Token kann der Angreifer einfach mehrere Requests mit möglicherweise passenden Token vorbereiten und dem Opfer unterschieben. Der Request mit gültigen Token wird vom Server ausgeführt, die anderen verworfen. Ob die präparierte Webseite (oder was sonst für den Angriff verwendet wird) einen oder mehrere vorbereitete CSRF-Requests enthält, ist für den Angriff egal.

Soviel vorerst zu CSRF. In der nächsten Folge geht es erneut um Cross-Site-Scripting.

Carsten Eilers