CSRF Cookies zur Gefahrenabwehr: Bedeutung und Problem mit dem Datenschutz

Kategorien: Datenschutz und Cookies

Sogenannte CSRF Tokens werden eingesetzt, um Hackerangriffe durch schädliche Links, die einem Webseitenbetreiber untergejubelt werden, zu unterbinden. Werden CSRF Cookies falsch eingesetzt, droht ein Verstoß gegen das TTDSG bzw. TDDDG.

Grundlagen

CSRF steht für Cross Site Request Forgery. Das bedeutet in etwa „Fälschen von Anfragen durch Einschleusen von außen“. Dabei werden Sicherheitslücken ausgenutzt. Gelegentlich wird auch die Abkürzung XSRF verwendet. Auf Wikipedia ist eine gute Erklärung dazu gegeben. Vor allem geht es um eine HTTP-Anfrage, die einem ahnungslosen Opfer, das an seine Webseite angemeldet ist, untergejubelt wird.

Der Angriff richtet sich gegen Betreiber von Webseiten bzw. Personen (Redakteure, Administratoren), die einen Zugang zu einer Webseite haben. Beispielsweise bieten moderne Content Management Systeme wie WordPress oder Contao einen Login-Bereich, über den sich Wartungspersonal für die Webseite anmelden kann. Die angemeldete Person kann dann je nach Berechtigungen Plugins installieren, Texte schreiben oder Einstellungen an der Webseite vornehmen.

Wenn ein Hacker diesen privilegierten Zugang ausnutzen kann, bedeutet das eine recht umfassende Kontrolle über die Webseite. Wer als Administrator handeln kann, obwohl er keiner ist, kann bösartig und oft unbemerkt einen Nutzer für sich selber anlegen. Mit diesem Superuser kann der Hacker dann die Webseite nahezu beliebig missbrauchen. Der Missbrauch reicht von negativem SEO, um Wettbewerbern zu schaden, bis hin zum Aufbau einer Bot-Armee. Mithilfe von Bots können Server ahnungsloser Opfer benutzt werden, um Massenattacken gegen andere Ziele auszuführen. Ein Beispiel sind DDoS-Attacken. DDoS bedeutet Distributed Denial of Service und hat zum Ziel, einen fremden Server durch Massenanfragen von unterschiedlichen Angriffspunkten aus lahmzulegen.

CSRF Attacken

Eine CSRF-Attacke läuft im Wesentlichen so:

1. Ein Administrator ist an seiner eigenen Webseite opferwebseite11.de angemeldet und hat somit vollen Zugriff auf alle Funktionen und Konfigurationsmöglichkeiten.
2. Ein Hacker sendet dem Administrator (Opfer) einen Link, der eine Aktion auf der Webseite des Opfers, opferwebseite11.de, ausführt.
3. Klickt das Opfer auf den Link, wird die Aktion auf seiner Webseite opferwebseite11.de aufgerufen.
4. Die Aktion kann nur erfolgreich (im Sinne des Hackers) ausgeführt werden, wenn das Opfer an seiner Webseite angemeldet ist. Eine solche Aktion kann das heimliche Anlegen eines Administrator-Nutzers für den Hacker sein, der damit sein Werk verrichten kann.

CSRF Attacken mit einem Cookie erkennen

Damit eine CSRF-Attacke blockiert werden kann, nutzen manche Content Management Systeme (CMS), wie etwa Contao, ein Cookie. Dieses Cookie heißt csrf_https-contao_csrf_token. Jedenfalls konnte ich genau dieses Cookie auf der Contao-Webseite einer Anwaltskanzlei, die auf das Datenschutzrecht spezialisiert ist, feststellen.

Mithilfe des CSRF-Token Cookies versucht Contao nun, den Angriff des Hackers zu erkennen. Contao versucht also, den untergejubelten schädlichen Link, der für den Hacker einen Superuser anlegen soll, als unberechtigten Link zu erkennen. Ein Token ist eine eindeutige Identifikation, die nicht erratbar und pro Sitzung einmalig ist.

Ein (unsichtbarer) Aufruf einer Contao-Funktion in Form eines Links wird von Contao nur als gültig angesehen, wenn ein passendes CSRF-Token vorhanden ist. Ein CSRF-Token wird an angemeldete Nutzer vergeben und mit der Sitzung des Nutzers abgeglichen. Dies wird auch als Double Submit Cookie bezeichnet. Nicht nur Contao, sondern auch andere CMS bieten Maßnahmen gegen CSRF-Angriffe. Ich bleibe hier aber bei Contao.

Damit die Lösung zum Erkennen schädlicher Links sicher funktioniert, wird bei jeder Aktion, die von der Webseite aus regulär möglich ist, das Token aus dem CSRF-Cookie über einen URL-Parameter (oder noch besser, über einen POST-Parameter) an den Server der Webseite geschickt. Reguläre Aktionen bieten etwa Kontaktformulare. Klickt der Nutzer auf den Absenden-Button, werden die Daten aus dem Formular an den Server der Webseite geschickt.

