- Einführung
- Verhindern von CSRF-Anfragen
- Ausschluss von URIs
- X-CSRF-Token
- X-XSRF-Token
Einführung
Cross-Site-Request-Forgeries sind eine Art von bösartigem Exploit, bei dem nicht autorisierte Befehle im Namen eines authentifizierten Benutzers ausgeführt werden. Glücklicherweise macht es Laravel einfach, Ihre Anwendung vor Cross-Site-Request-Forgery (CSRF)-Angriffen zu schützen.
Eine Erklärung der Schwachstelle
Für den Fall, dass Sie mit Cross-Site-Request-Forgeries nicht vertraut sind, lassen Sie uns ein Beispiel besprechen, wie diese Schwachstelle ausgenutzt werden kann. Stellen Sie sich vor, Ihre Anwendung verfügt über eine /user/email-Route, die eine POST-Anfrage zum Ändern der E-Mail-Adresse des authentifizierten Benutzers annimmt. Höchstwahrscheinlich erwartet diese Route ein email-Eingabefeld, das die E-Mail-Adresse enthält, die der Benutzer nun verwenden möchte.
Ohne CSRF-Schutz könnte eine böswillige Website ein HTML-Formular erstellen, das auf die /user/email-Route Ihrer Anwendung verweist und die eigene E-Mail-Adresse des böswilligen Benutzers übermittelt:
<form action="https://your-application.com/user/email" method="POST"> <input type="email" value=""></form><script> document.forms.submit();</script>Wenn die böswillige Website das Formular automatisch übermittelt, wenn die Seite geladen wird, muss der böswillige Benutzer nur einen ahnungslosen Benutzer Ihrer Anwendung dazu verleiten, seine Website zu besuchen, und seine E-Mail-Adresse wird in Ihrer Anwendung geändert.
Um diese Schwachstelle zu verhindern, müssen wir jede eingehende POST-, PUT-, PATCH– oder DELETE-Anfrage auf einen geheimen Sitzungswert überprüfen, auf den die böswillige Anwendung nicht zugreifen kann.
Verhindern von CSRF-Anfragen
Laravel generiert automatisch ein CSRF-„Token“ für jede von der Anwendung verwaltete aktive Benutzersitzung. Dieses Token wird verwendet, um zu überprüfen, ob der authentifizierte Benutzer tatsächlich die Person ist, die die Anfragen an die Anwendung stellt. Da dieses Token in der Sitzung des Benutzers gespeichert wird und sich jedes Mal ändert, wenn die Sitzung neu generiert wird, kann eine böswillige Anwendung nicht darauf zugreifen.
Das CSRF-Token der aktuellen Sitzung kann über die Sitzung der Anfrage oder über die csrf_token-Helper-Funktion abgerufen werden:
use Illuminate\Http\Request;Route::get('/token', function (Request $request) { $token = $request->session()->token(); $token = csrf_token(); // ...});Immer wenn Sie ein HTML-Formular in Ihrer Anwendung definieren, sollten Sie ein verstecktes CSRF _token-Feld in das Formular einfügen, damit die CSRF-Schutz-Middleware die Anfrage validieren kann. Der Einfachheit halber können Sie die @csrf Blade-Direktive verwenden, um das versteckte Token-Eingabefeld zu generieren:
<form method="POST" action="/profile"> @csrf <!-- Equivalent to... --> <input type="hidden" name="_token" value="{{ csrf_token() }}" /></form>Die App\Http\Middleware\VerifyCsrfToken-Middleware, die standardmäßig in der web-Middleware-Gruppe enthalten ist, prüft automatisch, ob das Token in der Anfrageeingabe mit dem in der Sitzung gespeicherten Token übereinstimmt. Wenn diese beiden Token übereinstimmen, wissen wir, dass der authentifizierte Benutzer derjenige ist, der die Anfrage initiiert.
CSRF Token & SPAs
Wenn Sie eine SPA erstellen, die Laravel als API-Backend verwendet, sollten Sie die Laravel Sanctum-Dokumentation für Informationen zur Authentifizierung mit Ihrer API und zum Schutz vor CSRF-Schwachstellen konsultieren.
URIs vom CSRF-Schutz ausschließen
Manchmal möchten Sie vielleicht eine Reihe von URIs vom CSRF-Schutz ausschließen. Wenn Sie zum Beispiel Stripe zur Zahlungsabwicklung verwenden und deren Webhook-System nutzen, müssen Sie Ihre Stripe-Webhook-Handler-Route vom CSRF-Schutz ausschließen, da Stripe nicht weiß, welches CSRF-Token an Ihre Routen gesendet werden soll.
Typischerweise sollten Sie diese Art von Routen außerhalb der web-Middleware-Gruppe platzieren, die App\Providers\RouteServiceProvider auf alle Routen in der routes/web.php-Datei anwendet. Sie können die Routen jedoch auch ausschließen, indem Sie ihre URIs zur $except-Eigenschaft der VerifyCsrfToken-Middleware hinzufügen:
<?phpnamespace App\Http\Middleware;use Illuminate\Foundation\Http\Middleware\VerifyCsrfToken as Middleware;class VerifyCsrfToken extends Middleware{ /** * The URIs that should be excluded from CSRF verification. * * @var array */ protected $except = ;}{tip} Der Einfachheit halber wird die CSRF-Middleware automatisch für alle Routen deaktiviert, wenn Tests ausgeführt werden.
X-CSRF-TOKEN
Zusätzlich zur Überprüfung des CSRF-Tokens als POST-Parameter überprüft die App\Http\Middleware\VerifyCsrfToken-Middleware auch den X-CSRF-TOKEN-Request-Header. Sie könnten das Token zum Beispiel in einem HTML meta-Tag speichern:
<meta name="csrf-token" content="{{ csrf_token() }}">Dann können Sie eine Bibliothek wie jQuery anweisen, das Token automatisch zu allen Anfrage-Headern hinzuzufügen. Dies bietet einen einfachen, bequemen CSRF-Schutz für Ihre AJAX-basierten Anwendungen, die Legacy-JavaScript-Technologie verwenden:
$.ajaxSetup({ headers: { 'X-CSRF-TOKEN': $('meta').attr('content') }});X-XSRF-TOKEN
Laravel speichert das aktuelle CSRF-Token in einem verschlüsselten XSRF-TOKENCookie, das in jeder vom Framework erzeugten Antwort enthalten ist. Sie können den Cookie-Wert verwenden, um den X-XSRF-TOKEN-Anforderungsheader zu setzen.
Dieser Cookie wird in erster Linie aus Bequemlichkeit für Entwickler gesendet, da einige JavaScript-Frameworks und -Bibliotheken, wie Angular und Axios, seinen Wert automatisch in den X-XSRF-TOKEN-Header bei Anfragen gleichen Ursprungs setzen.