Csrf: Anwendung, typische Fehler, Praxiswissen und saubere Workflows

Cross-Site Request Forgery ist kein Angriff auf Authentifizierung im engeren Sinn, sondern auf das Vertrauen einer Anwendung in den Browserzustand eines bereits angemeldeten Benutzers. Der Kernfehler liegt darin, dass der Server eine zustandsverändernde Anfrage akzeptiert, obwohl sie nicht aus einer legitimen Interaktion innerhalb der Anwendung stammt. Der Browser sendet dabei vorhandene Sitzungsinformationen wie Cookies, eventuell Client-Zertifikate oder andere automatisch beigefügte Authentifizierungsmerkmale mit. Genau diese automatische Mitgabe macht CSRF praktisch.

Entscheidend ist die Abgrenzung zu XSS. Bei XSS wird Code im Kontext der Zielanwendung ausgeführt. Bei CSRF wird kein Code in der Zielanwendung benötigt. Es reicht, dass ein Opfer eine präparierte Seite besucht oder ein manipuliertes Element lädt, während eine gültige Session zur Zielanwendung besteht. Der Server sieht dann oft nur eine formal korrekte Anfrage mit gültigem Session-Cookie. Wenn keine zusätzliche Anforderungsvalidierung stattfindet, wird die Aktion ausgeführt.

Typische Ziele sind Passwortänderungen, E-Mail-Änderungen, Profilupdates, das Hinzufügen von API-Schlüsseln, das Erzeugen neuer Sessions, Geldtransfers, Rollenänderungen in schwach geschützten Admin-Oberflächen oder das Verknüpfen externer Konten. Besonders kritisch sind Funktionen, die ohne erneute Passwortabfrage oder ohne transaktionsspezifische Bestätigung arbeiten.

In Burp Suite wird CSRF nicht isoliert betrachtet, sondern als Teil von Session- und Zustandslogik. Wer nur nach einem fehlenden Token sucht, übersieht oft reale Schutzmechanismen oder reale Schwächen. Ein belastbarer Test betrachtet mindestens die HTTP-Methode, die Cookie-Eigenschaften, die Herkunftsprüfung, die Token-Bindung an Session und Aktion sowie das Verhalten bei Cross-Site-Navigation. Für den Einstieg in die Werkzeugbasis sind Proxy, Repeater und Session Management die zentralen Bereiche.

Ein häufiger Denkfehler besteht darin, jede POST-Anfrage ohne sichtbaren Token automatisch als verwundbar zu bewerten. Das ist fachlich unzureichend. Moderne Browsermechanismen wie SameSite=Lax oder SameSite=Strict können bestimmte klassische CSRF-Szenarien bereits blockieren. Umgekehrt ist eine Anwendung trotz Token angreifbar, wenn der Token statisch ist, nicht an die Session gebunden wird, serverseitig nicht geprüft wird oder über GET-Anfragen wiederverwendbar abrufbar ist.

CSRF ist außerdem nicht auf HTML-Formulare beschränkt. Auch JSON-Endpunkte, GraphQL-Mutationen, Multi-Step-Workflows und API-nahe Webanwendungen können betroffen sein, sofern Browser automatisch Authentifizierungsdaten mitsenden und der Server keine robuste Request-Authentizität prüft. Deshalb muss jede Bewertung an der realen Browser- und Serverlogik ausgerichtet werden, nicht an alten Checklisten.

Der erste praktische Schritt ist nicht das Bauen eines Exploits, sondern das Filtern der wirklich relevanten Requests. CSRF betrifft nur Anfragen, die serverseitigen Zustand verändern oder sicherheitsrelevante Aktionen auslösen. Reine Lesezugriffe sind in der Regel nicht das primäre Ziel, auch wenn es Sonderfälle mit serverseitigen Nebenwirkungen gibt. In der Proxy History lässt sich schnell erkennen, welche Endpunkte nach Login aufgerufen werden und welche Parameter Änderungen auslösen.