Erhält Contao nun einen Befehl, prüft das System, ob der Befehl mit dem CSRF-Cookie versehen ist. Ist das Cookie vorhanden, wird dessen Wert gegen die Nutzersitzung geprüft. Zusätzlich kann das CSRF-Token mit dem Parameter (GET oder POST) der Anfrage verglichen werden. Sind alle Prüfungen positiv, kam die Anfrage regulär von einem angemeldeten Benutzer, der die Aktion tatsächlich auch wissentlich ausgeführt hat. GET und POST bedeuten: Eine Anfrage an eine Webseite kann entweder über die GET-Methode oder über die POST-Methode erfolgen. Mit GET kann nur eine begrenzte Datenmenge verschickt werden. Jeder Klick auf einen gewöhnlichen Link führt zu einem GET-Aufruf. POST-Aufrufe hingegen sind für Hintergrundanfragen gedacht. Die Datenmenge der Parameter in POST-Anfragen kann groß sein. Derart können beispielsweise Dateien hochgeladen werden. Vielleicht kennen Sie Upload-Formulare, wo man eine Datei vom eigenen Computer aussuchen und mit einem Button-Klick auf das Zielsystem hochladen kann.

Fehlt in der Anfrage (also dem angeklickten Link) das CSRF-Cookie oder hat das Cookie einen falschen Wert, war die Anfrage unzulässig. Es muss sich hier nicht immer um einen Hackerangriff handeln. Manchmal ruft ein Entwickler zu Testzwecken händisch einen Link auf, der nur für Administratoren gedacht ist. Auch in diesem Fall würde die Anfrage scheitern. Der Entwickler hätte dann Pech gehabt und müsste seinen Test anderweitig durchführen.

Datenschutzprobleme mit CSRF-Cookies

Das TTDSG als neues deutsches Datenschutzgesetz gilt seit dem 01.12.2021. Es ging im Mai 2024 wortgleich in das TDDDG über. Das TTDSG setzt endlich die ePrivacy-Richtlinie der EU um. Zuvor musste der BGH in seinem Planet49-Urteil die Umsetzung indirekt erfolgen lassen. Wegen der damaligen Geltung des § 15 Abs. 3 TMG galt die Regelung aber wohl nicht für alle Cookie-Arten. Das ist nun explizit anders.

Der § 25 TTDSG besagt, dass Cookies nur einwilligungsfrei sind, wenn sie entweder zur Durchführung der Übertragung einer Nachricht dienen oder unbedingt erforderlich sind, damit die Webseite bereitgestellt werden kann. Die Durchführung der Übertragung ist bei einem gewöhnlichen Webseitenaufruf (ohne Anmeldung, ohne Warenkorb etc.) jedenfalls nicht von einem Cookie abhängig zu machen und somit nicht einwilligungsfrei. Ich vermute, das kann man ganz generell so sagen, ohne jede mir aktuell bekannte Ausnahme. Ich will es nicht als Behauptung stehen lassen, sondern freue mich über Rückmeldungen.

Nun zum zweiten Teil des Erlaubnistatbestands für Cookies nach TTDSG.

Sind CSRF-Cookies technisch notwendig?

Cookies sind einwilligungsfrei, sofern die unbedingt erforderlich sind. Ein Cookie ausschließlich zur Absicherung einer Webseite zu nutzen, wenn es kein anderes Mittel gibt, wäre wohl technisch notwendig.

Meine Recherche ergab, dass es Möglichkeiten gibt, CSRF Attacken zu erkennen, die nicht auf Cookies basieren. Dazu kann man beispielsweise

• Anfragenparameter für das CSRF-Token verwenden (wie oben beschrieben) und diese mit der Nutzersitzung abgleichen,
• lediglich POST-Requests zulassen bzw. kritische Aktionen über GET-Befehle generell nicht erlauben, denn ein Klick auf einen Link führt immer einen GET-Request aus,
• Sitzungs-Cookies durch das SameSite-Attribut absichern,
• den Aufrufer der Anfrage auswerten, denn bei direktem Linkaufruf ist der Aufrufer ungleich der aktuellen Webseite.

Meine bisherige Untersuchung zeigt (vorläufiges Arbeitsergebnis): Wenn Sitzungs-Cookies mit dem Wert SameSite und dem Attribut Strict verwendet werden und kritische Aktionen nur über POST-Befehle möglich sind, braucht es aus technischer Sicht keines CSRF Cookies. Dass CSRF Cookies nützlich sind, scheint unbestritten. Nützlich ist aber keine Kategorie, die hier eine Rolle spielen kann. Denn nützlich wäre es für mich beispielsweise auch, wenn ich keine Steuern zahlen muss. Erlaubt ist es dennoch nicht, die Steuern nicht zu zahlen, soweit mir bekannt ist.

Somit kann man schon annehmen, dass CSRF-Cookies technisch nicht notwendig und somit einwilligungspflichtig nach TTDSG sind. Übrigens ist es laut TTDSG völlig egal, welche Werte in einem Cookie gespeichert sind. Das ist übrigens auch der Geist der ePrivacy-Richtlinie. Es spielt keine Rolle, ob personenbezogene Daten im Cookie vorliegen oder nicht.

