CSRF: Aktionen, die ohne Ihr Wissen ausgelöst werden

Der Angreifer sucht zunächst eine Anfrage, die bei einem Dienst etwas verändert, und baut dann eine Adresse oder ein Skript, das sie mit eigenen Werten nachbildet. OWASP nennt das Beispiel einer fiktiven Bank: Die legitime Anfrage überweist 100 Dollar an einen Begünstigten, und der Angreifer setzt sich selbst als Begünstigten ein und erhöht den Betrag¹.

Nun muss das Opfer diese Anfrage laden, während es angemeldet ist. Genannt werden zwei Wege: eine unerwünschte E-Mail mit HTML-Inhalt oder eine Falle auf Seiten, die das Opfer wahrscheinlich besucht, während es seinen Online-Dienst nutzt¹.

Der Angriff kann auch auf der verwundbaren Website selbst gespeichert werden, zum Beispiel in einem Feld, das HTML akzeptiert. Er wird dadurch wahrscheinlicher: Das Opfer ruft eher eine Seite dieser Website auf als eine beliebige Seite im Internet, und es ist dort zwangsläufig bereits angemeldet¹.

Oft nichts. Der präparierte Link kann als gewöhnlicher Link getarnt sein, mit einem Text wie „Meine Fotos ansehen“. Er kann auch die Form eines falschen Bildes mit der Größe null haben: Steht es in einer E-Mail, sieht das Opfer nichts, aber der Browser sendet die Anfrage trotzdem, ohne jedes sichtbare Zeichen, dass der Vorgang stattgefunden hat¹.

Neutralisierte Illustration, keine echte Adresse.
Getarnter Link: angezeigter Text „Voir mes photos“, versteckte Adresse
hxxp://banque[.]exemple[.]invalid/virement?dest=[Konto des Angreifers]&montant=[hoch]
Variante: unsichtbares Bild in einer E-Mail, ohne Klick geladen.

Erwartet der Dienst eine POST-Anfrage, kann der Angreifer auf seiner Website ein Formular mit versteckten Feldern bereitstellen. Das Opfer hält es für etwas anderes und klickt, oder ein Skript sendet es beim Laden der Seite automatisch ab¹. In beiden Fällen ist die angezeigte Seite harmlos, und die Aktion läuft woanders ab.

Der Mechanismus beruht auf einem normalen Verhalten der Browser. Sie speichern die Cookies, die eine Anwendung ausstellt, darunter die Sitzungscookies angemeldeter Benutzer, und sie senden bei jeder Anfrage alle Cookies einer Domain mit, gleichgültig, wie diese Anfrage im Browser entstanden ist². Cookies sind nicht der einzige Auslöser: Auch die Authentifizierung per Basic und Digest ist anfällig, weil der Browser die Zugangsdaten bis zum Ende der Sitzung automatisch erneut sendet².

Mehrere Verteidigungsideen funktionieren laut OWASP nicht¹:

• ein geheimes Cookie, da bei jeder Anfrage alle Cookies mitgesendet werden;
• nur POST-Anfragen zu akzeptieren, da ein verstecktes Formular genügt, um eine zu fälschen;
• Transaktionen in mehreren Schritten, solange der Angreifer jeden Schritt vorhersehen kann;
• die alleinige Prüfung des Referer-Headers, da er gefälscht werden kann und aus Datenschutzgründen manchmal fehlt.

Die empfohlenen Schutzmaßnahmen auf Seiten der Anwendung sind die folgenden.

• Zuerst prüfen, ob das Framework bereits einen CSRF-Schutz bietet, und diesen nutzen. Andernfalls allen Anfragen, die den Zustand ändern, Anti-CSRF-Token hinzufügen und sie serverseitig validieren³. Ohne Token kann der Angreifer keine gültige Anfrage bauen³.
• Bei Software ohne Zustand ein Double-Submit-Cookie verwenden, vorzugsweise signiert³.
• Das Attribut SameSite für Sitzungscookies setzen³. Beim Wert strict sendet der Browser das Cookie nicht bei websiteübergreifenden Anfragen, auch nicht, wenn man einem gewöhnlichen Link folgt. Bei lax sendet er es für einen Link, dem man von einer anderen Website aus folgt, hält es aber bei Methoden zurück, die für CSRF anfällig sind, wie POST⁴. Bei none bietet das Attribut keinen Schutz⁴.
• Den Ursprung mit Standard-Headern prüfen, insbesondere Sec-Fetch-Site, das seit März 2023 von allen großen Browsern unterstützt wird³.
• Keine GET-Anfragen für Vorgänge verwenden, die den Zustand ändern³.

Diese Maßnahmen haben Grenzen. SameSite=Lax lässt GET-Anfragen der Navigation auf oberster Ebene durch: Ein Endpunkt, der den Zustand per GET ändert, bleibt verwundbar². Ältere Browser wenden SameSite möglicherweise nicht an². Und eine XSS-Schwachstelle kann alle Anti-CSRF-Schutzmaßnahmen umgehen; der Samy-Wurm etwa nutzte einen XMLHttpRequest, um das CSRF-Token zu erhalten und Anfragen zu fälschen¹³. Das Standardverhalten von SameSite ist uneinheitlich: Im Dezember 2024 war lax der Standardwert in Chrome, Edge und Opera, aber in keiner Version von Firefox oder Safari, weshalb empfohlen wird, den Wert ausdrücklich zu setzen⁴.

2008: der uTorrent-Exploit

OWASP nennt als reales Beispiel für einen CSRF-Angriff auf eine Anwendung, die über GET-Anfragen arbeitet, einen Exploit gegen uTorrent aus dem Jahr 2008. Er wurde in großem Umfang genutzt, um Schadsoftware herunterzuladen¹. Mehr sagt die Quelle nicht: weder die Zahl der Opfer noch den Verbreitungsweg.

In der CWE katalogisierte Schwachstellen (Kennungen von 2004 bis 2009)

CWE-352 enthält eine Auswahl beobachteter Beispiele, die nicht vollständig ist⁵. Mehrere beruhen auf einer einfachen URL in einem img-Tag: CVE-2004-1703 und CVE-2004-1995 erlauben das Hinzufügen von Benutzerkonten, CVE-2004-1842 das Erlangen von Administratorrechten⁵. Andere betreffen die Verwaltung selbst: CVE-2009-3520 erlaubt es, das Passwort des Administrators zu ändern, und CVE-2009-3759, über eine Weboberfläche Passwörter zu ändern oder eine virtuelle Maschine herunterzufahren⁵.