In diesem Artikel erf\u00e4hrst du, wie ein CSRF-Angriff funktioniert und welche Schritte du unternehmen kannst, um dich darauf vorzubereiten.<\/p>\n
Schau dir unseren Video-Leitfaden an, um alles \u00fcber CSRF-Angriffe zu verstehen<\/a><\/strong><\/p>\n Bei einem Cross-Site Request Forgery-Angriff, auch bekannt als CSRF-Angriff, wird ein authentifizierter Nutzer dazu gebracht, unbeabsichtigte Aktionen auszuf\u00fchren, indem b\u00f6sartige Anfragen gestellt werden, ohne dass er es merkt.<\/p>\n Bei einem CSRF-Angriff werden in der Regel Anfragen gestellt, die den Status \u00e4ndern, weil der Angreifer keine Antwort erh\u00e4lt. Beispiele f\u00fcr solche Anfragen sind das L\u00f6schen eines Datensatzes, das \u00c4ndern eines Passworts<\/a>, der Kauf eines Produkts oder das Senden einer Nachricht. All dies kann ohne das Wissen des Nutzers geschehen.<\/p>\n Der b\u00f6swillige Angreifer nutzt in der Regel Social Engineering, um einem ahnungslosen Nutzer einen Link per Chat oder E-Mail zu schicken.<\/p>\n Wenn der Nutzer auf den Link klickt, f\u00fchrt er die vom Angreifer festgelegten Befehle aus.<\/p>\n Wenn du auf den Link klickst, kannst du zum Beispiel Geld vom Konto des Nutzers \u00fcberweisen. Oder er kann die E-Mail-Adresse eines Nutzers \u00e4ndern und so verhindern, dass dieser wieder Zugang zu seinem Konto erh\u00e4lt.<\/p>\n Der erste und wichtigste Schritt bei einem CSRF-Angriff ist es, den Nutzer dazu zu bringen, eine Anfrage zur \u00c4nderung des Status zu stellen, w\u00e4hrend er angemeldet ist. Bei CSRF-Angriffen versucht der Angreifer, einen authentifizierten Nutzer dazu zu bringen, unwissentlich eine b\u00f6sartige Webanfrage an eine Website oder Webanwendung zu senden. Diese Anfragen k\u00f6nnen aus Cookies, URL-Parametern<\/a> und anderen Datentypen bestehen, die f\u00fcr den Benutzer normal erscheinen.<\/p>\n Damit ein CSRF-Angriff erfolgreich ist, m\u00fcssen die folgenden Bedingungen erf\u00fcllt sein:<\/p>\n Die h\u00e4ufigste Methode zur Durchf\u00fchrung von CSRF-Angriffen ist die Verwendung von Cookies in Anwendungen mit einer schwachen SameSite-Cookie-Richtlinie. Webbrowser f\u00fcgen Cookies automatisch<\/a> und oft anonym ein und speichern die von einer Domain verwendeten Cookies in jeder Webanfrage, die ein Nutzer an diese Domain sendet.<\/p>\n Die SameSite-Cookie-Richtlinie legt fest, wie der Browser das Cookie in seiten\u00fcbergreifenden Browsing-Kontexten behandelt. Bei der Einstellung „strict“ wird der Cookie nicht in Cross-Site-Browsing-Kontexten weitergegeben, um CSRF-Angriffe zu verhindern. Wenn der Wert auf „none“ gesetzt ist, f\u00fcgt der Browser das Cookie in allen seiten\u00fcbergreifenden Kontexten hinzu. Dadurch wird die Anwendung anf\u00e4llig f\u00fcr CSRF-Angriffe.<\/p>\n Wenn ein Nutzer unwissentlich eine b\u00f6sartige Anfrage \u00fcber einen Webbrowser stellt, lassen die gespeicherten Cookies die Anfrage f\u00fcr den Server legitim erscheinen. Der Server antwortet dann auf die Anfrage, indem er das Konto des Nutzers \u00e4ndert, den Sitzungsstatus \u00e4ndert oder die angeforderten Daten zur\u00fcckgibt.<\/p>\n Schauen wir uns zwei Beispiele f\u00fcr CSRF-Angriffe genauer an, einen mit einer GET-Anfrage und einen mit einer POST-Anfrage.<\/p>\n Betrachten wir zun\u00e4chst eine GET-Anfrage<\/a>, die von einer Webanwendung f\u00fcr Finanzdienstleistungen verwendet wird.<\/p>\n Angenommen, die GET-Anfrage f\u00fcr eine Geld\u00fcberweisung sieht etwa so aus:<\/p>\n In der obigen echten Anfrage bittet der Nutzer darum, 1.000 US-Dollar als Bezahlung f\u00fcr gekaufte Produkte auf ein Konto bei Obwohl diese Anfrage eindeutig, einfach und praktisch ist, setzt sie den Kontoinhaber einem CSRF-Angriff aus. Das liegt daran, dass die Anfrage keine Details erfordert, die ein Angreifer m\u00f6glicherweise nicht kennt. Um einen Angriff zu starten, m\u00fcsste ein Angreifer also nur die Parameter dieser Anfrage (den Betrag und die Kontonummer) \u00e4ndern, um eine ausf\u00fchrbare gef\u00e4lschte Anfrage zu erstellen.<\/p>\n Die b\u00f6swillige Anfrage w\u00e4re bei allen Nutzern der Bank wirksam, solange sie \u00fcber eine laufende Cookie-verwaltete Sitzung verf\u00fcgen.<\/p>\n So w\u00fcrde die gef\u00e4lschte Anfrage zur \u00dcberweisung von 500 US-Dollar auf das Konto eines Hackers (hier die Nummer Wenn das erledigt ist, muss der Angreifer einen Weg finden, den Nutzer dazu zu bringen, diese Anfrage zu senden, w\u00e4hrend er in seiner Online-Banking-Anwendung angemeldet ist. Eine M\u00f6glichkeit, dies zu tun, ist, einen harmlosen Hyperlink zu erstellen, der die Aufmerksamkeit des Nutzers erregt. Der Link kann wie folgt aussehen:<\/p>\n Wenn der Angreifer die richtigen E-Mail-Adressen<\/a> seiner Zielpersonen gefunden hat, kann er diesen Link per E-Mail an viele Bankkunden schicken. Diejenigen, die auf den Link klicken, w\u00e4hrend sie eingeloggt sind, w\u00fcrden die Aufforderung ausl\u00f6sen, dem Angreifer 500 Dollar von dem eingeloggten Konto zu schicken.<\/p>\n Sehen wir uns an, wie das gleiche Finanzinstitut einen CSRF erleben w\u00fcrde, wenn es nur POST-Anfragen<\/a> akzeptieren w\u00fcrde. In diesem Fall w\u00fcrde die \u00dcbermittlung des Hyperlinks, die im Beispiel der GET-Anfrage verwendet wurde, nicht funktionieren. F\u00fcr einen erfolgreichen CSRF-Angriff m\u00fcsste ein Angreifer also ein HTML-Formular erstellen. Die echte Anfrage zur \u00dcbermittlung von 1.000 US-Dollar f\u00fcr ein gekauftes Produkt w\u00fcrde so aussehen:<\/p>\n Diese POST-Anfrage ben\u00f6tigt ein Cookie, um die Identit\u00e4t des Nutzers, den Betrag, den er senden m\u00f6chte, und das Konto, von dem er senden m\u00f6chte, zu ermitteln. Angreifer k\u00f6nnen diese Anfrage \u00e4ndern, um einen CSRF-Angriff durchzuf\u00fchren.<\/p>\n Der Angreifer muss nur ein echtes Cookie zu einer gef\u00e4lschten Anfrage hinzuf\u00fcgen, damit der Server die \u00dcberweisung bearbeitet. Er kann dies tun, indem er einen harmlos aussehenden Hyperlink erstellt, der den Nutzer zu einer Trigger-Website f\u00fchrt, die so aussieht:<\/p>\n Wir haben den Betrag und die Kontoparameter bereits im Formular oben festgelegt. Sobald ein authentifizierter Benutzer die Seite besucht, f\u00fcgt der Browser das Sitzungs-Cookie hinzu, bevor er die Anfrage an den Server weiterleitet. Der Server leitet dann die 500 Dollar an das Konto des Hackers weiter.<\/p>\n Es gibt mehrere Methoden, um potenzielle CSRF-Angriffe auf deine Website oder Webanwendung zu verhindern oder drastisch zu entsch\u00e4rfen, darunter:<\/p>\n Eine CSRF-sichere Website weist jeder Sitzung einen eindeutigen Token zu und teilt es mit der Serverseite und dem Client-Browser<\/a>. Immer wenn ein Browser eine sensible Anfrage sendet, erwartet der Server, dass sie das zugewiesene CSRF-Token enth\u00e4lt. Wenn sie das falsche Token enth\u00e4lt, verwirft der Server sie. Das CSRF-Token wird aus Sicherheitsgr\u00fcnden nicht in Session-Cookies im Browser des Kunden gespeichert.<\/p>\n Obwohl CSRF-Tokens eine hervorragende Sicherheitsma\u00dfnahme sind, ist diese Methode nicht angriffssicher. Einige der Schwachstellen, die mit CSRF-Tokens einhergehen, sind:<\/p>\n Ein Angreifer muss nur das Token entfernen und die Anfrage so senden, um den Angriff auszuf\u00fchren:<\/p>\n Ein Angreifer kann sich mit seinem Konto bei einer Anwendung anmelden, um ein Token zu erhalten, z. B:<\/p>\n Und da die Token gepoolt sind, kann der Angreifer dasselbe Token kopieren und verwenden, um sich bei einem anderen Benutzerkonto anzumelden, denn du wirst es wieder verwenden:<\/p>\n Ein Angreifer kann sich also mit seinem Konto bei einer Anwendung anmelden und die Cookie-Datei \u00f6ffnen, um Folgendes zu sehen:<\/p>\n Mit diesen Informationen kann er dann ein weiteres Cookie erstellen, um den Angriff abzuschlie\u00dfen<\/p>\n Eine weitere Strategie zur Verhinderung von CSRF-Angriffen ist die Verwendung des Referrer-Headers. In HTTP zeigen Referrer-Header die Herkunft der Anfragen an. Sie werden normalerweise f\u00fcr Analysen<\/a>, Optimierungen und die Protokollierung verwendet.<\/p>\n Du kannst auch die \u00dcberpr\u00fcfung der Referrer-Header auf der Serverseite aktivieren, um CSRF-Angriffe zu verhindern. Die Serverseite \u00fcberpr\u00fcft die Herkunft der Anfrage und bestimmt die Zielherkunft der Anfrage. Wenn sie \u00fcbereinstimmen, wird die Anfrage zugelassen. Wenn sie nicht \u00fcbereinstimmen, verwirft der Server die Anfrage.<\/p>\n Die Verwendung von Referrer-Headern ist viel einfacher als die Verwendung von Token, da sie keine individuelle Identifizierung des Nutzers erfordert.<\/p>\n Wie CSRF-Tokens weisen auch Referrer-Header einige erhebliche Schwachstellen auf.<\/p>\n Erstens sind Referrer-Header nicht verpflichtend, und manche Websites senden Anfragen ohne sie. Wenn die CSRF nicht \u00fcber eine Richtlinie zur Behandlung von Anfragen ohne Header verf\u00fcgt, k\u00f6nnen Angreifer Anfragen ohne Header nutzen, um status\u00e4ndernde Angriffe durchzuf\u00fchren.<\/p>\n Au\u00dferdem ist diese Methode mit der j\u00fcngsten Einf\u00fchrung der Referrer-Richtlinie<\/a> weniger effektiv geworden. Diese Spezifikation verhindert die Weitergabe von URLs an andere Domains und gibt den Nutzern mehr Kontrolle \u00fcber die Informationen im Referrer-Header. Sie k\u00f6nnen w\u00e4hlen, ob sie einen Teil der Referrer-Header-Informationen offenlegen oder sie deaktivieren wollen, indem sie ein Metadaten-Tag auf der HTML-Seite hinzuf\u00fcgen, wie unten gezeigt:<\/p>\n Der obige Code entfernt den Referrer-Header f\u00fcr alle Anfragen von dieser Seite. Dadurch wird es f\u00fcr Anwendungen, die sich auf Referrer-Header verlassen, schwierig, CSRF-Angriffe von einer solchen Seite zu verhindern.<\/p>\n Neben der Verwendung des Referrer-Headers und von CSRF-Tokens gibt es noch eine dritte und viel einfachere M\u00f6glichkeit: Die Wahl eines sicheren Hosting-Dienstes wie Kinsta<\/a> f\u00fcr deine Websites und Webanwendungen bietet eine viel st\u00e4rkere und sicherere Barriere zwischen Angreifern und deinen Nutzern.<\/p>\n Zus\u00e4tzlich zu wichtigen Sicherheitsfunktionen wie automatischen Backups<\/a>, Zwei-Faktor-Authentifizierung<\/a> und SFTP \u00fcber SSH-Protokolle<\/a> bietet die Cloudflare-Integration von Kinsta<\/a> Schutz auf Unternehmensniveau mit IP-basiertem und Firewall-Schutz.<\/p>\n Kinsta verf\u00fcgt derzeit \u00fcber rund 60 benutzerdefinierte Firewall-Regeln, um b\u00f6swillige Angriffe zu verhindern und schwerwiegende, nicht authentifizierte Sicherheitsl\u00fccken in Plugins und Themes zu schlie\u00dfen, einschlie\u00dflich spezieller Regeln, die nach CSRF-Schwachstellen suchen.<\/p>\n Cross-Site-Request-Forgery (CSRF) ist ein Angriff, der authentifizierte Nutzer dazu bringt, unbeabsichtigt zustands\u00e4ndernde Anfragen zu starten. Sie zielen auf Anwendungen ab, die nicht zwischen g\u00fcltigen und gef\u00e4lschten Status\u00e4nderungsanfragen unterscheiden k\u00f6nnen.<\/p>\n CSRF kann nur bei Anwendungen erfolgreich sein, die sich auf Sitzungscookies verlassen, um angemeldete Benutzer zu identifizieren, und die eine schwache SameSite-Cookie-Richtlinie haben. Au\u00dferdem brauchen sie einen Server, der Anfragen akzeptiert, die keine unbekannten Parameter wie z. B. Passw\u00f6rter enthalten. Hacker k\u00f6nnen b\u00f6sartige Angriffe entweder per GET oder POST senden.<\/p>\n Obwohl die Verwendung von CSRF-Tokens oder die \u00dcberpr\u00fcfung des Referrer-Headers einige CSRF-Angriffe verhindern kann, haben beide Ma\u00dfnahmen potenzielle Schwachstellen, die deine Pr\u00e4ventivma\u00dfnahmen nutzlos machen k\u00f6nnen, wenn du nicht aufpasst.<\/p>\nWas ist ein CSRF-Angriff?<\/h2>\n
![\"Ein](\"https:\/\/kinsta.com\/wp-content\/uploads\/2022\/11\/CSRF-Attack-Okta.png\")
Wie funktioniert ein CSRF-Angriff?<\/h2>\n
\n
CSRF f\u00fcr eine GET-Anfrage<\/h2>\n
GET https:\/\/xymbank.com\/online\/transfer?amount=1000&accountNumber=547895 HTTP\/1.1<\/code><\/pre>\n547895<\/code> zu \u00fcberweisen.<\/p>\n654585<\/code>) aussehen. Beachte, dass das Beispiel unten eine stark vereinfachte Version der Schritte ist, die bei einem CSRF-Angriff zur Erkl\u00e4rung n\u00f6tig sind.<\/p>\nGET https:\/\/xymbank.com\/online\/transfer?amount=500&accountNumber=654585 HTTP\/1.1<\/code><\/pre>\n<a\nhref=\"https:\/\/xymbank.com\/online\/transfer?amount=500&accountNumber=654585\">Click here to get more information<\/a>.<\/code><\/pre>\nCSRF f\u00fcr eine POST-Anfrage<\/h2>\n
POST \/online\/transfer HTTP\/1.1\nHost: xymbank.com\nContent-Type: application\/x-www-form-urlencoded\nCookie: session=FRyhityeQkAPzeQ5gHgTvlyxHJYhg\namount=1000\naccount=547895<\/code><\/pre>\n<html>\n<body>\n<form action=\"https:\/\/xymbank.com\/online\/transfer\" method=\"POST\">\n<input type=\"hidden\" name=\"amount\" value=\"500\"\/>\n<input type=\"hidden\" name=\"account\" value=\"654585\" \/>\n<\/form>\n<script>\ndocument.forms[0].submit();\n<\/script>\n<\/body>\n<\/html><\/code><\/pre>\n3 Wege zur Eind\u00e4mmung von CSRF-Angriffen<\/h2>\n
\n
So verhinderst du CSRF-Angriffe mit CSRF-Tokens<\/h2>\n
M\u00f6gliche Schwachstellen von CSRF-Tokens<\/h3>\n
\n
POST \/change_password\nPOST body:\npassword=pass123&csrf_token=93j9d8eckke20d433<\/code><\/pre>\nPOST \/change_password\nPOST body:\npassword=pass123<\/code><\/pre>\n\n
[application_url].com?csrf_token=93j9d8eckke20d433<\/code><\/pre>\n\n
Csrf_token:93j9d8eckke20d433<\/code><\/pre>\n\n
Wie man CSRF-Angriffe mit dem Referrer-Header verhindert<\/h2>\n
M\u00f6gliche Schwachstellen des Referrer-Headers<\/h3>\n
<meta name=\"referrer\" content=\"no-referrer\"><\/code><\/pre>\nWie Kinsta sich vor CSRF-Angriffen sch\u00fctzt<\/h2>\n
Zusammenfassung<\/h2>\n