Was ist Cross-Site-Request-Forgery?

Cross-Site-Request-Forgery (CSRF/XSRF) ist ein Angriff, bei dem ein Endbenutzer dazu gezwungen wird, eine unerwünschte Aktion in einer Webanwendung auszuführen, bei der er gerade angemeldet ist. Dieser Angriff funktioniert jedoch meist nur in Kombination mit einem Social-Engineering-Angriff, da das Opfer die Aktion bewusst ausführen muss. Die Auswirkungen dieses Angriffes sind abhängig von der dahinterliegenden Anwendung und der Rechte des angemeldeten Benutzers. So kann z.B. ein Benutzerkonto gelöscht werden, das Passwort oder die E-Mail-Adresse verändert werden oder aber auch Bestellungen getätigt werden. Deswegen sollte jede Seite und jedes Formular entsprechend gegen Cross-Site-Request-Forgery geschützt werden.

Wie funktioniert ein CSRF-Angriff?

Das potenzielle Opfer ist bei der Applikation angemeldet. Nach dem Log-in bleibt der Nutzer für die Dauer der Session angemeldet und kann Aktionen ausführen, ohne das Passwort erneut eingeben zu müssen. Während der Nutzer angemeldet ist, besucht er eine vom Angreifer erstellte Seite. Dort wird vom Nutzer eine Aktion ausgeführt, z.B. durch Drücken eines Buttons. Der Angreifer sendet infolgedessen einen HTTP-Request an die vom User genutzte Applikation und führt unter der Identität des Nutzers eine schädliche Aktion aus. Dies funktioniert, da die Session, die der Nutzer bei der Webanwendung hat, noch aktiv ist. Dadurch, dass das Session-Cookie valide ist, führt der Server die schädliche Aktion durch. Der CSRF Angriff ist deshalb so erfolgreich, weil nicht überprüft wird, woher die Anfrage kommt. Es ist nicht bekannt, ob der HTTP-Request durch die eigene Seite kommt oder von einer fremden Quelle stammt.

Vorbedingungen für einen erfolgreichen CSRF Angriff

Einen CSRF Angriff durchzuführen, ist für gewöhnlich sehr aufwendig, da mehrere Voraussetzungen erfüllt sein müssen. Der Angreifer muss wissen wie die Webanwendung funktioniert und muss auch unter anderem Wissen wie der entsprechende Aufruf der durchgeführt werden soll aufgebaut ist. Des Weiteren muss das Opfer in der Applikation angemeldet sein und über die entsprechenden Rechte verfügen, den Aufruf auszuführen. Das Opfer muss auf den vom Angreifer gesendeten Link klicken und zu guter Letzt darf die Anwendung nicht über einen CSRF Schutz verfügen.

Was ist die Auswirkung eines Angriffes?

Die Auswirkungen eines CSRF Angriff können katastrophal sein, dies ist jedoch abhängig von der Anwendung, die angegriffen werden soll, der Art der Aktion, die ausgeführt wird und über die Rechte, die das Opfer in der Anwendung hat. In einigen Fällen kann der Angreifer, die vollständige Kontrolle über das Benutzerkonto erlangen. Wenn der kompromittierte Benutzer eine privilegierte Rolle innerhalb der Anwendung innehat, kann der Angreifer möglicherweise die vollständige Kontrolle über alle Funktionen und Daten der Anwendung übernehmen. Die Folgen können Datendiebstahl, unbefugte Geldüberweisungen, geänderte Kennwörter und vieles mehr sein.

Beispiel eines CSRF Angriffes – Passwort ändern

Abbildung 1: CSRF Ablaufdiagramm

• Das Opfer meldet sich bei der Website an.
• Die Website stellt einen validen Sitzungstoken aus.
• Der Angreifer sendet dem Nutzer den Payload, der zur Änderung des Passwortes führt.
• Der Benutzer kommt der Aufforderung nach und öffnet den Payload. Im Payload ist eine Anfrage an die Website versteckt, welche zu einer Änderung des Passwortes führt.
• Die Aktion wird von der Website im Kontext des Opfers durchgeführt. Das Passwort für den Benutzer wurde geändert.

