CSRF (Cross-Site Request Forgery)
CSRF zwingt eingeloggte User, ungewollte Aktionen auszuführen. Der Browser sendet automatisch Cookies mit - der Server denkt, der User wollte die Aktion. Schutz: CSRF-Tokens.
detaillierte erklärung
Cross-Site Request Forgery (CSRF) nutzt aus, dass Browser automatisch Cookies mit jedem Request an eine Domain senden. Angreifer erstellt bösartigen Request (z.B. Geld überweisen) und täuscht den eingeloggten User, diesen auszulösen (via Link, Image-Tag, verstecktes Formular). Der Server erhält Request mit gültigen Session-Cookies und denkt, der User wollte die Aktion. Voraussetzungen: 1) Relevante Aktion existiert (Passwort ändern, Überweisung). 2) Cookie-basierte Session. 3) Keine unvorhersehbaren Parameter. Angriffsvektoren: GET via <img src="bank.com/transfer?to=attacker&amount=1000">, POST via verstecktes Formular mit JavaScript-Autosubmit. Schutzmaßnahmen: CSRF-Token (unvorhersehbarer Wert im Formular, der im Cookie fehlt), SameSite-Cookie-Attribut (verhindert Cross-Site-Requests), Referrer-Prüfung (unsicher, spoofbar). Ineffektiv: Secret Cookies (werden trotzdem gesendet), HTTPS (kein CSRF-Schutz), POST-only (HTML-Forms können POST).
warum ist das wichtig?
CSRF ist klassischer Web-Angriff - du musst verstehen, warum automatisch gesendete Cookies das Problem sind und wie CSRF-Tokens schützen. OWASP-Top-10-Wissen für Pentesting und Secure Development.
häufige fehler
- ⚠Secret Cookies verhindern CSRF - Nein, alle Cookies werden automatisch gesendet
- ⚠HTTPS schützt vor CSRF - Nein, HTTPS verschlüsselt nur, verhindert CSRF nicht
- ⚠POST-only Apps sind sicher - Nein, HTML-Forms können POST-Requests machen