Ein Endpunkt für Geldüberweisungen akzeptiert ein einfaches cookie-authentifiziertes POST ohne Token. Was fehlt?
Kurzantwort
Wenn der Browser das Sitzungs-Cookie automatisch anhängt, kann eine bösartige Seite die Überweisung im Namen des Opfers auslösen — das ist Cross-Site Request Forgery (CSRF). Schützen Sie zustandsändernde Anfragen mit Anti-CSRF-Token und SameSite-Cookies und prüfen Sie den Origin/Referer-Header. Das Cookie beweist die Identität, aber nicht die Absicht, ein Login-CAPTCHA schützt keine bereits authentifizierte Aktion, und HTTPS schützt die Transportvertraulichkeit, nicht die Anfragenfälschung.
Ein Überweisungs-Endpunkt, der nichts außer dem Sitzungs-Cookie vertraut, ist ein Lehrbuchziel für Cross-Site Request Forgery (CSRF). Der Browser hängt dieses Cookie bereitwillig an jede Anfrage an Ihre Domain an — auch an eine, die von einer völlig fremden, vom Angreifer kontrollierten Seite ausgelöst wird, die das Opfer zufällig besucht.
Wie der Angriff funktioniert
Der Angreifer hostet eine Seite mit einem sich selbst abschickenden Formular (oder einem Bild/fetch), das ein POST an Ihren Überweisungs-Endpunkt mit seinem gewählten Empfänger und Betrag sendet. Wenn ein angemeldetes Opfer diese Seite öffnet, sendet sein Browser die Anfrage mit dem gültigen Sitzungs-Cookie, und Ihr Server — der eine korrekt authentifizierte Sitzung sieht — führt die Überweisung aus. Das Opfer hat nie auf „Geld senden" geklickt. Das Cookie bewies, wer es ist, aber nie, dass es diese Aktion wollte.
Die richtige Lösung
Zustandsändernde Anfragen brauchen einen Absichtsnachweis, den eine fremde Seite nicht liefern kann:
- Anti-CSRF-Token (Synchronizer-Token-Muster): ein pro Sitzung unvorhersehbarer Wert, der ins Formular eingebettet und serverseitig validiert wird. Ein Cross-Site-Angreifer kann ihn wegen der Same-Origin-Policy nicht lesen.
- SameSite-Cookies (
LaxoderStrict), damit das Sitzungs-Cookie bei Cross-Site-Anfragen gar nicht erst gesendet wird — eine starke, moderne Grundlage. - Prüfen Sie den Origin/Referer-Header bei sensiblen Anfragen als Verteidigung in der Tiefe.
Warum die anderen Antworten falsch sind
- „Nichts — Cookies authentifizieren den Benutzer" verwechselt Authentifizierung mit der Autorisierung dieser konkreten Anfrage. Genau diese Lücke nutzt CSRF aus.
- Ein Login-CAPTCHA schützt das Login-Ereignis; es bewirkt nichts, sobald der Benutzer bereits authentifiziert ist und die gefälschte Anfrage auf seiner bestehenden Sitzung aufsetzt.
- HTTPS schützt Daten während der Übertragung vor Mithören und Manipulation — es hindert eine bösartige Seite nicht daran, den Browser des Opfers eine vollkommen gültige, verschlüsselte, gefälschte Anfrage senden zu lassen.
Der Interviewer will sehen, dass Sie Identität von Absicht trennen und zu Token und SameSite greifen, nicht zur Transportsicherheit.
Wahrscheinliche Anschlussfragen
- Wie unterscheidet sich SameSite=Lax von Strict, und wo lässt jeweils eine Lücke?
- Warum ist das Synchronizer-Token-Muster robuster, als nur den Referer zu prüfen?
- Wie würden sich CSRF-Abwehrmaßnahmen bei einer Cookie-Sitzung gegenüber einer Bearer-Token-API unterscheiden?