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 „cross-site“ oder „cross-origin“, 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.
Bei einer CSRF wird eine HTTP Anfrage gesendet, 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.
Stufe des CSRF Security Assessments
CVSS Vector: AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N
Wie wird ein XSRF Angriff durchgeführt?
Ein Angreifer verschafft sich bei einer XSRF Zugriff auf den Browser eines Opfers. Das erfolgt normalerweise ü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.
Es müssen mehrere Bedingungen erfüllt sein, damit eine CSRF eine sinnvolle Wirkung hat:
- 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.
Der Angriff kann alternativ auch so 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 request exploits 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.
Weitere XSRF Requests
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. Damit eine solche Anfrage zugelassen werden kann, muss eine manuelle Aufhebung dieser Beschränkungen auf einer Website erfolgen. Dadurch können Anfragen mit unterschiedlicher Herkunft empfangen werden.
Ein XSRF Angriff 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.
Welche Auswirkungen hat ein CSRF Angriff?
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, denn Anfragen können nur mit XSRF versendet, aber nicht empfangen werden. Mit diesem Angriff wird das Vertrauen ausgenutzt, das Benutzern seitens einer Anwendung oder einer Website entgegebracht wird.
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.
Leitfaden
CSRF-Angriffe Präventionsguide
Erfahren Sie, wie Sie eine Cross-Site Request Forgery – eine der am weitesten verbreiteten Sicherheitslücken – erkennen und verhindern können.
(Der Leitfaden ist derzeit nur auf Englisch verfügbar.)
Wie man Cross-Site Request Forgery Angriffe verhindert
Sie müssen sicherstellen, dass ein Angreifer keine beliebige Anfrage erstellen kann, die im Sicherheitskontext eines anderen Benutzers ausgeführt und von einer anderen Website gesendet wird, um CSRF injection attacks zu verhindern. Dies ist eine der wichtigsten Bedingungen, die erfüllt sein müssen, damit ein XSRF 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 Cross-Site Request Forgery Angriff öffnen können. Als Schutzmaßnahme gegen solche Angriffe, müssen CSRF Token, gemeinsam 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.
Same-site Cookie Vorbeugung
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.
Häufig gestellte Fragen zur CSRF/XSRF
F: Was ist CSRF?
A: Diese Art von Angriff, auch bekannt als CSRF oder XSRF, Cross-Site Reference Forgery, Hostile Linking usw., ermöglicht es einem Angreifer, Aktionen (Anfragen) innerhalb einer Anwendung auszuführen, in der ein Benutzer gerade angemeldet ist. Er ist „seitenübergreifend“ oder „herkunftsübergreifend“, weil er verschiedene Websites oder Elemente verwendet, um sich einzumischen, d. h. um Anfragen innerhalb einer Anwendung zu senden, die von außerhalb der Anwendung stammen.
F: Was sind die Auswirkungen eines XSRF Angriffs?
A: Die Auswirkungen eines CSRF Angriffs hängen von dem anvisierten Benutzer und seinen Berechtigungen innerhalb einer Anwendung ab. Für den durchschnittlichen Benutzer führt ein erfolgreicher CSRF Angriff in der Regel zu statusändernden Anfragen, z. B. zur Änderung des Kennworts oder der E-Mail-Adresse, zur Überweisung von Geldbeträgen auf ein anderes Konto oder zu Einkäufen mit seinen Anmeldedaten.
