Was ist Cross-Site-Request-Forgery?

Cross-Site-Request-Forgery (CSRF/XSRF) ist ein Angriff, bei dem ein Endbenutzer dazu gebracht wird, eine unerwünschte Aktion in einer Webanwendung auszuführen, in der er gerade angemeldet ist. Dieser Angriff funktioniert jedoch meist nur in Kombination mit einem Social-Engineering-Angriff, da das Opfer die Aktion selbst auslösen muss. Die Auswirkungen hängen von der jeweiligen Anwendung und den Rechten des angemeldeten Benutzers ab. So kann beispielsweise ein Benutzerkonto gelöscht, das Passwort oder die E-Mail-Adresse geändert oder eine Bestellung ausgelöst werden. Aus diesem Grund sollte jede Seite und jedes Formular gezielt gegen Cross-Site-Request-Forgery geschützt werden.

Wie funktioniert ein CSRF-Angriff?

Das potenzielle Opfer ist bei der Anwendung angemeldet. Nach dem Login bleibt der Nutzer für die Dauer der Sitzung eingeloggt und kann Aktionen ausführen, ohne das Passwort erneut eingeben zu müssen. Während der Nutzer angemeldet ist, besucht er eine vom Angreifer präparierte Seite. Dort führt der Nutzer eine Aktion aus, etwa durch Klicken auf einen Button. Dadurch sendet der Angreifer einen HTTP-Request an die vom Nutzer verwendete Anwendung und führt unter dessen Identität eine schädliche Aktion aus. Das funktioniert, weil die Sitzung des Nutzers bei der Webanwendung noch aktiv ist. Da das Session-Cookie weiterhin gültig ist, führt der Server die schädliche Aktion aus. Der CSRF-Angriff ist deshalb so wirkungsvoll, weil der Server nicht prüft, woher die Anfrage stammt -- ob sie von der eigenen Seite kommt oder von einer fremden Quelle.

Vorbedingungen für einen erfolgreichen CSRF-Angriff

Die Durchführung eines CSRF-Angriffs ist in der Regel sehr aufwendig, da mehrere Voraussetzungen gleichzeitig erfüllt sein müssen. Der Angreifer muss die Funktionsweise der Webanwendung kennen und unter anderem wissen, wie der gewünschte Aufruf aufgebaut ist. Darüber hinaus muss das Opfer in der Anwendung angemeldet sein und über die nötigen Rechte verfügen, den Aufruf auszuführen. Zudem muss das Opfer auf den vom Angreifer versendeten Link klicken -- und nicht zuletzt darf die Anwendung über keinen CSRF-Schutz verfügen.

Welche Auswirkungen hat ein CSRF-Angriff?

Die Auswirkungen eines CSRF-Angriffs können verheerend sein. Sie hängen jedoch von der angegriffenen Anwendung, der Art der ausgeführten Aktion und den Rechten des Opfers ab. In manchen Fällen kann der Angreifer die vollständige Kontrolle über das Benutzerkonto erlangen. Hat das kompromittierte Opfer eine privilegierte Rolle innerhalb der Anwendung, kann der Angreifer unter Umständen sämtliche Funktionen und Daten der Anwendung übernehmen. Mögliche Folgen reichen von Datendiebstahl über unbefugte Geldüberweisungen bis hin zu geänderten Passwörtern.

Beispiel eines CSRF-Angriffs -- Passwort ändern

Abbildung 1: CSRF Ablaufdiagramm

• Das Opfer meldet sich bei der Website an.
• Die Website stellt ein gültiges Sitzungstoken aus.
• Der Angreifer sendet dem Nutzer einen Payload, der zur Änderung des Passworts führt.
• Der Nutzer folgt der Aufforderung und öffnet den Payload. Darin ist eine Anfrage an die Website versteckt, die eine Passwortänderung auslöst.
• Die Website führt die Aktion im Kontext des Opfers aus. Das Passwort wurde geändert.

