CSRF-Angriff: So funktionieren Cross-Site Request Forgeries und wie Sie sich schützen

CSRF-Angriff bezeichnet eine Methode, bei der der Browser eines angemeldeten Nutzers dazu gebracht wird, eine Aktion auf einer Website auszuführen, ohne dass der Nutzer dies bewusst veranlasst. Angreifer müssen dazu weder das Passwort kennen, noch die Sitzung übernehmen oder direkten Zugang zum Account erhalten - es genügt, dass der Browser den Nutzer bereits als eingeloggt betrachtet.

Was ist ein CSRF-Angriff und warum ist er möglich?

CSRF einfach erklärt

Ein CSRF-Angriff (Cross-Site Request Forgery) nutzt die Situation aus, dass ein Nutzer auf einer Website angemeldet ist und der Browser die Session-Daten speichert. Besucht der Nutzer beispielsweise einen Online-Shop, ein Unternehmensportal oder einen anderen Dienst und bleibt eingeloggt, bestätigt der Browser weiterhin automatisch alle Anfragen an diese Seite.

Öffnet der Nutzer in dieser Zeit eine speziell präparierte Seite, klickt auf einen schädlichen Link oder lädt ein eingebettetes Element von einer fremden Website, kann der Browser eine Anfrage an den Dienst senden, bei dem der Nutzer bereits angemeldet ist - häufig geschieht dies im Hintergrund und bleibt für den Nutzer unsichtbar.

Die Gefahr entsteht, wenn der Server nur das Vorhandensein einer aktiven Session prüft, aber nicht verifiziert, ob die Anfrage tatsächlich vom Nutzer über das Interface der Website ausgelöst wurde.

• Der Nutzer loggt sich ein und erhält eine aktive Session.
• Er besucht eine fremde Seite, die eine Anfrage an den Zielservice auslöst.
• Der Browser sendet dabei automatisch die Session-Cookies mit.
• Der Server interpretiert die Anfrage als legitime Aktion des Nutzers.

Was bedeutet Cross-Site Request Forgery?

Die vollständige Bezeichnung CSRF steht für Cross-Site Request Forgery - auf Deutsch "Fälschung von bereichsübergreifenden Anfragen". Die Attacke zeichnet sich dadurch aus, dass eine Anfrage auf einer Website erzeugt, aber im Namen eines bereits angemeldeten Nutzers an eine andere Seite gesendet wird.

Hierbei ist es wichtig, zwischen dem eigentlichen Angriff und einer CSRF-Schwachstelle zu unterscheiden. Ein CSRF-Angriff ist der Versuch, den Browser zu einer ungewollten Aktion zu bewegen. Eine CSRF-Schwachstelle ist ein Fehler in der Logik der Webanwendung, der dazu führt, dass der Server eine solche Anfrage ohne zusätzliche Überprüfung akzeptiert.

Der Browser verhält sich dabei technisch korrekt: Er sendet Cookies und andere Domain-bezogene Daten entsprechend der Sicherheitseinstellungen. Das Problem liegt beim Webanwendung, wenn diese das Vorhandensein einer gültigen Session als ausreichenden Beweis für die Nutzerabsicht betrachtet.

Ein CSRF-Angriff erfordert daher weder Passwortdiebstahl noch Accountübernahme. Der Angreifer nutzt die bereits bestehende Autorisierung des Opfers aus, um den Browser zu erlaubten Aktionen im falschen Moment zu bewegen.

Wie funktioniert ein CSRF-Angriff: Vom Schadcode bis zur Nutzeraktion

Warum sendet der Browser automatisch Cookies?

Nach dem Login legt die Website eine Session an und verbindet diese über ein Cookie mit dem Browser. Bei weiteren Anfragen an die gleiche Domain werden die Cookies automatisch angehängt - so muss der Nutzer nicht jedes Mal Benutzername und Passwort eingeben.

Genau dieses Verhalten wird beim CSRF-Angriff ausgenutzt: Eine fremde Seite kann versuchen, eine Anfrage an eine Website zu initiieren, bei der der Nutzer bereits angemeldet ist. Wenn der Browser die Session-Cookies mitsendet und der Server die Anfrage akzeptiert, wird sie als legitime Nutzeraktion gewertet.

Das Problem: Das Vorhandensein des richtigen Cookies bestätigt nur die Session, nicht aber, dass der Nutzer die gewünschte Aktion tatsächlich ausführen wollte. Fehlen zusätzliche Prüfungen, kann der Angreifer diese Lücke zwischen Autorisierung und Nutzerabsicht nutzen.

Beispiel für eine CSRF-Attacke

Stellen Sie sich einen Dienst vor, bei dem ein angemeldeter Nutzer seine Account-Einstellungen ändern kann. Akzeptiert der Server Änderungsanfragen nur anhand einer aktiven Session, kann eine fremde Seite theoretisch versuchen, eine identische Anfrage zu senden.

