CSRF Protection (Updated)

nospam@example.com (Marc Jakubowski) — Tue, 22 Apr 2008 13:12:49 +0200

Nachdem fukami beim letzten Bonner WebMontag erläutert hatte was CSRF ist und was man alles damit anrichten kann, war mir zunächst nicht ganz klar, wie so etwas in der Praxis ausgenutzt wird und welche Schutzmaßnahmen man dagegen implementieren kann.

Netterweise demonstrierte mir mein Kollege Lary Strojny anhand meines Projekts todoyo.de wie so etwas genau aussieht. Er schickte mir einen unscheinbaren Link, den ich natürlich sofort öffnete und gelangte auf eine einfache Seite mit 3 Images, welche allerdings nicht richtig geladen wurden. Die Bilderpfade lauteten in etwa "http://todoyo.de/task/delete/id/1234". Wäre ich nun bei todoyo eingeloggt gewesen, wären ohne, dass ich etwas gemerkt hätte, einige meiner Aufgaben gelöscht worden. Die IDs der Aufgaben besorgte er sich aus der öffentlichen todoyo-Entwicklerliste. Glücklicherweise war ich nicht eingeloggt ;)

Dadurch wurde mir schlagartig klar, wie CSRF Angriffe funktionieren und welchen Schaden man damit alles anrichten kann, wenn die Seite nicht entsprechend geschützt ist.

Wie sehen nun die Gegenmaßnahmen aus, um so etwas zu verhindern? Folgende Schritte habe ich unternommen: - Aufgaben-IDs aus öffentlichen Listen entfernt
- Bei allen Formularen POST Requests erzwungen
- und anschließend nur POST Variablen auswerten
- Tokens in jedes Formular eingebaut
- Tokens auch für Links zu Datenänderungen benutzen (z.B. einfaches Löschen von Aufgaben per Link statt per Formular)

Im Code sieht das Ganze jetzt so aus:

<?php
// Todoyo/View/Helper/CsrfKey.php
class Todoyo_View_Helper_CsrfKey
{
protected $_token = '';

public function csrfKey()
{
if (empty($_SESSION['tokens'])) {
$_SESSION['tokens'] = array();
}

if (empty($this->_token)) {
$this->_token = md5(uniqid(rand(), TRUE));
$_SESSION['tokens'][] = $this->_token;
$_SESSION['tokens'] = array_slice($_SESSION['tokens'], -100);
}
return $this->_token;
}
}

// Todoyo/Controller/Action.php
class Todoyo_Controller_Action extends Zend_Controller_Action
{
// Prüft ob aktuelle Action geschützt ist und ob CSRF Key gültig ist
public function checkCsrfKey($actions)
{
// Keine CSRF geschützen Actions? Weiter
if (empty($actions)) {
return true;
}
// Action nicht eine der CSRF geschützen Actions? Weiter
if (!in_array($this->_request->getActionName(), $actions)) {
return true;
}

$token = $this->_getParam('x');

// Kein Token oder Token nicht in Session? Abbruch!
if (empty($token) or !in_array($token, (array) $_SESSION['tokens'])) {
$this->_flash->addMessage('Unerlaubte Aktion');
$this->_redirect('/');
return false;
}

// Token war gültig? Token löschen und weiter
$pos = array_search($token, $_SESSION['tokens']);
unset($_SESSION['tokens'][$pos]);
return true;
}

// Prupft ob für aktuelle Action POST erzwungen wurde und wirklich POST ist
public function checkPost($actions)
{
// Keine POST Actions erzwungen? Weiter
if (empty($actions)) {
return true;
}
// Action keine erzwungene POST Action? Weiter
if (!in_array($this->_request->getActionName(), $actions)) {
return true;
}

// Action ist kein POST? Abbruch!
if (!$this->_request->isPost()) {
$this->_flash->addMessage('Fehler beim Verarbeiten der Formulareingaben');
$this->_redirect('/');
}

return $this->checkCsrfKey($actions);
}
}

// TaskController.php
class TaskController extends Todoyo_Controller_Action
{
public function init()
{
parent::init();
$this->checkCsrfKey(array('insert', 'delete'));
$this->checkPost(array('insert'));
}
}

// index/index.phtml
<form action="/task/insert" method="post">
<input type="text" name="title" value="">
<input type="hidden" name="x" value="<?=$this->csrfKey()?>">
<input type="submit" name="submit" value="Speichern">
</form>

<a href=/task/delete/id/1234/x/<?=$this->csrfKey()?>>Aufgabe löschen</a>

Was geschieht im Detail?

Im Template wird nun bei jeder Aktion, die geschützt werden soll, ein CSRF Key (Token) entweder als Hidden Input Feld eingefügt, oder bei Links mit an die URL angehangen. Der CsrfKey-View-Helper liefert bei jedem Aufruf einen neuen zufälligen String, der in der Session gespeichert wird. Pro Seitenaufruf wird ein einziger Token erzeugt und für alle Elemente verwendet. Die Anzahl der gültigen Tokens wurde auf 100 beschränkt, um die Session nicht unnötig aufzublähen und dennoch gültige Requests bei mehreren Tabs/Seiten zu ermöglichen.

