Cross-Site Request Forgery (XSRF), auch als Session Riding bekannt, ist ein weit verbreitetes Sicherheitsproblem, das Webanwendungen betrifft, einschließlich Angular-Anwendungen. XSRF-Attacken zielen darauf ab, die Identität und Berechtigungen eines unwissenden Nutzers zu missbrauchen, um bösartige Aktivitäten durchzuführen. Angular bietet jedoch eingebaute Mechanismen zur Bekämpfung solcher Angriffe. In diesem Artikel werden wir XSRF in Angular eingehender betrachten und darüber diskutieren, wie wir uns davor schützen können.
Ablauf einer XSRF Attacke
Bei einer XSRF-Attacke sendet der Angreifer eine betrügerische Anfrage von einer Seite, der das Opfer vertraut. Der Angreifer nutzt die Tatsache aus, dass Cookies beim Senden von Anfragen an eine Site automatisch inkludiert werden, auch wenn die Anfrage von einer dritten Site ausgelöst wird. Wenn das Opfer zu diesem Zeitpunkt bei der betroffenen Anwendung angemeldet ist, wird die Anfrage als legitime Anfrage des Opfers angesehen und ausgeführt. Dies könnten zum Beispiel ein Request an einen Bank Server sein, der eine Überweisung auslöst.
Implementierung des XSRF-Schutzes in Angular
Hier sind die Schritte, die Sie befolgen sollten, um XSRF-Schutz in Ihrer Angular-Anwendung zu implementieren:
- HttpClientModule importieren: Sie müssen das HttpClientModule importieren in der src/app/app.module.ts und für die Requests verwenden.
import {HttpClientModule} from "@angular/common/http";
...
imports: [
HttpClientModule,
]
- XSRF-Token setzen: Der Server sollte das XSRF-Token in einem Cookie setzen. Das Standardcookie, das Angular sucht, heißt
XSRF-TOKEN. - XSRF-Tokens in HTTP-Anfragen verwenden: Der HttpXsrfInterceptor fügt automatisch das
X-XSRF-TOKEN-Header mit dem XSRF-Token aus dem Cookie hinzu. Wenn der Server das Header erhält, vergleicht er das Token mit dem, was er hat. Wenn es nicht übereinstimmt, wird die Anfrage abgelehnt.
Es ist wichtig zu beachten, dass XSRF-Schutz in Angular darauf beruht, dass der Server korrekt konfiguriert ist, um das XSRF-Token in einem Cookie zu setzen und dieses bei eingehenden Anfragen zu überprüfen.
Wenn der Backend Server einen anderen Cookie oder Header für den XRSF Token verwendet, kann dies in Angular folgender Maßen konfiguriert werden:
imports: [
HttpClientModule,
HttpClientXsrfModule.withOptions({
cookieName: 'My-Xsrf-Cookie',
headerName: 'My-Xsrf-Header',
}),
],
Angular fügt das XSRF-Token standardmäßig nur zu den PUT, POST, DELETE und PATCH HTTP-Anfragen hinzu, da diese Operationen im Allgemeinen den Zustand des Servers ändern können und daher als potenziell unsicher angesehen werden.
GET– und HEAD-Anfragen dagegen sind idempotent und lesen nur Daten, sie führen keine Aktionen aus, die den Zustand des Servers verändern, daher fügt Angular diesen Anfragen standardmäßig kein XSRF-Token hinzu. Das ist eine gängige Praxis, um die Menge der übertragenen Daten zu reduzieren und da XSRF-Angriffe typischerweise auf Zustandsänderungen abzielen.
Beispiel Implementierung im Backend mit PHP
Hier ist ein einfaches Beispiel in PHP für das Setzen und Überprüfen eines XSRF-Tokens.
Token setzen
Wenn ein Benutzer eine Sitzung startet, erstellen und speichert man ein XSRF-Token in einem Cookie und überträgt ihn damit an das Frontend.
<?php
session_start();
if (empty($_SESSION['token'])) {
$token = bin2hex(random_bytes(32));
$_SESSION['token'] = $token;
setcookie("XSRF-TOKEN", $token, time() + 3600, "/");
}
Token überprüfen
Bei eingehenden POST, PUT, DELETE oder PATCH Anfragen vom Frontend, überprüft man das XSRF-Token im Backend.
<?php
session_start();
$method = $_SERVER['REQUEST_METHOD'];
$serverToken = $_SESSION['token'];
$clientToken = $_SERVER['HTTP_X_XSRF_TOKEN'];
if (in_array($method, array('POST', 'PUT', 'DELETE', 'PATCH'))) {
if (!isset($clientToken)) {
die("Unauthorized request (missing X-XSRF-TOKEN header)");
} elseif (!hash_equals($serverToken, $clientToken)) {
die("Unauthorized request (X-XSRF-TOKEN does not match)");
}
}