Was ist eine Cross-Site-Request-Forgery (CSRF)?
Die Angriffsform der Cross-Site-Request-Forgery (CSRF, XSRF oder Session Riding) zwingt Anwender zum unwissentlichen Ausführen ungewollter Aktionen in einer Webanwendung, in der sie angemeldet sind. Die Angreifer zielen auf Zustands- und Statusveränderungen ab. Antworten auf die Anfragen sehen die Angreifer nicht, auf direktem Weg lassen sich mit dieser Methode keine persönlichen Daten entwenden. Vielmehr zielen CSRF-Attacken darauf ab, dass potenzielle Opfer bestimmte Aktionen in einer Anwendung ungewollt ausführen und beispielsweise monetäre Transaktionen durchführen oder die E-Mail-Adresse ändern.
Wie nutzen Hacker Cross-Site-Request Forgery für Angriffe?
Angreifer stellen für CSRF-Angriffe gültige HTTP-Requests nach und übermitteln diese an das potenzielle Opfer. Beim Request kann es sich um eine URL zur Webanwendung handeln, die der Datenbank einen neuen Benutzer hinzufügt, zum Beispiel: www.ziel-domain.de/addUser?username=admin1.
Diese Form von Cyberattacke verbreitet der Cyberkriminelle zum Beispiel über einen präparierten Link zur Webanwendung in Foren oder Gästebüchern. Wenn ein Seitenbesucher auf den Link klickt, wird der damit verbundene Befehl an die Webanwendung gesendet und im Benutzer-Kontext ausgeführt. Bei einem bereits angemeldeten Anwender erfolgt die Ausführung des verborgenen Befehls mit den Zugriffsrechten des Benutzers. Für gewöhnlich befinden sich solche Links mit versteckten ungewollten Aktionen in HTML Image-Tags.
Wie lässt sich Cross-Site Request Forgery verhindern?
Webanwendungen müssen Sicherheitsmechanismen unterstützen, die unbeabsichtigt weitergeleitete Befehle von beabsichtigten Seitenaufrufen des Benutzers unterscheiden können. Dafür eignet sich die Verwendung eines zusätzlichen Tokens.
Bei Webanwendungen mit besonders hohen Schutzanforderungen kann es empfehlenswert sein, das Token so zu erzeugen, dass ein neues Token für jeden Aufruf an den Client gesendet wird. Im folgenden Request muss dieses dann verwendet werden. Vor der Ausführung kritischer Aktionen sollte sich der Anwender immer erneut authentisieren müssen, damit bestimmte Aktionen nur nach Interaktion mit dem Benutzer ausgeführt werden.
Als weiteres Sicherheitsmerkmal eignet sich das Referrer-Feld im HTTP-Request. Dabei handelt es sich um die Website-URL, von der der Benutzer zur jetzigen Seite gekommen ist. Der Request ist dann in vielen Fällen nur gültig, wenn im Referrer-Feld die URL der eigenen Webanwendung steht. Das Programm kann dann sicher sein, dass der Request vom Klick auf einen Link in der Anwendung stammt. Allerdings eignet sich die Maßnahme nicht für alle Arten von Webanwendungen, teilweise muss zum Beispiel aus Gründen des Datenschutzes das Referrer-Feld gefiltert oder deaktiviert werden.
Letztlich müssen Administratoren jede Seite und jedes wichtige Formular ihrer Website gegen Cross-Site-Request-Forgery schützen. Als Regel gilt: Verändert ein Formular Einträge in der Datenbank oder führt kritische Aktionen aus, sollte dieses speziell vor den Gefahren durch CSRF geschützt werden. Webseiten sollten sensible Aktionen nicht bei GET-Abfragen durchführen und stattdessen Formulare nutzen, die Daten per POST übertragen.
Die Einführung eines geheimen Tokens erhöht den Schutz, der Angreifer kann dieses nur schwer erraten. Die geheime Information kennt nur der Server und Browser des Benutzers. Beim Seitenaufruf wird das Token in der URL oder als Hidden-Field im Formular übertragen. In der Folge prüft die Webanwendung jeden Client-Request auf die Übereinstimmung des übertragenen Tokens mit dem hinterlegten Wert zur Sitzung. Die Nachstellung eines gültigen HTTP-Requests ist Angreifern ohne die Token-Kenntnis nicht möglich.
Hinweis: Zwar handelt es sich bei einer Session ID um ein vertrauliches Datum, als Token eignet sich diese jedoch nicht, besser ist die Erzeugung eines separaten Tokens.
Anwender können sich ebenfalls zusätzlich schützen. Die Verwendung der Erweiterung NoScript im Browser blockiert XSS und andere Cross-Site Attacken. Der Browser lädt Bilder normalerweise automatisch, die Deaktivierung der Funktion schützt zusätzlich. Um auf Nummer sicher zu gehen, können sich Anwender immer aus allen Anwendungen ausloggen und keine Cookies speichern. Das Ändern der Benutzerdaten über einen fälschlicherweise angeklickten Link ist dann nicht möglich, ohne dass der Anwender sich erst wieder bei der Anwendung anmeldet.
Beispiel für CSRF-Schutz mit Token.
Zur Sicherheit ist in jedem wichtigen Formular eine geheime Information in Form eines Tokens eingebettet. Sinnvoll ist es beispielsweise nach dem Log-in einen zufälligen Wert zu generieren und diesen in der Session abzuspeichern.
~
<?php
//Nach dem Einloggen
$_SESSION['secret_token'] = uniqid('',true);
~
Der generierte Token wird jedem Formular und jedem wichtigen Link übergeben. Um ein Formular mit dem Token zu schützen, wird dieses um ein hidden-Field erweitert und der Wert dort gespeichert. Das verarbeitende Script überprüft die Werte und führt die Aktion nur aus, wenn der Wert mit dem in der Session gespeicherten Wert übereinstimmt. Bei gewissenhafter Umsetzung des CSRF-Schutzes mit geheimen Token ist die Webanwendung zuverlässig gegen Cross-Site-Request-Forgery (CSRF) geschützt.