Cross-Site Request Forgery (CSRF) ermöglicht es einem Angreifer, Aktionen (Anfragen) innerhalb einer Anwendung auszuführen, in der ein Benutzer gerade angemeldet ist. Sie ist „seitenübergreifend“ oder „herkunftsübergreifend“, weil sie verschiedene Websites oder Elemente verwendet, um sich einzumischen, d. h., um Anfragen innerhalb einer Anwendung zu senden, die von außerhalb der Anwendung stammen.

Diese Art von Angriff ist unter anderem als CSRF oder XSRF, Cross-Site Reference Forgery, Hostile Linking etc. bekannt.

Ein CSRF sendet eine HTTP-Anfrage, wenn ein Benutzer eine Website öffnet, die bösartigen Code enthält, um sein Ziel zu erreichen. Der Code ist so eingebettet, dass keine weiteren Aktionen des Benutzers erforderlich sind. 

Diese Art von Angriff wird häufig in Spam-E-Mails verwendet. Durch Anklicken einer bösartigen URL startet der Angriff ohne das Wissen des Benutzers und fälscht Aktionen. Die ohne das Wissen des Benutzers gesendeten HTTP-Anfragen können auf sensible Daten zugreifen, diese ändern oder löschen.

CSRF-Angriffe erfolgen zwar hauptsächlich über den Browser des Benutzers, können aber effektiv über jede Datei ausgeführt werden, die Skripting zulässt, z. B. Word- und XML-Dokumente, RSS-Feeds usw. 

Table of contents
  1. CSRF-Sicherheitsbwertungsstufe
  2. Wie funktioniert ein CSRF-Angriff?
  3. Was sind die Auswirkungen eines CSRF-Angriffs?
  4. Sind Cross-Site Request Forgery und Cross-Site Scripting dasselbe?
  5. Wie man Cross-Site Request Forgery Angriffe verhindert

CSRF-Sicherheitsbwertungsstufe

Cross-Site Request Forgery (CSRF) Security Assessment

CVSS Vector: AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N

Wie funktioniert ein CSRF-Angriff?

Bei einer CSRF verschafft sich ein Angreifer Zugriff auf den Browser eines Opfers – in der Regel über einen bösartigen Link. Dieser Zugang wird dann genutzt, um eine böswillige Anfrage an eine beliebige Anwendung mit einer aktiven Sitzung zu stellen, bei der der Benutzer authentifiziert ist. 

Da der Angreifer Zugriff auf den Browser hat, werden die von ihm gesendeten Anfragen von den Anwendungen als legitim angesehen, da sie zusammen mit dem Sitzungs-Cookie gesendet werden, das die Anfrage ermöglicht. 

Damit eine CSRF eine Wirkung hat und sinnvoll ist, müssen mehrere Bedingungen erfüllt sein:

  • Es muss eine Aktion geben, die der Angreifer im Namen des Opfers ausführen will und die dem Angreifer einen gewissen Nutzen bringt (z. B. Zugriff auf das Passwort des Opfers und Änderung desselben)
  • Die Anwendung muss Sitzungscookies verwenden, um die vom Benutzer gestellte Anfrage zu authentifizieren.
  • Der Angreifer kennt die Parameter der Anfragen, die er durchführen will.

Eine Cross-Site Request Forgery wird in der Regel auf eine der unten beschriebenen Arten ausgeführt.

GET Requests

Einige Anwendungen verwenden HTTP-GET-Anfragen, um Zustandsänderungen vorzunehmen, wie z. B. die Änderung eines Passworts. In diesem Fall sendet ein Angreifer einen bösartigen Link (der einen normalen Link imitiert). Wenn ein Benutzer den Link aufruft, wird ein Skript ausgeführt, das den Browser dazu veranlasst, die Anfrage auszuführen. 

Alternativ kann der Angriff auch ausgeführt werden, indem die Opfer auf eine Seite geschickt werden, die die Adresse über ein HTML-Element, wie z. B. ein Bild, lädt.

In beiden Fällen wird die GET-Anfrage des Browsers im Hintergrund ausgeführt, um das gewünschte Ergebnis zu erzielen, ohne dass der Benutzer davon erfährt. Daher sind CSRF-GET-Anfragen relativ trivial, treten aber dennoch als Sicherheitslücken in verschiedenen Anwendungen auf.

POST Requests

Der Hauptunterschied zwischen der Verwendung einer GET- und einer POST-Anfrage für eine CSRF besteht darin, wie die Anfrage übermittelt wird. Der Grund, warum Angreifer HTTP POST verwenden, ist, dass statusändernde Anfragen in Anwendungen häufig auf diese Weise gestellt werden. 

Im Gegensatz zu GET, wo der Angriff über eine URL erfolgt, die die Anfrage enthält, sendet der Browser des Opfers bei einer POST-Anfrage die gewünschten Werte über den request body. Diese werden in der Regel in Form eines Query-Strings kodiert.

