CSRF einfach erklärt
Stellen Sie sich einen Boten vor, der bei Ihrer Bank bekannt ist und einen Dauerausweis mit Ihrem Namen trägt. Jeden Auftrag, den er abgibt, führt die Bank ohne Rückfrage aus – er hat ja den Ausweis dabei. Bei CSRF steckt ein Betrüger dem Boten unterwegs heimlich einen zusätzlichen Auftrag zu. Die Bank sieht den gültigen Ausweis und führt auch diesen Auftrag aus.
In der digitalen Welt ist Ihr Browser dieser Bote. Wenn Sie sich bei einer Webanwendung anmelden – etwa im Onlinebanking, im Verwaltungsbereich eines Webshops oder im Firmenportal –, speichert der Browser ein Sitzungscookie. Das ist eine Art digitaler Besucherausweis. Der Browser schickt ihn bei jeder Anfrage an diese Anwendung automatisch mit, damit Sie sich nicht ständig neu anmelden müssen.
Zum Namen: „Cross-Site“ bedeutet, dass die Anfrage von einer fremden Website ausgeht; „Request Forgery“ heißt „gefälschte Anfrage“. Gelegentlich liest man auch die Abkürzung XSRF.
So funktioniert CSRF
Ein CSRF-Angriff läuft typischerweise in vier Schritten ab:
- Das Opfer ist angemeldet: Eine Person ist bei einer Webanwendung eingeloggt, etwa im Verwaltungsbereich eines Onlineshops.
- Der Köder: Der Angreifer lockt die Person auf eine präparierte Webseite, etwa über einen Link in einer E-Mail.
- Die versteckte Anfrage: Die Seite enthält unsichtbaren Code, der im Hintergrund eine Anfrage an die Webanwendung schickt – etwa „Lege einen neuen Administrator an“. Der Browser hängt das Sitzungscookie automatisch an.
- Die Ausführung: Die Webanwendung sieht eine Anfrage mit gültigem Sitzungscookie und führt sie aus. Sie kann nicht unterscheiden, ob die Person die Aktion wirklich wollte.
Die Antwort der Anwendung sieht der Angreifer dabei in der Regel nicht. Er kann also keine Daten direkt auslesen, wohl aber folgenreiche Aktionen auslösen.
CSRF wird oft mit Cross-Site Scripting (XSS) verwechselt. Bei XSS schleust der Angreifer eigenen Code in die Seiten der Webanwendung ein, der dann im Browser anderer Personen läuft. Bei CSRF bleibt die Anwendung unverändert – missbraucht wird das Vertrauen, das sie dem Browser der angemeldeten Person entgegenbringt. Eine XSS-Lücke kann allerdings CSRF-Schutzmaßnahmen aushebeln. Ebenfalls nicht zu verwechseln ist CSRF mit SSRF: Dort wird nicht der Browser, sondern ein Server zu ungewollten Anfragen gebracht.
Ein Beispiel aus der Praxis
Ein Großhändler für Sanitärbedarf betreibt ein Bestellportal für Handwerksbetriebe. Ein Mitarbeiter ist im Verwaltungsbereich angemeldet, als er in einer E-Mail auf einen Link zu einer angeblichen Preisliste eines Lieferanten klickt. Die Webseite wirkt harmlos, schickt im Hintergrund jedoch eine Anfrage an das Portal, die ein neues Administratorkonto anlegt – und weil der Mitarbeiter angemeldet ist, führt das Portal sie aus. Der Angreifer kann sich nun selbst einloggen und Preise, Kundendaten und Bestellungen manipulieren.
Die anschließende Analyse zeigt die Ursache: Die Formulare im Verwaltungsbereich enthalten keine Anti-CSRF-Token, also geheime Prüfwerte, und das Sitzungscookie ist nicht mit dem SameSite-Attribut eingeschränkt. Der Entwicklungsdienstleister aktiviert den CSRF-Schutz des Frameworks – also des Programmiergerüsts, auf dem das Portal aufbaut –, setzt das Cookie-Attribut und verlangt für das Anlegen von Administratoren künftig eine erneute Passworteingabe.
Warum ist das für Unternehmen wichtig?
CSRF betrifft vor allem Webanwendungen, in denen angemeldete Nutzende wichtige Aktionen auslösen: Webshops, Kundenportale, Onlinebanking, interne Verwaltungsoberflächen und die Weboberflächen von Routern oder Firewalls. Je höher die Rechte der getäuschten Person, desto größer der mögliche Schaden – bis hin zur Übernahme der gesamten Anwendung.
Moderne Browser und Frameworks haben die Hürden für CSRF erhöht: Einige Browser schicken Cookies ohne ausdrückliche SameSite-Angabe bei vielen seitenübergreifenden Anfragen nicht mehr mit. Verlassen sollten Sie sich darauf nicht – nicht alle Browser verhalten sich so, und schon eine ungeschützte Funktion kann genügen.
So schützen Sie sich
- Anti-CSRF-Token einsetzen: Jedes Formular erhält einen geheimen Zufallswert, den die Anwendung bei jeder Anfrage prüft. Eine fremde Webseite kennt ihn nicht und kann deshalb keine gültige Anfrage erzeugen.
- SameSite-Attribut setzen: Sitzungscookies mit der Einstellung „Strict“ oder „Lax“ schickt der Browser bei Anfragen von fremden Websites gar nicht oder nur eingeschränkt mit.
- Herkunft prüfen: Die Anwendung prüft anhand einer vom Browser mitgesendeten Herkunftsangabe (Origin-Header), woher eine Anfrage stammt, und lehnt fremde ab.
- Kritische Aktionen bestätigen lassen: Passwortänderungen, Überweisungen oder neue Administratorkonten erfordern eine erneute Passworteingabe oder einen zweiten Faktor.
- Keine Änderungen per einfachem Link: Aktionen, die Daten verändern, dürfen nie über einfache Seitenaufrufe (GET-Anfragen) auslösbar sein.
- Framework-Schutz nutzen: Viele Web-Frameworks bringen CSRF-Schutz mit. Fragen Sie Ihren Entwicklungsdienstleister, ob er überall aktiviert ist.
- Gewohnheiten anpassen: Wer mit Administratorrechten arbeitet, meldet sich nach getaner Arbeit ab und nutzt dafür am besten ein eigenes Browserprofil.
Wie Rootsektor unterstützt
In einem Penetrationstest für Webanwendungen prüfen wir unter anderem, ob sich Funktionen, die Daten oder Einstellungen verändern, per CSRF missbrauchen lassen und ob die Schutzmaßnahmen wirksam umgesetzt sind. Der Retest der behobenen Schwachstellen ist kostenlos; Ihr Festpreisangebot erhalten Sie über die Seite Pentest-Angebot.