Was ist Cross-Site Request Forgery?

Ein Cross-Site-Request-Forgery-Angriff verleitet ein Opfer dazu, seine Anmeldedaten zu verwenden, um eine zustandsändernde Aktivität aufzurufen.

Lernziele

Nach Lektüre dieses Artikels können Sie Folgendes:

  • Cross-Site Request Forgery (CSRF) definieren
  • Sie können erklären, wie ein CSRF-Angriff funktioniert
  • Möglichkeiten zur Bekämpfung von CSRF-Angriffen erkunden

Ähnliche Inhalte


Möchten Sie noch mehr erfahren?

Abonnieren Sie theNET, Cloudflares monatliche Zusammenfassung der beliebtesten Einblicke in das Internet!

Lesen Sie die Cloudflare Datenschutzrichtlinie, um zu erfahren, wie wir Ihre persönlichen Daten sammeln und verarbeiten.

Link zum Artikel kopieren

Was ist Cross-Site Request Forgery (CSRF)?

Ein Cross-Site-Request-Forgery-Angriff ist eine Art Confused Deputy* Cyberangriff, der einen Nutzer dazu verleitet, versehentlich seine Anmeldedaten zu verwenden, um eine Aktivität auszulösen, die den Status verändert, z. B. eine Überweisung von seinem Konto, die Änderung seiner E-Mail-Adresse und seines Passworts oder eine andere unerwünschte Aktion.

Während die potenziellen Auswirkungen auf einen normalen Nutzer beträchtlich sind, kann ein erfolgreicher CSRF-Angriff auf ein Administratorkonto einen ganzen Server kompromittieren und möglicherweise zu einer vollständigen Übernahme einer Webanwendung, einer API oder eines anderen Dienstes führen.

Wie funktioniert Cross-Site Request Forgery?

Dieser Angriff konzentriert sich auf zustandsändernde Anfragen, d. h. Anfragen, die dazu führen, dass Daten von einem Wert in einen anderen geändert werden. Eine gezielte Anfrage könnte zum Beispiel einen Kauf tätigen oder einen Wert in einem Konto ändern. Interessanterweise handelt es sich hierbei um einen „blinden Angriff“, bei dem keine Daten an den Angreifer zurückgegeben werden, was ihn zu einer schlechten Wahl für Datendiebstahl macht.

Hier ist ein Beispiel für die 4 Schritte eines Cross-Site Request Forgery-Angriffs:

  1. Ein Angreifer erstellt eine gefälschte Anfrage, die, wenn sie ausgeführt wird, 10.000 $ von einer bestimmten Bank auf das Konto des Angreifers überweist.
  2. Der Angreifer bettet die gefälschte Anfrage in einen Hyperlink ein und verschickt ihn in Massen-E-Mails und bettet ihn auch in Websites ein.
  3. Ein Opfer klickt auf eine vom Angreifer platzierte E-Mail oder einen Link auf der Website, was dazu führt, dass das Opfer die Bank auffordert, 10.000 $ zu überweisen.
  4. Der Bankserver empfängt die Anfrage, und da das Opfer ordnungsgemäß autorisiert ist, behandelt er die Anfrage als legitim und überweist das Geld.
Eine gefälschte Anfrage

CSRF-Angriffe unterscheiden sich in ihrer Methodik, weisen aber typischerweise die folgenden Merkmale auf:

  1. Sie nutzen Websites aus, die sich auf die Identität eines Nutzers verlassen
  2. Sie bringen den Browser des Nutzers dazu, HTTP-Anfragen an die gewünschte Website zu senden
  3. Sie verwenden HTTP-Anfragen, die Nebenwirkungen haben und nicht über die richtigen CSRF-Schutzmechanismen verfügen

Die verschiedenen HTTP-Verben sind unterschiedlich anfällig für CSRF-Angriffe, was zu unterschiedlichen Schutzstrategien führt. Das liegt daran, dass die Webbrowser die Verben unterschiedlich behandeln.

HTTP GET-Anfragen haben eingebettete Parameter, z. B. in Bild-Tags, die manipuliert und ausgenutzt werden können. Normalerweise ändern GET-Anfragen den Status nicht, sodass sie für eine ordnungsgemäß implementierte Webanwendung oder andere Ressource als Ziel von CSRF unwirksam sind.

