Auswirkungen
Mit Cross-Site Request Forgery (CSRF) kann ein Angreifer den Browser eines Opfers dazu verleiten, unerwünschte Aktionen auf einer anderen Website auszuführen, auf der das Opfer derzeit authentifiziert ist. Da Browser automatisch Ambient-Anmeldeinformationen wie Cookies in Anfragen einbeziehen, kann ein Angreifer ohne Wissen des Benutzers zustandsverändernde Vorgänge fälschen – etwa das Ändern von Passwörtern, das Löschen von Daten oder das Initiieren von Transaktionen.
Grundursache
Die Hauptursache für CSRF ist das Standardverhalten des Webbrowsers, bei jeder Anforderung an diese Domäne mit einer Domäne verknüpfte Cookies zu senden, unabhängig vom Ursprung der Anforderung [S1]. Ohne spezifische Validierung, dass eine Anfrage absichtlich über die eigene Benutzeroberfläche der Anwendung ausgelöst wurde, kann der Server nicht zwischen einer legitimen und einer gefälschten Benutzeraktion unterscheiden.
Django CSRF-Schutzmechanismen
Django bietet ein integriertes Verteidigungssystem, um diese Risiken durch Middleware und Vorlagenintegration [S2] zu mindern.
Middleware-Aktivierung
django.middleware.csrf.CsrfViewMiddleware ist für den CSRF-Schutz verantwortlich und ist normalerweise standardmäßig aktiviert. [S2]. Es muss vor jeder View-Middleware positioniert werden, die davon ausgeht, dass CSRF-Angriffe bereits verarbeitet wurden [S2].
Template-Implementierung
Für alle internen POST-Formulare müssen Entwickler das {% csrf_token %}-Tag in das <form>-Element [S2] einfügen. Dadurch wird sichergestellt, dass die Anfrage ein einzigartiges, geheimes Token enthält, das der Server dann anhand der Sitzung des Benutzers validiert.
Token-Leckage-Risiken
Ein wichtiges Implementierungsdetail besteht darin, dass {% csrf_token %} niemals in Formulare eingefügt werden sollte, die auf externe URLs [S2] abzielen. Andernfalls würde das geheime CSRF-Token an Dritte weitergegeben und möglicherweise die Sitzungssicherheit des Benutzers gefährdet [S2].
Schutz auf Browserebene: SameSite-Cookies
Moderne Browser haben das SameSite-Attribut für den Set-Cookie-Header eingeführt, um eine Ebene der Tiefenverteidigung [S1] bereitzustellen.
- Streng: Das Cookie wird nur in einem Erstanbieterkontext gesendet, was bedeutet, dass die Website in der URL-Leiste mit der Domäne des Cookies [S1] übereinstimmt.
- Lax: Das Cookie wird nicht bei seitenübergreifenden Unteranfragen (z. B. Bildern oder Frames) gesendet, sondern wenn ein Benutzer zur Ursprungsseite navigiert, z. B. indem er einem Standardlink [S1] folgt.
Wie FixVibe darauf testet
FixVibe beinhaltet jetzt CSRF-Schutz als Gated Active Check. Nach der Domänenüberprüfung prüft active.csrf-protection entdeckte zustandsverändernde Formulare, prüft auf CSRF-Token-förmige Eingaben und SameSite-Cookie-Signale, versucht dann eine Übermittlung mit gefälschtem Ursprung mit geringen Auswirkungen und meldet nur, wenn der Server diese akzeptiert. Cookie-Prüfungen kennzeichnen auch schwache SameSite-Attribute, die die CSRF-Defense-in-Depth verringern.