Nach dem Abschicken eines Formulars, wird bevor die eigentliche Action ausgeführt wird, geprüft, ob die Aktion durch einen POST-Request entstanden sein muss, was bei Formularen klar der Fall ist. Der Methode "checkPost" werden also alle Actions übergeben, bei denen wir POST erzwingen wollen. Zusätzlich wir bei definierten Actions geprüft, ob sie einen CSRF Key besitzen müssen, und falls ja, ob dieser auch gültig ist (=in der Session vorhanden ist). Wenn ja, dann wird der benutzte Token aus der Session gelöscht und die Action wir ausgeführt. Bei der Verwendung von "checkPost()" wird automatisch auch der CSRF Key überprüft, weil alle Formulare zwingend einen gültigen Token haben müssen, URLs hingegen nur bei Bedarf.

Somit kann man für jeden Controller ganz einfach definieren, welche Actions ausschließlich per POST aufgerufen werden dürfen und welche durch CSRF geschützt werden sollen. In der Regeln ist dies bei allen Aktionen der Fall, bei denen Daten geändert werden (insert, update, delete,...). Bei Anzeige-Aktionen legt man eher Wert auf schöne URLs ohne einen Token.

Für weitere Verbesserungsvorschläge oder Fehlerhinweise wäre ich sehr dankbar :)

UPDATE:
Im deutschen Zend Framework Forum wurden ein paar Vorschläge geäußert:

- Auslagerung der "checkPost()" und "checkCsrf()" Funktionalität in einen eigenen ActionHelper
- Nutzung von Zend_Session_Namespace zum Zugriff auf die Session Tokens
- Erstellung eines Zend_Form_Element um z.B. automatisch bei jedem Form das Hidden Token Element hinzuzufügen

Mein neues Projekt: todoyo.de

nospam@example.com (Marc Jakubowski) — Thu, 17 Apr 2008 00:10:20 +0200

Seit ca 2 Wochen arbeite ich an einem neuen Projekt, welches ich auf den Namen "todoyo - notieren. erledigen. freigeben." bzw auf Englisch "todoyo - note. do. share" getauft habe.
Wie man am Namen erkennen kann geht es um das Thema ToDo-Listen.

Wie kam es dazu?
Nun, seit geraumer Zeit bin ich begeisterter Nutzer diverser Google Services wie Gmail, Google Reader, Google Calendar oder Google Docs.
Diese Anwendungen finde ich deshalb so toll, weil sie großen Wert auf intuitive Bedienbarkeit und Übersichtlichkeit legen und trotzdem eine Menge an Funktionalität bieten. So gibt es jeweile eine Hauptansicht, welche alle Informationen schlicht darstellt und dank Ajax Spielereien eine unterbrechungsfreie Bearbeitung ermöglichen. Hinzu kommt noch, dass ich keine Lust habe Datenbestände zwischen meinem Home-PC und meinem Arbeits-Macbook zu synchronisieren und ich von überall Zugriff darauf habe.

Etwas was mir noch fehlte war eine entsprechende Anwendung um meine privaten Erledigungen und auch Arbeitsaufgaben und Projektschritte zu verwalten. Dafür habe ich eine zeitlang Remember-The-Milk genutzt und auch dessen GMail Integration, aber irgendwie war mir das nicht schlicht genug und zu umständlich. Warum also nicht selbst versuchen es besser zu machen, wenn man schonmal PHP Entwickler ist ;)

Hinzu kam noch, dass ich unbedingt einmal ein paar neue Komponenten des Zend Frameworks ausprobieren wollte, welche ich bislang noch nicht direkt genutzt hatte, wie z.B. Zend_Layout mit dem ViewRenderer, Internationalisierung oder die diversen Service Komponenten. jQuery wollte ich mir in dem Zusammenhang auch einmal genauer anschauen.

Nach ein paar Überlegungen wie ich die Handhabung der Anwendung am effektivsten gestalten könnte, legte ich los und begann erst einmal mit der Kernfunktionalität: den Listen und Aufgaben. Dies ging alles überraschend einfach, da das ZendFramework einem extrem viel des MVC Designs abnimmt und die Applikationsstruktur grob vorgibt. Danach folgten Schritt für Schritt immer mehr Features und Optimierungen.

Als Template Engine habe ich nach jahrelanger Smarty Nutzung mal wieder reines PHP (mit Short-Open-Tags) benutzt, was einem etwas mehr Freiheiten als Smarty bietet, wobei man aufpassen muss nicht plötzlich Logik in die somit mächtigen Templates zu packen.
Zwischenzeitlich hatte ich einmal versucht, das Projekt auf Smarty umzuschreiben, bin aber daran gescheitert, dass eine Zend_Layout Nutzung dadurch quasi unmöglich wurde und nur mit hässlichen Workarounds funktioniert hätte. Also Änderungen verworfen und weiter mit PHP als Template Sprache.

Praktisch war, dass ich die Listen- und Aufgaben Funktionalität von todoyo selbst für dessen eigene Entwicklung nutzen und gleichzeitig testen konnte. Mittlerweile ist die Entwicklungs-Todo-Liste Liste immer länger geworden, da einem natürlich immer mehr interessante Features einfallen, die man realisieren könnte.

Also auf jeden Fall ein nettes Projekt für zwischendurch. Auch wenn es später vielleicht kaum jemand nutzen wird, so erfüllt es auf jeden Fall meine eigenen Anforderungen, die ich an ToDo-Listen stelle und wird mich in Zukunft in meinem Alltag unterstützen.

Also, schaut es euch doch einmal an :)

blOgtave - todoyo.de

CSRF Protection (Updated)

Mein neues Projekt: todoyo.de