In den meisten Fällen ist die Auswirkung eines CSRF-Angriffs für den Benutzer nicht direkt sichtbar. Mit dem neu gesetzten Passwort und dem Benutzernamen des Opfers kann sich der Angreifer nun bei der Website anmelden. Voraussetzung für dieses Beispiel ist, dass bei einer Passwortänderung das aktuelle Passwort nicht abgefragt wird.

Wie lässt sich CSRF verhindern?

Um CSRF-Angriffe zu verhindern, muss sichergestellt werden, dass ein Angreifer keine beliebige Anfrage erstellen kann, die im Kontext eines anderen Benutzers ausgeführt wird. Dafür stehen verschiedene Methoden zur Verfügung.

Token-basierte Prävention

Wie von der OWASP beschrieben, ist die gängigste Abwehrtechnik gegen Cross-Site-Request-Forgery die Verwendung eines CSRF-Tokens. Dabei handelt es sich um unvorhersehbare, eindeutige Werte, die von der Anwendung generiert und an den Client gesendet werden. Bei jeder Anfrage schickt der Client das Token an den Server zurück, der es verifiziert.

Auf diese Weise wird ein Element eingeführt, das der Angreifer nicht kennt und das den CSRF-Angriff wirksam entschärft. Jede Anfrage, die nicht aus dem ursprünglichen Formular stammt, kann verworfen werden, da sie nicht den korrekten Token-Wert enthält.

Dennoch können auch bei der Verwendung von CSRF-Token durch Implementierungsfehler Schwachstellen entstehen. Für einen wirksamen Schutz müssen CSRF-Token korrekt umgesetzt werden. Moderne Frameworks bringen einen tokenbasierten CSRF-Schutz in der Regel bereits mit oder ermöglichen dessen einfache Integration.

Double-Submit Cookie

Wenn eine serverseitige Token-Validierung nicht möglich ist, bietet die Double-Submit-Cookie-Technik eine Alternative. Sie ist einfach zu implementieren und zustandslos. Dabei wird ein Zufallswert sowohl in einem Cookie als auch als Anfrageparameter gesendet. Der Server prüft anschließend, ob beide Werte übereinstimmen. Beim ersten Besuch der Website wird ein kryptografisch starker Zufallswert erzeugt und als Cookie auf dem Rechner des Nutzers gespeichert -- getrennt von der Sitzungskennung. Die Website verlangt dann, dass jede Transaktionsanfrage diesen Wert als verstecktes Formularfeld enthält. Stimmen beide Werte serverseitig überein, akzeptiert der Server die Anfrage als legitim; andernfalls wird sie abgelehnt.

Same-Site Cookie

Das Same-Site-Cookie ist ein Attribut, das CSRF-Angriffe verhindern soll. Es steuert, ob der Browser Cookies zusammen mit einer Anfrage sendet. Mögliche Werte sind Lax, Strict oder None.

• None -- Cookies werden immer gesendet, unabhängig vom Kontext. Dies funktioniert nur bei Cookies mit dem Flag „secure”.

• Lax -- Der Browser unterbindet das Senden des Cookies nur bei „unsicheren” Anfragen (POST), erlaubt es jedoch bei „sicheren” Anfragen (GET).

• Strict -- Cookies werden bei seitenübergreifenden Anfragen grundsätzlich nicht gesendet.

Wichtig: Dieses Attribut ist kein Ersatz für ein CSRF-Token. Vielmehr sollte es gemeinsam mit dem Token eingesetzt werden, um einen robusteren Schutz zu gewährleisten.

Fazit

Obwohl die CSRF-Schwachstelle seit Langem bekannt ist und viele Frameworks sie bereits standardmäßig abfangen, tritt sie in der Praxis nach wie vor häufig auf -- oft mit gravierenden Folgen. Mit den oben beschriebenen Methoden lässt sich die Sicherheit Ihrer Webanwendung jedoch deutlich erhöhen.