Besonders verdächtig sind Requests an Profil-, Konto-, Zahlungs-, Administrations- und Integrationsfunktionen. Dazu gehören auch Endpunkte, die auf den ersten Blick harmlos wirken, etwa das Aktivieren von Benachrichtigungen, das Setzen einer Weiterleitungsadresse oder das Erzeugen eines API-Tokens. In vielen realen Anwendungen sind genau diese Funktionen schwächer abgesichert als Passwort- oder Zahlungsänderungen.

Ein sauberer Test beginnt mit der Frage, welche Authentifizierungsmerkmale der Browser automatisch mitsendet. Klassische Session-Cookies sind der Standardfall. Wenn eine Anwendung stattdessen Bearer-Tokens im Authorization-Header verwendet, ist klassisches CSRF oft nicht direkt möglich, weil fremde Seiten diesen Header nicht einfach setzen können. Trotzdem muss geprüft werden, ob die Webanwendung parallel Cookie-basierte Sessions nutzt oder ob CORS-Fehlkonfigurationen neue Wege öffnen.

• State-changing Requests identifizieren: Passwort, E-Mail, Telefonnummer, Rollen, Zahlungsdaten, API-Keys, Verknüpfungen zu Drittanbietern.
• Prüfen, ob Cookies automatisch mitgesendet werden und welche SameSite-, Secure- und HttpOnly-Attribute gesetzt sind.
• Untersuchen, ob der Server zusätzliche Signale wie CSRF-Token, Origin, Referer oder Step-Up-Authentifizierung verlangt.

Auch die HTTP-Methode ist relevant, aber nicht allein entscheidend. GET für zustandsverändernde Aktionen ist ein schwerer Designfehler und oft direkt ausnutzbar. POST, PUT, PATCH und DELETE sind nicht automatisch sicher. Wenn der Server keine Herkunfts- oder Token-Prüfung durchführt, bleibt die Schwachstelle bestehen. Ebenso wichtig ist der Content-Type. Manche Anwendungen akzeptieren nur application/json und verlassen sich darauf als Schutz. Das ist kein belastbarer Schutz, weil Browser in bestimmten Konstellationen trotzdem ausnutzbare Requests erzeugen können oder alternative Endpunkte mit form-urlencoded existieren.

Ein weiterer Punkt ist die Benutzerinteraktion. Manche Funktionen sind nur nach einem vorherigen Formularabruf erreichbar, weil dort ein Token generiert wird. Andere akzeptieren direkte Requests ohne Vorstufe. Genau diese Unterschiede entscheiden darüber, ob eine Schwachstelle praktisch ausnutzbar ist oder nur theoretisch wirkt. Deshalb sollte jeder relevante Request zunächst isoliert in Repeater Anleitung reproduzierbar gemacht werden, bevor weitere Annahmen getroffen werden.

Ein belastbarer CSRF-Schutz besteht selten aus nur einer Maßnahme. In modernen Anwendungen wird meist eine Kombination eingesetzt. Der klassische Schutz ist ein serverseitig validierter Anti-CSRF-Token, der pro Session oder idealerweise pro Aktion erzeugt und in jeder zustandsverändernden Anfrage geprüft wird. Der Token muss unvorhersehbar sein, an die Session gebunden sein und serverseitig tatsächlich validiert werden. Ein Token, der nur im Frontend existiert oder bei jeder beliebigen Anfrage akzeptiert wird, ist wertlos.

SameSite-Cookies reduzieren die Angriffsfläche erheblich, ersetzen aber keine saubere Serverlogik. SameSite=Strict blockiert Cookies bei Cross-Site-Navigation sehr konsequent. SameSite=Lax erlaubt Cookies in bestimmten Navigationskontexten, blockiert aber viele klassische Hintergrund-Requests. SameSite=None erfordert Secure und erlaubt Cross-Site-Szenarien explizit. In der Praxis scheitern viele Bewertungen daran, dass Tester nur den Cookie sehen, aber nicht das reale Browserverhalten gegen den konkreten Request-Typ prüfen.