Mit HTTP POST werden Zustandsänderungen vorgenommen, was zu einem erhöhten Schutzbedarf führt. Zu diesem Zweck implementieren Webbrowser Sicherheitsmaßnahmen, die als SOP (same origin policy) und CORS (cross origin resource sharing) bezeichnet werden und die die ursprungsübergreifende Sicherheitsrichtlinie enthalten. SOP erlaubt nur Anfragen aus demselben Ursprung und CORS erlaubt nur bestimmte Arten von Anfragen, die von einem anderen Ursprung stammen. Die Kombination dieser Implementierungen hilft bei der Prävention von CSRF-Angriffen (und anderen), indem sie die Interaktionsmöglichkeiten einer Anfrage oder Webseite mit einem anderen Ursprung einschränkt.

Andere HTTP-Verben wie PUT und DELETE können nur mit SOP und CORS ausgeführt werden, wodurch viele Cross-Site-Angriffe bekämpft werden können.

Es ist zwar ungewöhnlich, aber einige Websites deaktivieren diese Sicherheitsmaßnahmen ausdrücklich, und es ist auch möglich, sie innerhalb eines Webbrowsers zu deaktivieren.

Wie kann die Cross-Site Request Forgery abgewehrt werden?

Die gebräuchlichste Methode zur Bekämpfung von CSRF-Angriffen ist die Verwendung von Anti-CSRF-Tokens mit einer von zwei Methoden. Die Token-Implementierungen unterscheiden sich zwar geringfügig, aber das zugrunde liegende Prinzip bleibt dasselbe. Durch die Erstellung und den anschließenden Vergleich einer zufällig generierten Token-Zeichenkette ist es für einen Angreifer unwahrscheinlicher, einen Angriff ohne eine außergewöhnlich unwahrscheinliche Vermutung durchführen zu können.

Synchronisations-Token-Muster:

Wenn ein Nutzer eine Webseite besucht, z. B. die Webseite der Bank, die eine Überweisung ermöglicht, bettet die Website der Bank ein zufälliges Token in das Formular ein. Wenn der Nutzer das Formular abschickt, wird das zufällige Token zurückgegeben und die Bank kann prüfen, ob die beiden Token übereinstimmen. Wenn die Token übereinstimmen, wird die Überweisung ausgeführt. Der Angreifer hat keine Möglichkeit, auf den zufälligen Token-Wert zuzugreifen, der auf der Webseite erstellt wurde, und wenn er die Seite anfordert, würde die gleiche Ursprungsrichtlinie den Angreifer daran hindern, die Antwort zu lesen.

Der Nachteil dieser Bekämpfungsmethode ist, dass sie den Aufwand auf der serverseitigen Seite erhöht, die Gültigkeit der Token bei jeder Anfrage zu überprüfen. Außerdem kann es zu Problemen kommen, wenn ein Nutzer mehrere Browser-Fenster oder andere Bedingungen hat, bei denen die Anfrage von unterschiedlicher Software gestellt wird. Durch die Erweiterung des Geltungsbereichs des Tokens auf eine Sitzung statt auf eine Anfrage können einige dieser Schwierigkeiten vermieden werden.

Cookie-to-Header-Token:

Eine andere Methode besteht darin, ein Cookie mit einem zufälligen Token an den Webbrowser des Besuchers zu senden. JavaScript auf der Client-Seite liest den Wert des Tokens im Cookie und kopiert ihn in einen HTTP-Header, der mit jeder Anfrage gesendet wird. Wenn eine echte Anfrage vom Nutzer gesendet wird, kann der Wert im Header vom Server verifiziert werden. Alle anderen Fälle schlagen fehl, wodurch ein erfolgreicher Angriff bekämpft wird.

Durch die Verwendung benutzerdefinierter Regeln über eine WAF können Nutzer dazu beitragen, bestimmte CSRF-Angriffe zu verhindern. Entdecken Sie die Web Application Firewall von Cloudflare.

*Confused Deputy Problem

Ein Confused Deputy Problem bezieht sich auf ein Computerprogramm, das dazu verleitet wird, seine Autorisierung zu missbrauchen. Dieses Risiko, das mit dieser Art von Sicherheitslücke verbunden ist, ist der Grund, warum fähigkeitsbasierte Sicherheit hilft, die mit falschem Gebrauch verbundenen Risiken zu verringern. Bei der Installation von Software zum Beispiel muss sich der Nutzer bei den meisten Computern heute anmelden. Dies hilft die ungewollte Ausführung von Code zu verhindern, wenn der Nutzer versehentlich seine Autorisierung zur Autorisierung einer Installation verwendet.