Ein Cross-Site-Request-Forgery-Angriff verleitet ein Opfer dazu, seine Anmeldedaten zu verwenden, um eine zustandsändernde Aktivität aufzurufen.
Nach Lektüre dieses Artikels können Sie Folgendes:
Ähnliche Inhalte
Sichere Webanwendungen
Angriff mit Cross-Site-Scripting
Brute-Force-Angriff
Datenschutzverletzung
Was ist SQL-Injection?
Abonnieren Sie theNET, Cloudflares monatliche Zusammenfassung der beliebtesten Einblicke in das Internet!
Link zum Artikel kopieren
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.
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:
CSRF-Angriffe unterscheiden sich in ihrer Methodik, weisen aber typischerweise die folgenden Merkmale auf:
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.
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.
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.
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.
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.