Falscher Gebrauch von CSRF-Cookies

Ganz eindeutig falsch ist meiner Einschätzung nach der anlasslose Gebrauch von CSRF-Cookies.

Dabei wird einfach immer, also bei jedem Webseiten-Besuch ein CSRF-Token erzeugt. Ich jedenfalls war nicht an der Anwaltswebseite angemeldet, als diese ein CSRF-Cookie in meinem Browser und somit auf meinem Endgerät setzte.

Es macht einfach keinen Sinn, ein CSRF-Token für unangemeldete Besucher einer Webseite zu vergeben. Denn das CSRF-Token ist gerade dafür da, um angemeldete Nutzer mit dem CSRF-Cookie als berechtigt anzusehen. Es ist nicht dafür da, um unangemeldete Nutzer zu legitimieren. Das wäre ja auch noch schöner und das Gegenteil einer Sicherheitsmaßnahme.

Contao schreibt es übrigens auch selber: "Providing CSRF protection for users that are not authenticated against the app does not make any sense.".

Wenn also ein CSRF-Cookie auf einer Webseite anlasslos, also für jeden Besucher, erzeugt wird, handelt es sich um einen Verstoß gegen § 25 TTDSG. Das Cookie ist technisch nicht nur unnotwendig. Es ist sogar unnötig und unsinnig.

Fazit

Das Erkennen von Attacken in Form schadhafter Links, die einem Betreuer einer Webseite untergejubelt werden, ist wichtig. Die Abwehr kann, muss aber nicht, in Form eines Cookies erfolgen.

Ein Cookie zur Abwehr von CSRF-Attacken anlasslos zu setzen, ist laut meiner Erkenntnis und der von Contao rechtswidrig. Contao als Anbieter eines CMS sagt nämlich selber, dass es Unsinn ist, ein CSRF-Token für unangemeldete Nutzer zu vergeben. Das TTDSG (neuerdings TDDDG) wiederum sagt, dass Cookies nur einwilligungsfrei sind, wenn sie notwendig sind.

Empfehlungen

Prüfen Sie Ihre Webseite und schauen Sie, ob irgend welche Cookies dort anzutreffen sind, bevor eine Einwilligung durch einen Nutzer erteilt wird (Erstbesuch der Webseite).

Sofern Sie hier Cookies finden, die nicht sitzungsbezogen sind, können Sie von einem Verbot bis nach Einwilligung ausgehen. Das gilt nicht immer, aber wohl meistens. Man müsste sich den Einzelfall ansehen.

Sofern Sie Drittpartei-Cookies finden, also solche, deren Adresse ungleich der Ihrer Webseite ist, sollten Sie bis auf Weiteres auch davon ausgehen, dass Ihre Webseite rechtswidrig ist.

Bei eigenen Cookies (Adresse gleich Ihrer Webseite) ist deren Notwendigkeit zu prüfen. Nur bei Sonderfällen wie der PHP-Sitzungsverwaltung (PHPSESSID) kann eine technische Notwendigkeit wohl unterstellt werden. Manche First-Party Cookies, wie die von Google Analytics, sind allerdings nur technisch Erstpartei-Cookies. Fachlich sind es Drittpartei-Cookies und somit meist einwilligungspflichtig. Bei Google Analytics gilt das sowieso, weil die Cookies technisch nicht notwendig sind und zudem, weil Google Daten auch zu eigenen (im Sinne des Datenschutzes schädlichen) Zwecken auswertet.

Weist Ihre Webseite (beim Erstbesuch, die der obige Cookie-Test simuliert) mehrere Cookies auf, ist erst einmal davon auszugehen, dass dies rechtswidrig ist. Wofür sollen, anlasslos, mehrere Cookies technisch notwendig sein?

Wenn Sie Dienste von Google und ähnlichen Anbietern auf Ihrer Webseite einsetzen, dann sparen Sie sich die ganze Mühe. Sie brauchen eine Einwilligung Ihrer Besucher. Vergessen Sie nicht, Ihre nicht unbedingt notwendigen Cookies auch noch mit aufzunehmen. Aber selbst dann ist Ihre Webseite wegen der Google Tools nicht rechtssicher, außer Sie können beweisen, dass Google und weitere Datenempfänger die Daten nicht zu eigenen Zwecken nutzen.

Nutzen Sie ein CMS wie WordPress, Contao, Magento, Typo3, Drupal oder Joomla, dann installieren Sie nur Plugins, die Sie wirklich benötigen. Prüfen Sie die Quelle der Plugins. Halten Sie Plugins aktuell. Nutzen Sie ein Security Plugin, das CSRF Attacken unterbinden kann. Für WordPress gibt es etwa WordFence Security oder iThemes Security. Sichern Sie Ihren Server ab. Als Stichpunkte seien hier nur Content Security Policy (CSP) und CORS genannt. Sie wissen nicht, wie das geht? Das Leben wird immer komplexer. Ich kann mein Auto auch nicht selber reparieren. Sogar für die Steuererklärung meiner Firma brauche ich einen Dienstleister.