Der Nutzer öffnet lediglich eine fremde Website, während der Browser im Hintergrund mit dem Zielservice kommuniziert. Für den Server sieht es so aus, als hätte der Nutzer selbst die Aktion ausgelöst.

Oft erhält der Angreifer dabei keinen Zugriff auf die Antwort des Servers oder die Account-Inhalte. Das Ziel ist meist nicht das Auslesen fremder Daten, sondern das Ausführen von Aktionen im Namen des Opfers.

Welche Aktionen sind besonders gefährlich?

• Änderung von Kontakt- oder Sicherheitsdaten
• Anpassung von Profileinstellungen
• Operationen in Admin-Panels

Das Risiko steigt, wenn solche Aktionen keine zusätzliche Bestätigung erfordern. Je mehr Rechte der Nutzer besitzt, desto gravierender sind die Folgen: Ein CSRF-Angriff auf einen Admin-Account kann erheblichen Schaden anrichten.

Daher sollten sensible Aktionen nicht ausschließlich an die aktive Session gekoppelt sein. Der Server benötigt ein weiteres Signal, dass die Anfrage tatsächlich über das vertrauenswürdige Interface und vom Nutzer selbst kommt.

CSRF-Token: Wie unterscheidet eine Website echte von gefälschten Anfragen?

Was ist ein CSRF-Token?

Ein CSRF-Token ist ein zusätzlicher Wert, den der Server bei sensiblen Anfragen erwartet. Er wird individuell pro Nutzer, Session oder Formular generiert und in die Seite eingebettet, von der die Aktion ausgeht.

Sendet der Nutzer ein Formular über das reguläre Interface, schickt der Browser den Token an den Server zurück. Dieser vergleicht den Wert mit dem erwarteten und führt die Aktion nur bei Übereinstimmung aus.

Somit reicht eine gültige Session nicht mehr aus - fehlt der korrekte CSRF-Token, lehnt der Server die Anfrage ab, selbst wenn die Session-Cookies stimmen.

Warum kann der Angreifer keinen gültigen Token mitsenden?

Eine fremde Seite hat keinen Zugang zum Seiteninhalt eines anderen Domains. Sie kann zwar Anfragen initiieren, aber in der Regel nicht den CSRF-Token aus dem Formular des Zielservices auslesen und in die gefälschte Anfrage einbauen.

Hier zeigt sich der Unterschied zu Cookies: Während Session-Cookies oft automatisch vom Browser gesendet werden, muss ein CSRF-Token explizit vom Webanwendung in die Anfrage eingebunden werden.

Ist der Token-Wert nicht vorhersagbar und prüft der Server ihn konsequent, ist eine Fälschung deutlich erschwert. Allein die Anmeldung des Nutzers reicht dann nicht mehr aus.

Weitere Schutzmechanismen gegen CSRF

• SameSite-Attribut für Cookies: Begrenzung der Cookie-Übertragung bei bereichsübergreifenden Anfragen.
• Überprüfung der Header Origin und Referer: Zusätzliche Kontrolle über die Herkunft der Anfrage.
• Erneute Identitätsprüfung bei sensiblen Aktionen: Passwortabfrage, Einmal-Code oder gesonderte Bestätigung.

So kann selbst eine aktive Session und ein Versuch der Fälschung nicht direkt zu kritischen Änderungen führen.

CSRF und XSS: Die Unterschiede

CSRF nutzt das Vertrauen der Website in den Browser

Beim CSRF-Angriff nutzt der Angreifer die bestehende Autorisierung des Nutzers. Der Browser sendet eine Anfrage samt Session-Cookies, und der Server akzeptiert sie als legitime Nutzeraktion.

Das Besondere: Der schädliche Code muss nicht auf der Zielseite selbst ausgeführt werden. Die Attacke startet auf einer fremden Seite und zwingt den Browser, sich gegenüber dem echten Dienst zu authentifizieren.

XSS nutzt das Vertrauen des Nutzers in die Website

XSS (Cross-Site Scripting) funktioniert anders: Hier kann ein Angreifer bösartigen JavaScript-Code direkt auf der Zielseite einschleusen und ausführen lassen.

Läuft ein solcher Skript, erhält er Zugriff auf die Rechte, die der Browser der Seite gewährt. Je nach Schwachstelle kann das zur Manipulation von Inhalten, zum Abfangen von Nutzereingaben oder zum Auslösen eigener Anfragen führen.

Beim CSRF erhält der Angreifer normalerweise keinen Zugriff auf den Seiteninhalt; sein Ziel ist ausschließlich das Auslösen von Aktionen. Beim XSS hingegen läuft der Schadcode direkt im Kontext der vertrauenswürdigen Seite - mit weitreichenden Folgen.

Warum der Schutz vor einer Attacke nicht vor der anderen schützt

