Cross-Site Request Forgery (auch bekannt als Cross-Site Reference Forgery) ist eine Form des Angriffs auf Webanwendungen. Der Hacker bringt Benutzer durch böswillige Anfragen dazu, Aufgaben auszuführen, die sie eigentlich nicht ausführen wollen. Um solche Angriffe zu verhindern, benötigt der Webserver einen Mechanismus, mit dem er feststellen kann, ob eine Anfrage von einem legitimen Benutzer über den Browser des Benutzers generiert wurde.
Ein CSRF-Token hilft dabei, indem es serverseitig einen eindeutigen, unvorhersehbaren und geheimen Wert erzeugt, der in die HTTP-Anfrage des Clients aufgenommen wird. Bei der anschließenden Anfrage prüft der Webserver den Anfrageparameter, der das Token enthält, und lehnt diejenigen ab, die das Token nicht enthalten. Dieser Ansatz wird häufig verwendet, um CSRF-Angriffe zu verhindern, da es für den Hacker fast unmöglich ist, eine vollständige, gültige HTTP-Anfrage zu konstruieren, um ein Opfer zu überfallen.
Wir haben bereits erklärt, dass Cross-Site-Scripting-Schwachstellen zu den häufigsten Formen von Angriffen gehören, bei denen schadhafter Code im Browser des Opfers ausgeführt wird. Obwohl ein CSRF-Angriff ähnlich wie ein XSS-Angriff klingt, gibt es grundlegende Unterschiede in der Art und Weise, wie sie ausgeführt werden.
In diesem Artikel wird erläutert, wie ein CSRF-Token funktioniert und welche Bedeutung es für die Anwendungssicherheit hat.
Warum ist ein gültiges CSRF-Token erforderlich?
Es wird empfohlen, CSRF-Tokens zu allen zustandsändernden Anfragen hinzuzufügen und sie im Back-End zu validieren. Da nur Anwendungsserver und Clients das Token erkennen, muss das Backend sicherstellen, dass die eingehende Anforderung ein gültiges CSRF-Token enthält, um erfolgreiche XSS- oder Cross-Site-Request-Forgery-Angriffe zu verhindern.
Das CSRF-Token ist ein geheimer Wert, der sicher verwahrt werden sollte, um während Cookie-basierter Sitzungen gültig zu bleiben. Das Token sollte in einem verborgenen Feld eines HTML-Formulars an den Client übertragen werden, das mit HTTP-POST-Anfragen übermittelt wird. Als bewährtes Verfahren wird empfohlen, die Herkunft von Anfragen anhand von Standard-Headern zu überprüfen. Zusätzliche Maßnahmen sollten auch die Herkunft von Quelle und Ziel identifizieren und vergleichen. Wenn die Ursprünge übereinstimmen, wird die Anfrage als legitim angesehen, wenn nicht, deutet dies auf eine domänenübergreifende Anfrage hin und wird verworfen.
Bedeutung von CSRF-Tokens für die Verhinderung von Angriffen
Die CSRF-Token-Werte enthalten eine erhebliche Entropie und sind unvorhersehbar, da die generierten Token einen Pseudo-Zufallszahlengenerator, ein statisches Geheimnis und einen Zeitstempel verwenden. Darüber hinaus sind die Token für jeden Benutzer unterschiedlich und werden nur für eine aktive Benutzersitzung gespeichert. Sicherheitsteams können die Einzigartigkeit des Token-Wertes verbessern, indem sie die Ausgabe des Zufallszahlengenerators mit einer benutzerspezifischen Entropie verketten und die gesamte Struktur hashen. Dadurch wird es für den Hacker wesentlich schwieriger, das CSRF-Token auf der Grundlage einer Stichprobe von Token zu erraten, die in früheren Sitzungscookies ausgegeben wurden.
CSRF-Tokens – Verwendung
In einigen Anwendungen ist es ratsam, die CSRF-Tokens in einem benutzerdefinierten Request-Header zu übertragen. Obwohl ein Token im URL-Abfrage-String platziert werden kann, gilt dieser Ansatz als unsicher, da der Abfrage-String in mehreren Datensätzen auf der Server- und Client-Seite protokolliert wird. Der Abfrage-String ist jedoch auf dem Bildschirm des Client-Browsers abrufbar und kann auch im HTTP-Referer-Header an die Anwendungen von Drittanbietern übermittelt werden.
Darüber hinaus sollte das CSRF-Token in der serverseitigen Anwendung gespeichert werden, die jede validierungspflichtige Anfrage prüft. Die serverseitige Anwendung sollte sicherstellen, dass gültige Anfragen ein Token enthalten, das dem während der aktiven Sitzung des Benutzers gespeicherten Wert entspricht. Die CSRF-Token-Validierung sollte auch für alle HTTP-Methoden, einschließlich POST, PUT und DELETE, durchgeführt werden.
Leitfaden
CSRF-Angriffe Präventionsguide
Erfahren Sie, wie Sie eine Cross-Site Request Forgery – eine der am weitesten verbreiteten Sicherheitslücken – erkennen und verhindern können.
(Der Leitfaden ist derzeit nur auf Englisch verfügbar.)
Wie implementiert man CSRF Token in Java?
Java-Anwendungen haben keinen eingebauten Schutz gegen CSRF-Angriffe. Daher beinhaltet die vorgeschlagene Implementierung von CSRF-Tokens in Java die Verwendung eines Filters und von Hilfsklassen, die die Erstellung von Tokens, die Analyse von Ressourcen und die Erstellung von Antworten ermöglichen. Eine solche Lösung ist der Generic Stateless-Filter, der das Double-Submit-Cookie-Muster implementiert, um CSRF-Schutz zu ermöglichen, und der den im Folgenden beschriebenen Arbeitsablauf durchläuft:
Der Filter wird zunächst in der Datei web.xml der Java-Anwendung definiert, wie im folgenden Codeschnipsel gezeigt:
<filter>
<filter-name>CSRFFilter</filter-name>
<filter-class>com.github.adriancitu.csrf.GenericCSRFStatelessFilter</filter-class>
<filter>
<filter-mapping>
<filter-name>CSRFFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>Der Filter enthält zwei optionale Initialisierungsvariablen:
- csrfHeadername – der Name des Headers, der das Token enthält, und
- csrfCookieName – die Identität des Cookies, in dem das CSRF-Token gespeichert ist.
Für jede HTTP-Anfrage stellt der Filter eine Instanz der Klasse ExecutionContext bereit. Dies ist ein Java-Legacy-Objekt, das die CSRF-Cookies, die HTTP-Anfrage und die Antwort enthält. Die Klasse enthält auch Implementierungen von Hilfsklassen (ResourceCheckerHook, ResponseBuilderHook und TokenBuilderHook).
Der Filter prüft zunächst den Schutzstatus der angeforderten HTTP-Ressource. Es gibt drei Optionen:
- MUST_NOT_BE_PROTECTED
- MUST_BE_PROTECTED_BUT_NO_COOKIE_ATTACHED
- MUST_BE_PROTECTED_AND_COOKIE_ATTACHED
Für Ressourcen mit dem Status MUST_NOT_BE_PROTECTED und MUST_BE_PROTECTED_BUT_NO_COOKIE_ATTACHED erzeugt der Filter zunächst ein Cookie mit einem CSRF-Token, das von der Klasse TokenBuilderHook bereitgestellt wird. Bei Ressourcen mit der Kennzeichnung MUST_BE_PROTECTED_AND_COOKIE_ATTACHED prüft der Filter den CSRF-Schutzstatus der Ressource mit ResourceCheckerHook und gibt dann eine Antwort an den Client mit der Klasse ResponseBuilderHook zurück.
Kurzer Hinweis: Der obige Code ist ein Referenzbeispiel und erfordert, dass Entwicklerteams weitere CSRF-Schutzmechanismen in den Quellcode einbauen.
Wie implementiert man CSRF Token in PHP?
PHP ist bei Content-Management-Systemen sehr beliebt, da es Entwicklern ermöglicht, dynamische Websites mit interaktiven Funktionen zu erstellen. Daher ist es wichtig, einen Anti-CSRF-Schutz in PHP-Kontakt-/Benutzereingabeformulare zu implementieren, damit deren Post-Handler eingehende Anfragen gegen CSRF-Angriffe validieren können. Ein typischer Arbeitsablauf für die Implementierung des CSRF-Schutzes in PHP-Kontaktformularen sieht folgendermaßen aus:
Zunächst erstellen Sie auf der Landing Page ein Skript für die Fußzeile des Formulars, das SecurityService aufruft – die PHP-Klasse erzeugt das Token und initiiert die PHP-Sitzung. SecurityService schreibt das Token, das zur Validierung der Anfragen verwendet wird, und lädt das Token in ein verstecktes Feld. Eine typische SecurityService.php-Konfiguration würde so aussehen:
public function getCSRFToken()
{
if (empty($this->session[$this->sessionTokenLabel])) {
$this->session[$this->sessionTokenLabel] = bin2hex(openssl_random_pseudo_bytes(32));
}
if ($this->hmac_ip !== false) {
$token = $this->hMacWithIp($this->session[$this->sessionTokenLabel]);
} else {
$token = $this->session[$this->sessionTokenLabel];
}
return $token;
}Das PHP-Kontaktformular wird dann gerendert, um die Details wie Betreff, Nachricht, Name und E-Mail einzugeben. Das Formular sollte auch das generierte Token in einem versteckten Feld csrf-token enthalten. Sobald der Benutzer auf die Schaltfläche „Submit“ klickt, führt die Anwendung eine JQuery-Formularvalidierung durch, nach der die Parameter an PHP gesendet werden.
Sobald das Kontaktformular abgeschickt wurde, führt die Formularaktion ein Skript aus, das das eingebettete Token mit dem in der Sitzung gespeicherten vergleicht. Wenn die Token übereinstimmen, wird die Anwendung die Anfrage des Benutzers bearbeiten. Ist dies nicht der Fall, quittiert PHP den Vorgang mit einer Fehlermeldung.
Wie implementiert man CSRF-Token in Django?
Django bietet von Haus aus ein CSRF-Middleware-Tag, mit dem sich der Schutz vor CSRF-Angriffen leicht aktivieren lässt. Der Beispiel-Workflow zeigt, wie CSRF-Schutz innerhalb des Frameworks implementiert werden kann:
In Django ist die CSRF-Middleware standardmäßig aktiviert. Wenn der Entwickler diese Einstellung überschreibt, sollte er django.middleware.csrf.CsrfViewMiddleware vor jedem View deklarieren, um die CSRF-Token-Validierung zu aktivieren.
Für bestimmte Views können Entwickler den csrf-protect Dekorator aufrufen. Der Dekorator wird für Ansichten verwendet, die das CSRF-Token in die Ausgabe einfügen. Die Konfiguration des Dekorators würde so ähnlich aussehen:
from django.shortcuts import render
from django.views.decorators.csrf import csrf_protect
@csrf_protect
def my_view(request):
c = {}
# ...
return render(request, "a_template.html", c)
Entwickler können den Schutz für Vorlagen aktivieren, die das POST-Formular verwenden, indem sie das csrf_token-Tag in das <form>-Element einfügen. Dies gilt nur für Formulare mit einer internen URL und nicht für POST-Formulare, die auf externe URLs abzielen. Für externe URLs kann das CSRF-Token-Tag durch die Verwendung von aufgerufen werden:
<form method="post">{% csrf_token %}Außerdem wird empfohlen, RequestContext zu verwenden, um die Antwort in den entsprechenden Django-Ansichten darzustellen.
Wie man CSRF Token in Javascript implementiert
Alle Javascript-Frameworks verfügen über Standardoptionen, um CSRF-Schutz zu erreichen. Express.js enthält zum Beispiel eine Middleware namens csurf, die bei der Erstellung und Validierung von Token hilft. Um den CSRF-Schutz mit csurf zu aktivieren, gehen Sie wie folgt vor:
Fügen Sie in der Datei index.js den folgenden Code ein:
app.get('/', csrfProtection, (req, res) => {
res.render('index', { csrfToken: req.csrfToken() });Anschließend fügen Sie eine Datei index.ejs in den Ordner views ein, indem Sie eine Konfiguration ähnlich wie folgt verwenden:
<input type='hidden' name='_csrf' value='<%= csrfToken %>'>
<label for='name'> Name:</label>
<input type='text' name='name'>
<button type='submit'> Update </button>
</form>Die /-Route in der Hauptkonfigurationsdatei gibt die csrfToken-Variable in der index.ejs-Vorlage wieder und interpoliert das Token in ein verstecktes Feld. Die Anfrage wird zur /profile-Route hinzugefügt, wenn der Benutzer das Formular absendet, das eine CSRF-Token-Validierung bietet. Wenn dieses CSRF-Token fehlt, gibt die Anwendung einen Fehler mit einem ungültigen CSRF-Token zurück.
Wie man ein ungültiges CSRF-Token behebt
Der CSRF-Angriff führt zum unauthentifizierten Zugriff auf Benutzersitzungen und hat schwerwiegende Folgen. Um diese Art von Angriffen zu verhindern, muss sichergestellt werden, dass Benutzer Anfragen mit gültigen Token stellen. Einige gängige Ansätze zur Behebung und Verhinderung ungültiger Token sind:
Verwendung benutzerdefinierter Anfrage-Header
Das Hinzufügen von CSRF-Tokens in einer angreifbaren Anwendung ist mit administrativen Aufgaben verbunden, die zu Änderungen an der Benutzeroberfläche führen und oft komplex und problematisch sind. Als Alternative können Sicherheitsteams benutzerdefinierte Anforderungs-Header erstellen, die den CSRF-Schutz mithilfe der Same-Origin-Richtlinie stärken. Die Sicherheitsrichtlinie lehnt herkunftsübergreifende Anfragen ab und setzt gleichzeitig die Einschränkung durch, dass benutzerdefinierte Header nur in Javascript erstellt und nur innerhalb ihres Ursprungs verwendet werden können.
Nutzung eingebauter und vorhandener CSRF-Abwehrimplementierungen
Die meisten Entwicklungsframeworks enthalten in die Sicherheitssuite integrierte Synchronisierungs-Token-Verteidigungsmechanismen, die den gesamten Anwendungsstapel schützen sollen. Wenn das Framework im Tech-Stack eines Teams Optionen für einen standardmäßigen CSRF-Schutz bietet, wird empfohlen, diese zu nutzen, bevor man versucht, ein benutzerdefiniertes System zu entwickeln. In den meisten Fällen bieten die eingebauten Konfigurationen einen angemessenen Schutz, der durch die Implementierung von Konfigurationen, die auf dem Anwendungsfall des Unternehmens basieren, weiter verstärkt werden kann.
Einsatz einer UI-basierten CSRF-Abwehr
Mehrere Mechanismen analysieren eine Anfragemethode, um nicht autorisierte Aktionen durch CSRF zu verhindern und legitime Anfragen von solchen zu trennen, die unerwünschte Aktionen beabsichtigen. Dazu gehören CAPTCHA, Authentifizierungsmechanismen mit erneuter Authentifizierung und einmalige Token. Diese bieten zwar einen starken Schutz für die Eingabevalidierung, verändern aber das Benutzererlebnis und sollten nur für wichtige Sicherheitsmaßnahmen verwendet werden.
