Was ist CSRF und wie schützt man sich?
Autor: Redaktion Domeny.ForSale Veröffentlicht
Kurz gesagt: CSRF ist ein Angriff, bei dem eine fremde Website den Browser eines angemeldeten Nutzers dazu bringt, eine unerwünschte Anfrage an einen anderen Dienst zu senden. Prüft dieser Dienst nur, ob der Nutzer angemeldet ist, kann er eine Aktion ohne dessen bewusste Zustimmung ausführen. Die Grundlage des Schutzes bilden Maßnahmen auf Anwendungsseite: CSRF-Token, passende Cookie-Einstellungen und die Prüfung der Herkunft von Anfragen.
Wie CSRF funktioniert – am Beispiel einer Shop-Verwaltung
CSRF steht für Cross-Site Request Forgery, also das Fälschen websiteübergreifender Anfragen. Der Angriff nutzt aus, dass der Browser ein Sitzungscookie automatisch an Anfragen an den jeweiligen Dienst anhängen kann. Mit diesem Cookie erkennt der Server die angemeldete Person, ohne erneut nach dem Passwort zu fragen.
Stell dir vor, du verwaltest einen Onlineshop und hast dessen Administrationsbereich geöffnet. In einem zweiten Tab besuchst du eine vom Angreifer vorbereitete Website. Diese versucht, eine Anfrage an den Administrationsbereich zu senden, um die E-Mail-Adresse deines Kontos zu ändern.
Hängt der Browser das Sitzungscookie an und prüft der Administrationsbereich nicht zusätzlich die Echtheit der Anfrage, kann der Server sie als deine Entscheidung behandeln. Der Angreifer muss weder dein Passwort kennen noch das Cookie auslesen – es reicht, dass der Browser es beim Senden der Anfrage verwendet.
Das ist ein wenig so, als würde jemand einen Auftrag zur Ausführung einreichen, auf dem automatisch dein Stempel angebracht wurde. Das System erkennt den Stempel, prüft aber nicht, ob du diese konkrete Aktion tatsächlich ausführen möchtest.
Wann der Angriff gelingen kann und was ihn nicht verhindert
Ein typischer CSRF-Angriff setzt mehrere Bedingungen voraus: Der Nutzer hat eine aktive Sitzung, der Browser sendet automatisch Authentifizierungsdaten mit und die Anwendung akzeptiert eine vorhersehbare Anfrage, die den Zustand des Kontos verändert. Dabei kann es um das Ändern von Daten, das Hinzufügen eines Nutzers oder das Löschen eines Eintrags gehen. Die Folgen hängen von den verfügbaren Aktionen und den Berechtigungen des Opfers ab.
Der Angreifer muss die Antwort des Servers meist nicht lesen können. Der Browser kann der fremden Website zwar verbieten, Daten aus dem Administrationsbereich zu lesen, das Absenden bestimmter Anfragen bleibt aber dennoch möglich. Deshalb ersetzt die Same-Origin-Policy, die den Zugriff von Skripten auf fremde Ressourcen einschränkt, keinen Schutz vor CSRF.
Auch HTTPS löst dieses Problem nicht. Es verschlüsselt die Verbindung und schützt die Daten bei der Übertragung, bestätigt aber nicht, dass der Nutzer die Aktion bewusst veranlasst hat. Auch die Methode POST anstelle von GET reicht allein nicht aus: Eine fremde Website kann ein gewöhnliches POST-Formular absenden.
CSRF ist nicht dasselbe wie XSS. Bei XSS wird unerwünschter Code im Kontext einer vertrauenswürdigen Website ausgeführt. CSRF nutzt dagegen das Vertrauen des Dienstes in Anfragen aus dem Browser des Nutzers aus. Eine XSS-Schwachstelle kann allerdings den CSRF-Schutz unterlaufen, etwa indem sie das Auslesen des Tokens ermöglicht.
So schützt du eine Anwendung vor CSRF
Der sicherste Ausgangspunkt ist der integrierte Schutz des verwendeten Frameworks. Aktiviere ihn und stelle sicher, dass er alle datenändernden Aktionen abdeckt, nicht nur das Anmeldeformular.
- Prüfe das CSRF-Token. Dabei handelt es sich um einen nicht vorhersagbaren Wert, den die Anwendung in ein Formular einfügt oder zum Senden in einem entsprechenden Header bereitstellt. Der Server prüft ihn, bevor er die Aktion ausführt. In einer verbreiteten Variante ist das Token an die Sitzung gebunden; eine fremde Website sollte es weder auslesen noch erraten können. Das Token sollte nicht in die URL gelangen.
- Setze das Attribut SameSite für das Sitzungscookie. Es schränkt das Senden des Cookies in websiteübergreifenden Kontexten ein. Die Varianten Lax und Strict bieten unterschiedlich starke Einschränkungen. Prüfe deshalb, wie sich die gewählte Einstellung auf die Anmeldung und auf Integrationen auswirkt. SameSite ist eine Schutzschicht, aber kein uneingeschränkter Ersatz für ein Token.
- Prüfe die Herkunft der Anfrage. Der Header Origin und bei einem entsprechend konzipierten Prüfverfahren auch Referer helfen dabei, die Herkunft einer Anfrage festzustellen. Vergleiche den jeweiligen Wert mit genau festgelegten zulässigen Adressen, statt nur nach einem Teil des Domainnamens zu suchen.
- Ändere keine Daten über GET. Das Öffnen eines Links sollte weder ein Konto löschen noch eine Bestellung bestätigen. Datenändernde Aktionen sollten die passenden Methoden verwenden und weiterhin einer CSRF-Prüfung unterliegen.
Ergänze bei besonders sensiblen Aktionen eine erneute Authentifizierung oder eine gesonderte Bestätigung. Sitzungscookies sollten außerdem die passenden Attribute Secure und HttpOnly haben, auch wenn keines davon allein CSRF verhindert.
Braucht auch eine API Schutz?
Eine API, also eine Schnittstelle zur Kommunikation zwischen Programmen, kann ebenfalls für CSRF anfällig sein, wenn sie eine per Cookie authentifizierte Sitzung verwendet. Eine Antwort im Format JSON allein bietet keine Sicherheit.
Fügt der Client ein Zugriffstoken ausdrücklich im Header Authorization hinzu und hängt der Browser dieses nicht automatisch an, greift der typische CSRF-Mechanismus in der Regel nicht. Das bedeutet jedoch keinen Schutz vor Token-Diebstahl oder XSS. Auch CORS, ein Mechanismus zur Regelung von Zugriffen zwischen unterschiedlichen Ursprüngen, ist kein eigenständiger Schutz vor CSRF.
Was du bei deinem eigenen Dienst prüfen solltest
Beginne mit einer einzelnen Aktion, etwa dem Ändern der E-Mail-Adresse. Prüfe mit einem Testkonto in deiner eigenen Umgebung oder mit Zustimmung des Betreibers, ob eine Anfrage ohne CSRF-Token oder mit einem falschen Token abgewiesen wird und tatsächlich keine Daten verändert. Kontrolliere anschließend die Cookie-Einstellungen sowie die weiteren Wege, über die sich dieselbe Aktion ausführen lässt.
Wenn du ein fertiges System verwendest, prüfe die Funktionsweise des Schutzes anhand der offiziellen Dokumentation der eingesetzten Version und der installierten Erweiterungen. Als Nutzer kannst du fehlende Schutzmaßnahmen auf dem Server nicht beheben. Du kannst das Risiko aber verringern, indem du dich nach der Arbeit in einem sensiblen Administrationsbereich abmeldest. Als Betreiber einer Anwendung solltest du zunächst die datenändernden Aktionen durchgehen: Bei ihnen muss geprüft werden, ob die Anfrage tatsächlich von einer autorisierten Benutzeroberfläche stammt.
Siehe auch: Was bedeutet www?
Lesen Sie auch