Origin- und Referer-Prüfungen sind zusätzliche Schutzschichten. Origin ist für viele zustandsverändernde Requests verlässlicher als Referer, weil Referer durch Datenschutzmechanismen oder Browserverhalten fehlen kann. Eine robuste Implementierung akzeptiert nur erwartete Origins und behandelt fehlende oder abweichende Werte restriktiv. Schwach ist eine Prüfung, die nur auf Teilstrings vergleicht, Subdomains unsauber behandelt oder bei fehlendem Header automatisch erlaubt.

Wichtig ist die Wechselwirkung dieser Mechanismen. Eine Anwendung kann ohne sichtbaren Token trotzdem wirksam geschützt sein, wenn SameSite und Origin-Prüfung sauber greifen. Umgekehrt kann ein vorhandener Token wirkungslos sein, wenn er in einer GET-Anfrage offengelegt wird, in JavaScript global verfügbar ist und serverseitig nicht an die Session gebunden wird. Wer CSRF testet, muss deshalb immer die gesamte Kette betrachten: Browser sendet was, Server prüft was, Anwendung akzeptiert was.

Auch Login-CSRF und Logout-CSRF dürfen nicht übersehen werden. Beim Login-CSRF wird das Opfer unbemerkt in ein vom Angreifer kontrolliertes Konto eingeloggt. Das kann spätere Datenabflüsse oder Fehlzuordnungen ermöglichen. Logout-CSRF wirkt oft harmlos, kann aber Schutzmechanismen umgehen oder Benutzer in unsichere Zustände zwingen. Solche Fälle liegen an der Schnittstelle zu Login Testing und Cookies.

Ein professioneller Befund beschreibt daher nicht nur, dass ein Token fehlt oder vorhanden ist, sondern ob die Gesamtkombination aus Token, Cookie-Policy und Herkunftsprüfung einen realen Cross-Site-Angriff verhindert. Alles andere führt zu Fehlbewertungen, unnötigen False Positives oder übersehenen Schwachstellen.

Ein sauberer Workflow beginnt im Browser mit einer frischen, bekannten Session. Danach wird die Zielaktion einmal regulär ausgeführt, während Burp den Traffic mitschneidet. In der Regel wird der relevante Request aus dem Proxy an Repeater gesendet. Dort wird zuerst geprüft, ob sich die Aktion mit identischen Parametern reproduzieren lässt. Ohne reproduzierbaren Baseline-Request ist jede weitere Aussage unsicher.

Im nächsten Schritt wird die Anfrage systematisch reduziert. Nicht benötigte Header werden entfernt, optionale Parameter variiert und auffällige Felder wie csrf, token, authenticity_token oder hidden form values isoliert betrachtet. Ziel ist nicht nur, den Request zum Funktionieren zu bringen, sondern zu verstehen, welche Bestandteile serverseitig wirklich relevant sind. Genau hier trennt sich oberflächliches Klicken von belastbarer Analyse.

Danach folgt die Herkunftsperspektive. Ein echter CSRF-Test fragt: Kann ein fremder Ursprung diese Anfrage in einer Form erzeugen, bei der der Browser die Session des Opfers mitsendet und der Server sie akzeptiert? Dazu wird geprüft, ob der Request als simples Formular, als Bild- oder Link-Trigger, als Auto-Submit-Formular oder über andere browsernative Mechanismen nachstellbar wäre. JSON-Requests, Custom-Header und Preflight-Anforderungen verändern die Lage, schließen CSRF aber nicht pauschal aus.

In Burp selbst ist Repeater das Hauptwerkzeug für die serverseitige Validierung. Der Browser bleibt jedoch unverzichtbar, wenn SameSite- oder Origin-Verhalten realistisch geprüft werden muss. Repeater allein simuliert keinen echten Cross-Site-Kontext. Deshalb ist die Kombination aus Proxy-Aufzeichnung, Repeater-Analyse und realem Browserverhalten entscheidend. Wer nur Repeater nutzt, bewertet oft falsch, weil Cookies dort manuell kontrolliert werden und Browserrestriktionen nicht automatisch greifen.

Für größere Anwendungen lohnt sich ein strukturierter Ablauf nach Funktionsgruppen. Zuerst Konto- und Profilfunktionen, dann Integrationen, dann Admin-Funktionen, dann selten genutzte Einstellungen. Parallel sollte Scope sauber gesetzt sein, damit keine irrelevanten Requests die Analyse verwässern. Für die Grundkonfiguration sind Scope und Workflow eng miteinander verknüpft.

