Was ist Cross-Site Request Forgery (CSRF)?

Cross-Site Request Forgery (CSRF oder XSRF) bringt den Browser eines angemeldeten Nutzers dazu, ungewollt eine Aktion an eine andere Website zu senden. Weil der Browser Cookies häufig automatisch mitsendet, kann die Zielanwendung den manipulierten Request für eine legitime Handlung des Opfers halten.

Wie funktioniert CSRF?

Ein Angreifer platziert beispielsweise ein präpariertes Formular, Bild oder Skript auf einer fremden Seite. Besucht das Opfer diese Seite, sendet sein Browser einen Request an die verwundbare Anwendung. Ist das Opfer dort angemeldet und wird die Session über Cookies erkannt, enthält der Request die gültige Sitzung. Die Anwendung prüft dann zwar die Identität, aber nicht, ob der Nutzer genau diese Aktion beabsichtigt hat.

Welche Voraussetzungen braucht ein Angriff?

• Es existiert eine relevante Aktion, etwa Änderung von E-Mail-Adresse, Passwort, Berechtigung oder Zahlungsempfänger.
• Die Anwendung verlässt sich auf automatisch übertragene Zugangsdaten wie Session-Cookies.
• Der Angreifer kann alle notwendigen Request-Parameter vorhersagen oder festlegen.
• Es fehlt eine wirksame Prüfung, dass der Request aus dem beabsichtigten Anwendungskontext stammt.

Bei Bearer-Tokens, die JavaScript bewusst in einen Authorization-Header einfügt, ist klassisches CSRF meist nicht direkt möglich. Werden Tokens jedoch in Cookies abgelegt oder existieren alternative cookiebasierte Endpunkte, muss das konkrete Verhalten geprüft werden.

Welche Auswirkungen sind möglich?

Die Auswirkung entspricht der missbrauchten Funktion und den Rechten des Opfers. Angreifer können Profile ändern, Bestellungen auslösen, neue API-Schlüssel erzeugen oder administrative Konfigurationen manipulieren. CSRF liest normalerweise keine Antwort der Zielseite aus. In Verbindung mit Cross-Site Scripting, CORS-Fehlern oder Informationslecks kann diese Grenze jedoch fallen.

Wie verhindert man CSRF?

Frameworkeigene CSRF-Funktionen sind meist die beste Grundlage. SameSite ist eine wichtige zusätzliche Kontrolle, sollte aber nicht ungeprüft als alleiniger Schutz verwendet werden.

Codebeispiel: CSRF-Schutz in Laravel

Verwundbar: Zustandsänderung über GET und Formular ohne Token.

// Unsichere Route
Route::get('/account/delete', [AccountController::class, 'destroy']);

<form method="POST" action="/email/change">
    <input name="email">
</form>

Sicherer Grundaufbau:

Route::delete('/account', [AccountController::class, 'destroy'])
    ->middleware('auth');

<form method="POST" action="/account">
    @csrf
    @method('DELETE')
    <button type="submit">Konto löschen</button>
</form>

Laravel prüft das Token in der Web-Middleware. Für eine endgültige Kontolöschung ist eine erneute Passwort- oder MFA-Bestätigung eine sinnvolle zusätzliche Kontrolle.

Welche Schutzfehler treten häufig auf?

Ein Token hilft nicht, wenn es optional, vorhersagbar, nicht an die Session gebunden oder über eine fremde Subdomain setzbar ist. Manche Anwendungen prüfen nur POST, akzeptieren dieselbe Aktion aber auch per GET oder anderer Methode. Eine Referer-Prüfung mit einfacher Teilzeichenkette lässt sich durch ähnlich benannte Domains umgehen. Auch Login-CSRF ist relevant: Das Opfer wird unbemerkt in ein vom Angreifer kontrolliertes Konto eingeloggt und legt dort später vertrauliche Daten ab.

Wie wird CSRF getestet?

Tester erfassen alle zustandsändernden Requests und prüfen Token, Cookie-Attribute, Methodenwechsel sowie Origin-Validierung. Anschließend wird ein minimaler Cross-Origin-Nachweis in einer getrennten Testseite erstellt. Dabei sind nicht nur Kontoänderungen, sondern auch Adminfunktionen, Uploads, OAuth-Verknüpfungen und API-Endpunkte zu berücksichtigen. Ein erfolgreicher Test verändert nur freigegebene Testdaten.