Ein Angreifer kann das <form>-Element verwenden, um diese Anfrage zu übermitteln, so dass der Benutzer die Anfrage manuell übermitteln muss. Dies kann erreicht werden, indem das Opfer dazu verleitet wird, auf eine Schaltfläche auf der bösartigen Website zu klicken, zu der es geleitet wird. Alternativ kann der Angreifer auch JavaScript in die Website einbetten, das die 

Das gleiche Ergebnis kann auch mit einem iFrame erzielt werden, der vom Angreifer als verstecktes Feld eingebettet wird. Ähnlich wie bei JavaScript kann der iFrame so erstellt werden, dass er die Anfrage sendet, sobald er auf der Website geladen ist.

Andere CSRF-Anfragen

Eine weitere Möglichkeit, eine CSRF erfolgreich durchzuführen, ist die Verwendung verschiedener HTTP-Elemente wie PUT oder DELETE. Diese können als Teil einer JSON- oder XML-Zeichenkette übermittelt werden, werden aber von modernen Browsern aufgrund der SOP-Beschränkungen (Same-Origin Policy) und CORS (Cross-Origin Resource Sharing) standardmäßig verhindert. Um eine solche Anfrage zuzulassen, müssen diese Beschränkungen auf einer Website manuell aufgehoben werden, so dass Anfragen mit unterschiedlicher Herkunft empfangen werden können. 

Ein CSRF kann auch als Teil eines Cross-Site-Scripting-Angriffs (XSS) ausgeführt werden. In diesem Fall ist die CSRF Teil der Payload, die an den XSS angehängt ist, wie bei dem berühmten Samy worm, der in MySpace verwendet wurde. 

Cross-Site Request Forgery CSRF in a graph

Was sind die Auswirkungen eines CSRF-Angriffs?

Die Auswirkungen eines CSRF-Angriffs hängen von dem betroffenen Benutzer und seinen Berechtigungen innerhalb einer Anwendung ab. 

Bei einem durchschnittlichen Benutzer führt ein erfolgreicher CSRF-Angriff in der Regel zu Anfragen, die den Status ändern, wie z. B. die Änderung des Passworts oder der E-Mail-Adresse, die Überweisung von Geldbeträgen auf ein anderes Konto oder die Durchführung von Einkäufen mit den Anmeldedaten des Benutzers. 

Wenn ein Benutzer mit höheren Privilegien, z. B. ein Administratorkonto, erfolgreich angegriffen wird, kann ein CSRF-Angriff zu einer vollständigen Systemkompromittierung führen. Dies liegt daran, dass ein solches Konto Anfragen für eine andere Bestellung einreichen kann. 

Sind Cross-Site Request Forgery und Cross-Site Scripting dasselbe?

Nein, CSRF und XSS sind unterschiedliche Arten von Angriffen, obwohl sie gemeinsam eingesetzt werden können. Bei beiden handelt es sich um häufige JavaScript-Schwachstellen.

Damit CSRF funktioniert, muss der Benutzer derzeit in einer Anwendung authentifiziert sein, über die der Angreifer dann eine Anfrage senden kann. Es handelt sich um einen „Einweg“-Angriff, da Anfragen mit CSRF nur versendet, aber nicht empfangen werden können. Dieser Angriff nutzt das Vertrauen aus, das eine Anwendung oder eine Website dem Benutzer entgegenbringt.

Im Gegensatz dazu erfordert XSS keine Authentifizierung, sondern nur, dass der Benutzer eine bestimmte Website besucht, auf der das XSS-Skript dann im Browser des Benutzers ausgeführt wird. Da Anfragen sowohl gesendet als auch empfangen werden können, handelt es sich um einen „Zwei-Wege“-Angriff oder -Sicherheitslücke. Dieser Angriff nutzt das Vertrauen aus, das ein Benutzer in die Website hat.

Erkennen Sie CSRF Schwachstellen in Ihren Webanwendungen

JETZT KOSTENLOS TESTEN

Wie man Cross-Site Request Forgery Angriffe verhindert

Um CSRF injection attacks zu verhindern, müssen Sie sicherstellen, dass ein Angreifer keine beliebige Anfrage erstellen kann, die im Sicherheitskontext eines anderen Benutzers ausgeführt und von einer anderen Website gesendet wird. Dies ist eine der wichtigsten Bedingungen, die erfüllt sein müssen, damit ein CSRF-Angriff erfolgreich sein kann. Die Unterbrechung dieser Bedingung verhindert die Möglichkeit eines solchen Angriffs. 

Tokenbasierte Prävention

Wie im OWASP Cross-Site Request Forgery Prevention Cheat Sheet beschrieben, ist die gängigste Abwehrtechnik für Cross-Site Request Forgery-Angriffe die Verwendung eines CSRF-Tokens (auch bekannt als Synchronizer-Token oder Anti-CSRF-Token). Diese Sitzungs-Tokens sind unvorhersehbare und eindeutige Werte, die von der Anwendung generiert und an den Client gesendet werden. Anschließend werden sie in der Anfrage des Clients an den Server zurückgeschickt, der die Anfrage überprüft. 

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, enthält nicht den richtigen Wert für das CSRF-Token und kann leicht verworfen werden. 