Ein typischer Minimalablauf sieht so aus: Request erfassen, in Repeater reproduzieren, Token- und Header-Abhängigkeiten prüfen, Cookie-Attribute analysieren, Browser-Cross-Site-Verhalten testen, Ergebnis dokumentieren. Erst wenn diese Schritte konsistent sind, ist eine Aussage belastbar. Alles andere produziert Vermutungen statt Befunde.

POST /account/email/change HTTP/1.1
Host: target.example
Cookie: session=abc123
Content-Type: application/x-www-form-urlencoded

email=attacker%40example.net&csrf=7f9c2d1a

Bei diesem Beispiel ist die entscheidende Frage nicht nur, ob ein csrf-Parameter vorhanden ist, sondern ob der Server ihn prüft, ob er an die Session gebunden ist und ob dieselbe Aktion ohne diesen Parameter oder mit einem fremden Wert ebenfalls akzeptiert wird.

Viele Anwendungen zeigen einen Token im Formular und gelten intern sofort als geschützt. Genau hier entstehen gefährliche Fehlannahmen. Ein Token schützt nur dann, wenn der Server ihn korrekt validiert und wenn der Token nicht trivial beschaffbar oder wiederverwendbar ist. In Repeater wird deshalb nicht nur ein Request mit gültigem Token gesendet, sondern eine ganze Reihe kontrollierter Varianten.

• Token komplett entfernen und prüfen, ob die Aktion trotzdem ausgeführt wird.
• Token durch Zufallswert ersetzen und auf serverseitige Ablehnung achten.
• Token aus einer anderen Session oder von einem anderen Benutzer verwenden und die Bindung testen.

Zusätzlich sollte geprüft werden, ob der Token pro Formular, pro Request oder nur pro Session gilt. Ein per Session stabiler Token ist nicht automatisch unsicher, aber er vergrößert die Angriffsfläche, wenn er an anderer Stelle offengelegt werden kann. Kritisch wird es, wenn derselbe Token in mehreren Funktionen wiederverwendet wird oder wenn er in GET-Antworten, JavaScript-Variablen oder Caches auftaucht. Noch problematischer ist ein Double-Submit-Cookie-Ansatz ohne serverseitige Bindung oder mit vorhersagbarer Token-Erzeugung.

Ein häufiger Implementierungsfehler ist die reine Presence-Validation. Der Server prüft dann nur, ob ein Feld namens csrf vorhanden ist, nicht aber dessen Wert. Ebenso verbreitet sind Fallbacks wie: Wenn kein Token vorhanden ist, akzeptiere die Anfrage für mobile Clients oder Legacy-Endpunkte trotzdem. Solche Sonderpfade finden sich oft in älteren APIs, Migrationsrouten oder Admin-Bereichen.

Auch Multi-Step-Formulare verdienen Aufmerksamkeit. Manche Anwendungen generieren im ersten Schritt einen Token, validieren ihn aber im finalen Commit nicht mehr. Andere prüfen den Token nur clientseitig und verlassen sich serverseitig auf eine Workflow-ID. In solchen Fällen kann eine direkte Anfrage an den finalen Endpunkt ohne legitime Benutzerinteraktion erfolgreich sein.

Für differenzierte Vergleiche zwischen funktionierenden und fehlschlagenden Requests ist Comparer nützlich. Damit lassen sich Response-Unterschiede, Redirect-Ketten und Fehlermeldungen präziser auswerten. Gerade bei Anwendungen, die immer HTTP 200 liefern und Fehler nur im HTML oder JSON kodieren, spart das viel Zeit.

POST /profile/update HTTP/1.1
Host: target.example
Cookie: session=victim123
Content-Type: application/x-www-form-urlencoded

display_name=demo&csrf=INVALID

Wenn dieser Request dieselbe Wirkung hat wie mit einem gültigen Token, liegt kein Schutz vor. Wenn der Server zwar eine Fehlermeldung zeigt, die Änderung aber trotzdem persistiert, ist die Lage noch kritischer, weil Logging und UI einen falschen Sicherheitszustand suggerieren.

