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.