In den meisten Fällen ist die Auswirkung eines CSRF Angriffes nicht direkt sichtbar für den Benutzer. Mit dem neu gesetzten Passwort und dem Benutzernamen des Opfers ist der Angreifer nun in der Lage, sich bei der Website anzumelden. Die Vorbedingung für dieses Beispiel ist, dass bei einer Änderung des Passwortes das aktuelle Passwort nicht abgefragt wird.

Wie verhindere ich CSRF?

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. Dies kann auf mehrere Arten umgesetzt werden.

Token-basierte Prävention

Wie auch schon von der OWASP beschrieben, ist die gängigste Abwehrtechnik für Cross-Site-Request-Forgery-Angriffe die Verwendung eines CSRF-Tokens. Diese Sitzungstoken sind unvorhersehbare und eindeutige Werte, die von der Anwendung generiert und an den Client gesendet werden. Danach werden sie in der Anfrage des Clients an den Server zurückgeschickt, der die Anfrage verifiziert.

Dadurch wird ein unbekanntes Element eingeführt, das den CSRF-Angriff wirksam entschärfen kann. Jede Anfrage, die nicht aus dem ursprünglichen Formular stammt, kann einfach verworfen werden, da sie nicht den richtigen Wert für das CSRF-Token enthält.

Dennoch können auch bei der Verwendung von CSRF-Token aufgrund von Fehlern in der Umsetzung einige Schwachstellen auftreten. Um sich gegen einen solchen Angriff zu schützen, müssen CSRF-Token korrekt implementiert werden. Bei der Verwendung moderner Frameworks ist ein auf Token basierender CSRF-Schutz in der Regel bereits enthalten oder kann leicht hinzugefügt werden.

Double-Submit Cookie

Wenn die Verwendung eines gültigen Tokens auf der Serverseite nicht möglich ist, besteht eine alternative Möglichkeit in der Verwendung der Double Submit Cookie-Technik. Diese Technik ist einfach zu implementieren und zudem zustandslos. Hierbei wird ein Zufallswert sowohl in einem Cookie als auch als Anforderungsparameter gesendet, wobei der Server prüft, ob der Cookie-Wert und der Anforderungswert übereinstimmen. Wenn ein Benutzer zum ersten Mal die Website besucht, sollte die Website einen kryptografisch starken Zufallswert generieren und ihn als Cookie auf dem Computer des Benutzers speichern. Dieser Cookie soll getrennt von der Sitzungskennung gespeichert werden. Die Website verlangt dann, dass jede Transaktionsanforderung diesen Pseudozufallswert als versteckten Formularwert enthält. Wenn beide Werte auf der Serverseite übereinstimmen, akzeptiert der Server die Anfrage als legitim, wenn nicht, wird sie abgelehnt.

Same-Site Cookie

Das Same-Site-Cookie ist ein Attribut, mit dem CSRF Angriffe verhindert werden sollen. Dieses Attribut hilft dem Browser bei der Entscheidung, ob Cookies zusammen mit einer Anfrage gesendet werden sollen. Mögliche Werte für dieses Attribut sind Lax, Strict oder None.

None – Die Cookies werden immer gesendet, unabhängig vom Kontext. Dies funktioniert nur für Cookies mit dem Flag „secure“.

Lax – Bei einer laxen Einstellung verhindert der Browser das Senden des Cookies nur bei „unsicheren“ Anfragen (POST), erlaubt aber „sichere“ Anfragen (GET).

Strict – Bei der Einstellung Strict, werden Cookies bei seitenübergreifenden Anfragen niemals gesendet.

Es ist wichtig zu beachten, dass die Verwendung dieses Attributes einen CSRF-Token nicht ersetzen soll. Stattdessen sollte es mit diesem Token koexistieren, um den Benutzer auf eine robustere Weise zu schützen.

Fazit

Obwohl die CSRF Schwachstelle an sich schon lange bekannt ist und die Auswirkungen von vielen Frameworks bereits standardmäßig mitigiert werden, ist die Schwachstelle noch häufig in der freien Wildbahn zu finden. Dies auch meist mit katastrophalen Auswirkungen. Jedoch kann mit einigen der oben aufgeführten Methoden die Sicherheit Ihrer Webanwendung, einfach, um ein Vielfaches erhöht werden.