SameSite hat die praktische CSRF-Landschaft stark verändert. Viele ältere Testmethoden ignorieren das und melden Schwachstellen, die im realen Browser nicht mehr ausnutzbar sind. Umgekehrt verlassen sich manche Teams blind auf SameSite, obwohl einzelne Flows, Browser-Versionen, Subdomain-Konstellationen oder explizit gesetzte None-Cookies den Schutz aushebeln. Deshalb muss die Bewertung immer an der tatsächlichen Cookie-Konfiguration und am realen Request-Kontext erfolgen.

Wichtig ist die Unterscheidung zwischen same-site und same-origin. Zwei unterschiedliche Subdomains können same-site sein, obwohl sie nicht denselben Origin teilen. Das ist relevant, wenn ein Angreifer Kontrolle über eine Subdomain besitzt oder wenn Drittanwendungen unter derselben registrierbaren Domain betrieben werden. In solchen Fällen kann eine rein auf SameSite gestützte Sicherheitsannahme zu optimistisch sein.

Bei Lax werden Cookies typischerweise bei Top-Level-Navigationen unter bestimmten Bedingungen mitgesendet, nicht aber bei vielen eingebetteten oder programmgesteuerten Cross-Site-Requests. Das schützt gegen klassische Auto-Submit-Formulare in vielen Fällen, aber nicht gegen jedes Szenario. Besonders bei GET-basierten Zustandsänderungen bleibt das Risiko hoch. Strict ist deutlich robuster, kann aber funktionale Nebenwirkungen haben, etwa bei SSO- oder Deep-Link-Flows. None erlaubt Cross-Site bewusst und muss daher mit anderen Schutzmechanismen kombiniert werden.

Ein häufiger Fehler im Test ist das manuelle Nachstellen eines Requests in Repeater mit gesetztem Cookie und anschließende Schlussfolgerung, die Anwendung sei CSRF-anfällig. Das beweist nur, dass der Server den Request mit gültiger Session akzeptiert. Es beweist nicht, dass ein Browser denselben Request in einem echten Cross-Site-Szenario mitsenden würde. Deshalb gehören Browsertests zwingend dazu, insbesondere wenn SameSite eine Rolle spielt.

Auch Redirects und Mischflüsse sind relevant. Eine Anwendung kann initial einen Cross-Site-Request blockieren, aber nach einer Navigation oder einem Redirect in einen Zustand gelangen, in dem Cookies wieder gesendet werden. Ebenso können Legacy-Cookies ohne SameSite neben modernen Cookies existieren. Solche Mischzustände sind in großen Anwendungen nicht selten und führen zu schwer erkennbaren Teilrisiken.

Wer Burp für diese Analyse nutzt, sollte den Browserverkehr vollständig verstehen. Die Seiten zu Proxy Https und Zertifikat Installieren sind dafür relevant, weil fehlerhafte TLS- oder Proxy-Konfigurationen sonst das reale Verhalten verfälschen. Ein unvollständig eingebundener Testbrowser liefert bei CSRF-Bewertungen schnell falsche Sicherheit oder falschen Alarm.

CSRF gehört zu den Schwachstellen, die besonders oft falsch bewertet werden. Der häufigste False Positive entsteht, wenn ein Tester einen Request ohne Token in Repeater erfolgreich reproduziert und daraus direkt eine Ausnutzbarkeit ableitet. Ohne Nachweis, dass ein Browser diesen Request in einem Cross-Site-Kontext mit denselben Authentifizierungsmerkmalen senden würde, ist die Aussage unvollständig. Gerade bei SameSite=Lax oder Strict ist das ein klassischer Fehler.

Ein weiterer Fehler ist die Gleichsetzung von fehlendem Token mit kritischer Schwachstelle. Manche Anwendungen nutzen bewusst Origin-Validierung plus SameSite und sind damit gegen den relevanten Angriffsweg ausreichend geschützt. Das bedeutet nicht, dass Token unnötig wären, aber die Bewertung muss die reale Schutzwirkung abbilden. Ein Report, der nur das Fehlen eines Tokens nennt, ohne Browserverhalten und Servervalidierung zu prüfen, ist fachlich schwach.