CSRF-Token schützen effektiv gegen gefälschte Anfragen von fremden Seiten, lösen aber das XSS-Problem nicht. Gelingt es einem Angreifer, JavaScript auf einer verwundbaren Seite auszuführen, kann er in vielen Fällen auch mit Schutzmechanismen wie CSRF-Token interagieren.

Umgekehrt gilt: Maßnahmen gegen XSS - wie Daten-Escaping, Input-Filter und Content Security Policy - ersetzen nicht die Überprüfung von CSRF-Token und SameSite-Cookies.

CSRF und XSS zählen somit zu unterschiedlichen Klassen von Web-Schwachstellen. Beide können ähnliche Folgen haben, nutzen aber verschiedene Angriffswege und erfordern jeweils spezifische Schutzmaßnahmen.

Wie schützt man eine Website vor CSRF-Angriffen?

Alle datenverändernden Anfragen überprüfen

CSRF-Schutz beginnt mit der richtigen Anwendungslogik. Anfragen, die Nutzerdaten oder den Systemzustand ändern, dürfen nicht allein aufgrund einer gültigen Session ausgeführt werden.

Insbesondere sollten GET-Anfragen niemals für Änderungen genutzt werden. GET dient ausschließlich dem Abruf von Daten, während Änderungen, Löschungen oder Transaktionen über Methoden wie POST, PUT, PATCH oder DELETE erfolgen sollten - stets mit zusätzlicher Überprüfung.

Die Wahl des HTTP-Methodentyps allein reicht jedoch nicht: Vertraut der Server ausschließlich auf die Session, bleibt die CSRF-Schwachstelle bestehen. Sensible Anfragen müssen daher einen Herkunftsnachweis oder ein eindeutiges Bestätigungsmerkmal enthalten.

CSRF-Token und SameSite-Cookies einsetzen

Ein zentraler Schutzmechanismus sind CSRF-Token. Der Server generiert einen nicht vorhersagbaren Wert und erwartet ihn bei jeder sensiblen Anfrage. Da fremde Seiten den Token in der Regel nicht kennen, werden gefälschte Anfragen auch bei aktiver Session abgelehnt.

Ein weiterer Schutz ist das SameSite-Attribut für Cookies. Es limitiert die Cookie-Übertragung bei bereichsübergreifenden Anfragen und reduziert so das Risiko, dass der Browser automatisch Autorisierungsdaten an fremdinitiierte Anfragen anhängt.

CSRF-Token und SameSite-Cookies sind keine Alternativen, sondern ergänzen sich als unterschiedliche Schutzebenen: Der Token bestätigt die Legitimität der Anfrage, die SameSite-Policy begrenzt die automatische Cookie-Übermittlung.

CSRF ist nur eine von vielen Arten von Web-Schwachstellen. Beim SQL-Injection-Angriff etwa zielt der Angreifer auf die Kommunikation zwischen Anwendung und Datenbank. Mehr dazu erfahren Sie im Beitrag SQL-Injektion: Gefahr für Webanwendungen und effektive Schutzmaßnahmen.

Zusätzliche Prüfungen für kritische Aktionen

Gerade bei besonders sensiblen Aktionen reicht ein CSRF-Token oft nicht aus. Passwortänderungen, Hinzufügen neuer Wiederherstellungsmethoden oder Rechteverwaltung sollten eine erneute Identitätsprüfung verlangen.

• Passworteingabe erneut abfragen
• Einmal-Codes verwenden
• Separate Bestätigung kritischer Aktionen

So wird verhindert, dass zufällig oder manipulativ ausgelöste Anfragen sofort gravierende Veränderungen am Account bewirken.

Zusätzlich sollte der Server die Origin- und Referer-Header auswerten - sie geben Aufschluss über die Herkunft der Anfrage. Diese Prüfungen sind als ergänzende, nicht als alleinige Schutzmaßnahme zu verstehen.

Ein sicherer Schutz basiert auf mehreren Ebenen: korrekter Einsatz von HTTP-Methoden, CSRF-Token, SameSite-Cookies, Prüfung der Anfrageherkunft und zusätzliche Verifizierung bei kritischen Aktionen.

Fazit

Der CSRF-Angriff nutzt nicht das Passwort, sondern das Vertrauen einer Website in den bereits autorisierten Browser. Ist der Nutzer eingeloggt und betrachtet der Server eine gültige Session als ausreichenden Beweis, kann eine fremde Seite versuchen, im Namen des Nutzers Anfragen auszulösen.

Der wichtigste Schutz sind CSRF-Token, die dem Server eine Prüfung ermöglichen, ob die Anfrage tatsächlich von der Anwendung stammt. Ergänzend helfen SameSite-Cookies, die Kontrolle von Origin und Referer, richtige HTTP-Methoden sowie die zusätzliche Bestätigung besonders sensibler Aktionen.

Für Entwickler gilt: Eine gültige Session bedeutet noch nicht, dass der Nutzer die Aktion wirklich initiieren wollte. Werden Daten verändert, muss der Server die Legitimität jeder Änderung gesondert prüfen.