Häufige CSRF-Token-Schwachstellen

Dennoch können bei der Verwendung von CSRF-Tokens aufgrund von Lücken im Verfahren einige Schwachstellen auftreten. Zu den häufigsten Schwachstellen bei CSRF-Tokens gehören:

  • Token werden nur bei POST-Anfragen validiert und verwendet, nicht aber bei GET-Anfragen
  • Die Validierung erfolgt nur, wenn das Sitzungs-Token vorhanden ist, und wenn es weggelassen wird, wird auch die Validierung übersprungen
  • Token sind nicht an die aktuelle Benutzersitzung gebunden, sondern werden mit Token verglichen, die zu einem beliebigen Zeitpunkt von der Anwendung ausgegeben wurden.
  • Token sind mit einem Cookie verknüpft, aber nicht mit einem, das zur Verfolgung der aktuellen Sitzung verwendet wird.
  • Anwendungen führen keine Aufzeichnungen über Token – stattdessen ist das Token im Cookie enthalten, und die Anwendung prüft, ob das Token in der Anfrage mit dem im Cookie übereinstimmt

Alle oben genannten Punkte stellen Schwachstellen dar, die die Tür für einen CSRF-Angriff öffnen können. Um sich gegen einen solchen Angriff zu schützen, müssen CSRF-Tokens, zusammen mit verschiedenen anderen Abwehrtechniken, korrekt implementiert werden.

Bei der Verwendung moderner Frameworks ist ein auf Token basierender CSRF-Schutz in der Regel bereits enthalten oder kann leicht zu Formularen hinzugefügt und von der entsprechenden Middleware validiert werden. Bei einseitigen Anwendungen kann das CSRF-Token auch über ein Meta-Tag bereitgestellt werden, das dann aus dem JavaScript im Browser ausgelesen und bei jeder Anfrage geändert wird. 

Verhinderung der doppelten Übermittlung von Cookies

Wenn die Verwendung eines gültigen Tokens auf der Serverseite nicht möglich ist, kann ein Ansatz zur doppelten Übermittlung von Cookie-Token verwendet werden. Bei dieser Cookie-basierten Sitzungsbehandlung erzeugt die Seite, wenn ein Benutzer eine Website besucht, einen Wert, der als Cookie auf dem Gerät des Benutzers gespeichert wird, abgesehen von dem Cookie, das als Sitzungskennzeichen dient. 

Wenn eine rechtmäßige Anfrage an die Website gestellt wird, muss sie denselben Wert enthalten, der im Cookie enthalten ist. Der Server überprüft dies, und wenn die Werte übereinstimmen, wird der Anfrageparameter akzeptiert. 

Wie von OWASP empfohlen, sollte dieser Ansatz zusammen mit einer CSRF-Token-Strategie und nicht als Ersatz verwendet werden. 

Der Same-Site-Cookie-Ansatz schränkt den Ursprung ein, von dem ein Cookie gesendet werden kann. Auf diese Weise nutzt Cross-Site Request Forgery die Möglichkeit aus, eine herkunftsübergreifende Anfrage (und damit seitengleiche Cookies) zu stellen. Durch die Einschränkung, dass Anfragen nur von dem Ursprung aus gesendet werden können, mit dem ein Cookie verknüpft ist, wird die Möglichkeit, externe Anfragen an eine Anwendung zu senden, effektiv verhindert. 

Custom Request Header

Eine Technik, die sich besonders für AJAX- oder API-Endpunkte eignet, ist die Verwendung von benutzerdefinierten Anfrage-Headern. Bei diesem Ansatz wird JavaScript verwendet, um eine benutzerdefinierte Kopfzeile hinzuzufügen. Leider kann JavaScript aufgrund der SOP-Sicherheitseinschränkungen keine herkunftsübergreifenden Anfragen mit einem benutzerdefinierten Header stellen.

Dadurch wird das Senden einer domainübergreifenden Anforderung mit benutzerdefinierten Headern verhindert, wodurch die Möglichkeit eines CSRF-Angriffs ausgeschlossen wird.

Django

In Django ist es ähnlich einfach, jedes Formular mit einem CSRF-Token zu schützen, indem man das Snippet innerhalb der <form></form>-Tags verwendet. 

Um das Token für die Verwendung mit JavaScript-Anfragen bereitzustellen, rufen Sie es aus seinem Speicher-Cookie ab und fügen es der Anfrage hinzu.

var csrftoken = Cookies.get('csrftoken');
...
xhr.setRequestHeader("X-CSRFToken", csrftoken);

Ausführlichere Beispiele finden Sie in der Django-Dokumentation.

Laravel

Um Formulare in Laravel zu schützen, fügen Sie den folgenden Code in die <form></form>-Tags ein. 

Für JavaScript-Anfragen konfiguriert die Datei resources/assets/js/bootstrap.js automatisch das csrf-token-Meta-Tag, das von der Axios HTTP-Bibliothek verwendet wird. Wenn Sie diese Bibliothek nicht verwenden, finden Sie weitere Informationen in der Laravel-Dokumentation