Auf der anderen Seite werden echte Schwachstellen oft übersehen, wenn ein sichtbarer Token vorhanden ist. Viele Reports enden an der Oberfläche und prüfen nicht, ob der Token serverseitig bindend ist. Ebenso werden GET-Endpunkte mit Seiteneffekten, Login-CSRF, API-nahe Webflows oder administrative Sonderrouten häufig nicht getestet. Diese blinden Flecken sind in realen Assessments deutlich relevanter als das hundertste Standardformular.

• False Positive: Repeater zeigt Erfolg, Browser würde Cookies im Cross-Site-Kontext aber nicht mitsenden.
• False Negative: Token vorhanden, aber serverseitig nicht validiert oder nicht an Session gebunden.
• Unklare Bewertung: Schutz greift nur für Standardpfade, nicht aber für Legacy-, API- oder Admin-Endpunkte.

Schlechte Reports beschreiben nur Symptome. Gute Reports beschreiben die exakte Bedingungskette: Welche Sessionart liegt vor, welche Cookies werden automatisch gesendet, welche Header werden geprüft, welche Request-Variante war erfolgreich, welche Browserbedingung war nötig und welche konkrete Aktion konnte ausgelöst werden. Nur so lässt sich das Risiko realistisch einordnen und reproduzieren.

Auch die Auswirkung muss präzise sein. Eine CSRF auf „Profilfarbe ändern“ ist nicht gleichwertig mit einer CSRF auf „MFA deaktivieren“ oder „Bankverbindung ändern“. Die Schwere ergibt sich aus der ausgelösten Aktion, der erforderlichen Benutzerinteraktion, der Reichweite des Angriffs und der Wahrscheinlichkeit, dass ein Opfer mit aktiver Session erreicht wird. Diese Differenzierung ist wichtiger als pauschale Schweregrade.

Für ergänzende Analysen kann Scanner Hinweise liefern, aber die finale Bewertung bleibt manuell. Automatisierte Checks erkennen Muster, nicht die tatsächliche Ausnutzbarkeit im konkreten Browser- und Sessionkontext.

Ein klassischer Fall ist die E-Mail-Änderung im Benutzerkonto. Der Request ist ein POST mit sessionbasiertem Cookie, aber ohne Token und ohne Origin-Prüfung. Wenn SameSite=None gesetzt ist oder ein Legacy-Cookie ohne SameSite existiert, lässt sich die Aktion oft direkt per Cross-Site-Formular auslösen. Die Auswirkung ist hoch, wenn Passwort-Reset-Mails danach an die neue Adresse gehen.

Ein zweiter Fall betrifft Admin-Oberflächen. Dort finden sich häufig interne Komfortfunktionen wie „Benutzer aktivieren“, „Rolle setzen“ oder „API-Key erzeugen“. Solche Endpunkte sind oft historisch gewachsen und schlechter abgesichert als öffentliche Benutzerflows. Wenn ein Administrator parallel im Backend angemeldet ist, kann schon der Besuch einer präparierten internen Wiki-Seite oder eines externen Links genügen. In Assessments ist dieser Bereich besonders relevant, weil die Wirkung einer erfolgreichen CSRF hier schnell privilegierte Änderungen umfasst.

Ein dritter Fall sind JSON-Endpunkte. Viele Teams gehen davon aus, dass JSON automatisch vor CSRF schützt. Das stimmt nur teilweise. Wenn der Endpunkt ausschließlich application/json akzeptiert, keine browserkompatiblen Alternativen existieren und keine permissiven CORS-Regeln vorliegen, sinkt das Risiko klassischer CSRF deutlich. In der Praxis existieren aber oft parallele Form-Endpunkte, method override Mechanismen oder Legacy-Routen, die denselben Zustand ändern. Genau diese Alternativpfade müssen gesucht werden.

