Dipl.-Inform. Carsten Eilers

Es gibt außer den bereits genannten Möglichkeiten noch eine ganze Reihe weiterer Möglichkeiten, einen Benutzer einen HTTP-Request abschicken zu lassen, ohne das 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.

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

<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>

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.

Ein möglicher Angriffsvektor für IoT-Geräte könnten präparierte Anleitungen zur Konfiguration oder Problemlösung sein. Während der Benutzer die liest ist er oft beim IoT-Gerät angemeldet, so dass ein CSRF-Angriff mit großer Wahrscheinlichkeit erfolgreich ist. Früher hätte der Angreifer dazu eine eigene Anleitung ins Web stellen und warten müssen, bis erst die Suchmaschinen und danach die Benutzer diese Seite finden. Heutzutage könnte so ein Angriff auch über eine präparierte Werbeanzeige auf einer eigentlich harmlosen Website erfolgen. Bisher werden die zwar "nur" für Drive-by-Infektionen genutzt, aber warum sollten die Cyberkriminellen sie nicht auch für andere Zwecke nutzen, wenn es sich lohnt?

CSRF-Schwachstellen erkennen

Ein Webanwendung ist immer dann über CSRF angreifbar, wenn Aktionen über einen statischen URL (GET-Request) oder einen statischen POST-Request ausgeführt werden können, also einen Request, der sich im Laufe der Zeit nicht ändert.

Als einfacher Test, ob eine Anwendung verwundbar ist oder nicht, können die betroffenen Seiten durchgegangen und alle Requests über einen Proxy wie z.B. dem OWASP Zed Attack Proxy 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.

CSRF-Angriffe abwehren

In erster Linie müssen die Entwickler der Weboberflächen ihre Anwendungen absichern. Aber auch Sie als Benutzer können das Risiko eines Angriffs minimieren, aber dazu komme ich gleich.

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 muss jedes Formular mit einem individuellen, zufällig erzeugten Token versehen werden. Nur Requests mit einem gültigem 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 potentiell 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.

Als Benutzer eines IoT-Geräts sollten Sie es vermeiden, gleichzeitig in dessen Weboberfläche eingeloggt zu sein und im Web zu browsen. Gelangen Sie dabei auf eine präparierte Seite mit einem CSRF-Angriff für ihr Gerät, ist dieser Angriff erfolgreich (sofern es eine CSRF-Schwachstelle in der Weboberfläche gibt).

Wenn Sie unbedingt im Web browsen müssen, während Sie beim IoT-Gerät angemeldet sind, sollten Sie fürs browsen und die Administration getrennte Browser verwenden. Dann schlägt ein in den "Browser-Browser" eingeschleuster CSRF-Angriff fehl, da dieser Browser kein Authentifizierungs-Token für die Weboberfläche des IoT-Geräts besitzt. Das kennt nur der "Administrations-Browser", und in dem findet ja kein CSRF-Angriff statt.

Hiermit ist der Punkt "Insecure Web Interface" der Top IoT Vulnerabilities von OWASP abgeschlossen. In der nächsten Folge geht es folglich um den nächsten Punkt, "Insufficient Authentication/Authorization".

Carsten Eilers