Auch OAuth- oder Konto-Verknüpfungsflüsse sind anfällig, wenn state-Parameter oder transaktionsspezifische Bindungen fehlen. Solche Fälle liegen nahe an Oauth Testing. Ebenso können CSRF und Clickjacking zusammenwirken, wenn Benutzer zu einer legitimen Aktion verleitet werden und die Anwendung keine zusätzliche Bestätigung verlangt.

POST /admin/user/role HTTP/1.1
Host: target.example
Cookie: admin_session=xyz
Content-Type: application/x-www-form-urlencoded

user_id=1042&role=administrator

Wenn dieser Request ohne Token, ohne Origin-Prüfung und mit Cross-Site sendbaren Cookies akzeptiert wird, ist die Schwachstelle gravierend. Die Bewertung steigt weiter, wenn keine Protokollierung erfolgt oder wenn die Änderung ohne sichtbare Rückmeldung im UI passiert.

Ein weiteres realistisches Beispiel ist Login-CSRF. Ein Opfer wird unbemerkt in ein vom Angreifer kontrolliertes Konto eingeloggt. Danach lädt das Opfer persönliche Daten hoch oder hinterlegt Informationen, die im Konto des Angreifers landen. Dieser Fall wird oft unterschätzt, weil keine direkte Kontoübernahme stattfindet. Die praktische Auswirkung kann trotzdem erheblich sein, etwa bei Support-Portalen, Bewerbungsplattformen oder Cloud-Diensten.

Ein professioneller CSRF-Workflow ist reproduzierbar, sparsam und eindeutig. Zuerst wird die Sessionbasis definiert: Benutzerrolle, Browser, Cookie-Zustand, MFA-Status und Ausgangsseite. Danach wird genau eine Zielaktion isoliert getestet. Jede Änderung an Request, Headern oder Session wird dokumentiert. So lässt sich später nachvollziehen, ob ein Erfolg auf fehlender Token-Prüfung, auf Cookie-Verhalten oder auf einem Sonderpfad beruht.

Für Teams ist es sinnvoll, CSRF nicht als Einzeltest, sondern als festen Bestandteil des Web-Pentest-Ablaufs zu behandeln. Nach Authentifizierung und Sessionanalyse folgen systematisch alle state-changing Funktionen. Besonders wichtig ist die Trennung zwischen serverseitiger Akzeptanz und browserseitiger Ausnutzbarkeit. Beide Ebenen müssen im Testprotokoll getrennt festgehalten werden. Das verhindert Missverständnisse bei Review, Retest und Entwicklung.

Gegenmaßnahmen sollten konkret und priorisiert sein. Für kritische Aktionen ist ein serverseitig validierter Anti-CSRF-Token weiterhin der robuste Standard. Ergänzend sollten Session-Cookies mit passenden SameSite-Attributen versehen werden. Origin-Validierung ist eine starke zusätzliche Schicht, insbesondere für moderne Anwendungen. Hochkritische Aktionen wie Passwortänderung, MFA-Deaktivierung oder Zahlungsänderungen sollten außerdem eine erneute Authentifizierung oder transaktionsspezifische Bestätigung verlangen.

Wichtig ist, dass Schutzmaßnahmen konsistent über alle Endpunkte ausgerollt werden. In realen Umgebungen scheitert Sicherheit oft nicht am Hauptformular, sondern an Legacy-Routen, mobilen APIs, Admin-Tools oder asynchronen Nebenfunktionen. Deshalb muss jede Abhilfe gegen den gesamten Funktionsraum geprüft werden. Ein einzelner gefixter Endpunkt beseitigt selten das Gesamtproblem.

Für die tägliche Arbeit mit Burp helfen stabile Grundlagen in Erste Schritte, Proxy Intercept und Debugging. Gerade bei CSRF spart ein sauber eingerichteter Browser mit klarer Sessiontrennung viel Zeit und reduziert Fehlinterpretationen.

Am Ende zählt nicht, ob ein Formularfeld csrf heißt, sondern ob eine fremde Seite eine sicherheitsrelevante Aktion im Kontext des Opfers auslösen kann. Genau diese Frage muss jeder Test beantworten. Wenn der Nachweis sauber geführt wird, sind Befund, Risiko und Abhilfe klar. Wenn diese Kette fehlt, bleibt nur eine Vermutung.