CSRF-Angriffe verstehen und CSRF-Schwachstellen sperren
Veröffentlicht: 2022-11-21Sicherheitslücken im Internet sind weit verbreitet und nehmen ständig zu. Die Wahrung der Sicherheit und Privatsphäre Ihrer Benutzer ist wichtiger denn je. Das Nichtbeachten von Web-Schwachstellen kann zu einem ruinierten Ruf und saftigen Bußgeldern von Aufsichtsbehörden führen, und Sie verlieren auch das Vertrauen Ihrer Benutzer.
Websites und Webanwendungen sind anfällig für Malware, Spam und andere Angriffe – dieser Artikel konzentriert sich auf einen solchen Angriffsvektor – Cross-Site Request Forgery (CSRF)-Angriffe. CSRF-Angriffe sind besonders besorgniserregend, da sie ohne Wissen des Benutzers auftreten können. Sie sind auch für einen Entwickler oder Websitebesitzer schwer zu erkennen, da die böswilligen Anfragen echten Anfragen sehr ähnlich erscheinen.
Dieser Artikel untersucht einen CSRF-Angriff, wie er funktioniert und welche Schritte Sie unternehmen können, um sich darauf vorzubereiten.
Was ist ein CSRF-Angriff?
Ein Cross-Site Request Forgery-Angriff, auch bekannt als CSRF-Angriff, verleitet einen authentifizierten Benutzer dazu, unbeabsichtigte Aktionen auszuführen, indem er böswillige Anforderungen sendet, ohne dass er es merkt.
Typischerweise beinhaltet ein CSRF-Angriff Anfragen zur Zustandsänderung, da der Angreifer keine Antwort erhält. Beispiele für solche Anfragen sind das Löschen eines Datensatzes, das Ändern eines Passworts, der Kauf eines Produkts oder das Senden einer Nachricht. Diese können alle ohne das Wissen des Benutzers auftreten.
Der böswillige Angreifer verwendet normalerweise Social Engineering, um einem ahnungslosen Benutzer einen Link per Chat oder E-Mail zu senden.
Wenn der Benutzer auf den Link klickt, führt er die vom Angreifer festgelegten Befehle aus.
Wenn Sie beispielsweise auf einen Link klicken, können Sie Geld vom Konto eines Benutzers überweisen. Oder es kann die E-Mail-Adresse eines Benutzers ändern und ihn daran hindern, wieder auf das Konto zuzugreifen.
Wie funktioniert ein CSRF-Angriff?
Der erste und wichtigste Schritt bei einem CSRF-Angriff ist es, den Benutzer dazu zu bringen, eine Statusänderungsanforderung zu initiieren, während er angemeldet ist. Bei CSRF-Angriffen zielt der Angreifer darauf ab, einen authentifizierten Benutzer dazu zu bringen, unwissentlich eine böswillige Webanfrage an eine Website oder Webanwendung zu senden. Diese Anfragen können aus Cookies, URL-Parametern und anderen Datentypen bestehen, die dem Benutzer normal erscheinen.
Damit ein CSRF-Angriff erfolgreich ist, müssen die folgenden Bedingungen erfüllt sein:
- Ein authentifizierter Benutzer muss bei einer Webanwendung angemeldet sein, die Cookies für die Sitzungsverwaltung verwendet.
- Ein Angreifer muss eine zustandsändernde gefälschte Anfrage erstellen.
- Echte Anforderungen, die vom Zielserver verarbeitet werden, sollten keine unvorhersehbaren Parameter enthalten. Zum Beispiel sollte die Anfrage kein Passwort als Parameter für Überprüfungszwecke erwarten, bevor die Statusänderungsanfrage initiiert wird.
Die häufigste Methode zur Durchführung von CSRF-Angriffen ist die Verwendung von Cookies in Anwendungen mit einer schwachen SameSite-Cookie-Richtlinie. Webbrowser schließen Cookies automatisch und oft anonym ein und speichern Cookies, die von einer Domain verwendet werden, in jeder Webanforderung, die ein Benutzer an diese Domain sendet.
Die SameSite-Cookie-Richtlinie definiert, wie der Browser in Cross-Site-Browsing-Kontexten mit dem Cookie umgeht. Wenn es auf „Strict“ gesetzt ist, wird das Cookie nicht in Cross-Site-Browsing-Kontexten geteilt, wodurch CSRF-Angriffe verhindert werden. Der Browser hängt das Cookie in allen websiteübergreifenden Kontexten an, wenn es auf „none“ gesetzt ist. Dadurch wird die Anwendung anfällig für CSRF-Angriffe.
Wenn ein Benutzer unwissentlich eine böswillige Anfrage über einen Webbrowser sendet, sorgen die gespeicherten Cookies dafür, dass die Anfrage dem Server legitim erscheint. Der Server antwortet dann auf die Anfrage, indem er das Konto des Benutzers ändert, den Sitzungsstatus ändert oder die angeforderten Daten zurückgibt.
Schauen wir uns zwei Beispiele für CSRF-Angriffsmöglichkeiten genauer an, eines mit einer GET-Anfrage und das andere mit einer POST-Anfrage.
CSRF für eine GET-Anfrage
Betrachten Sie zunächst eine GET-Anforderung, die von einer Finanzbank-Webanwendung verwendet wird, bei der der Angriff eine GET-Anforderung und die Bereitstellung eines Hyperlinks ausnutzt.
Angenommen, die GET-Anforderung zum Überweisen von Geld sieht etwa so aus:
GET https://xymbank.com/online/transfer?amount=1000&accountNumber=547895 HTTP/1.1 In der obigen echten Anfrage fordert der Benutzer an, 1.000 US-Dollar als Zahlung für gekaufte Produkte auf ein Konto mit 547895 zu überweisen.
Obwohl diese Anfrage explizit, 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öglicherweise nicht kennt. Um einen Angriff einzuleiten, müsste ein Angreifer also nur die Parameter dieser Anfrage (den Betrag und die Kontonummer) ändern, um eine ausführbare gefälschte Anfrage zu erstellen.
Die böswillige Anfrage wäre für alle Benutzer der Bank wirksam, solange sie laufende Cookie-verwaltete Sitzungen haben.
So würde die gefälschte Anfrage aussehen, 500 $ auf das Konto eines Hackers (hier Nummer 654585 ) zu überweisen. Beachten Sie, dass das folgende Beispiel zur Erläuterung eine stark vereinfachte Version der Schritte ist, die an einem CSRF-Angriff beteiligt sind.
GET https://xymbank.com/online/transfer?amount=500&accountNumber=654585 HTTP/1.1Sobald dies abgeschlossen ist, muss der Angreifer einen Weg finden, den Benutzer dazu zu bringen, diese Anfrage zu senden, während er bei seiner Online-Banking-Anwendung angemeldet ist. Eine Möglichkeit, dies zu tun, besteht darin, einen harmlosen Hyperlink zu erstellen, der die Aufmerksamkeit des Benutzers auf sich zieht. Der Link kann so aussehen:
<a href="https://xymbank.com/online/transfer?amount=500&accountNumber=654585">Click here to get more information</a>. Da der Angreifer die korrekten E-Mail-Adressen seiner Ziele gefunden hat, kann er diese per E-Mail an viele Bankkunden senden. Diejenigen, die auf den Link klicken, während sie angemeldet sind, würden die Aufforderung auslösen, dem Angreifer 500 Dollar vom angemeldeten Konto zu senden.
CSRF für eine POST-Anfrage
Mal sehen, wie dasselbe Finanzinstitut einen CSRF erleben würde, wenn es nur POST-Anforderungen akzeptieren würde. In diesem Fall würde die im GET-Request-Beispiel verwendete Hyperlink-Übermittlung nicht funktionieren. Daher würde ein erfolgreicher CSRF-Angriff erfordern, dass ein Angreifer ein HTML-Formular erstellt. Die echte Anfrage, 1.000 $ für ein gekauftes Produkt zu senden, würde so aussehen:
POST /online/transfer HTTP/1.1 Host: xymbank.com Content-Type: application/x-www-form-urlencoded Cookie: session=FRyhityeQkAPzeQ5gHgTvlyxHJYhg amount=1000 account=547895Diese POST-Anforderung erfordert ein Cookie, um die Identität des Benutzers, den Betrag, den er senden möchte, und das Konto, das er senden möchte, zu bestimmen. Angreifer können diese Anfrage ändern, um einen CSRF-Angriff durchzuführen.
Der Angreifer muss einer gefälschten Anfrage nur ein echtes Cookie hinzufügen, damit der Server die Übertragung verarbeitet. Sie können das tun, indem sie einen harmlos aussehenden Hyperlink erstellen, der den Benutzer zu einer Trigger-Webseite führt, die so aussieht:
<html> <body> <form action="https://xymbank.com/online/transfer" method="POST"> <input type="hidden" name="amount" value="500"/> <input type="hidden" name="account" value="654585" /> </form> <script> document.forms[0].submit(); </script> </body> </html>Die Betrags- und Kontoparameter haben wir bereits oben im Formular eingestellt. Sobald ein authentifizierter Benutzer die Seite besucht, fügt der Browser das Sitzungscookie hinzu, bevor er die Anfrage an den Server weiterleitet. Der Server leitet dann 500 $ an das Konto des Hackers weiter.
3 Möglichkeiten zur Abwehr von CSRF-Angriffen
Es gibt mehrere Methoden, um potenzielle CSRF-Angriffe auf Ihre Website oder Webanwendung zu verhindern und drastisch abzuschwächen, darunter:
- Verwenden von CSRF-Token
- Verwendung des Referrer-Headers
- Auswahl einer sicherheitsorientierten Hosting-Lösung wie Kinsta
So verhindern Sie CSRF-Angriffe mit CSRF-Token
Eine CSRF-sichere Website weist jeder Sitzung ein eindeutiges Token zu und teilt es mit der Serverseite und dem Client-Browser. Immer wenn ein Browser eine sensible Anfrage sendet, erwartet der Server, dass sie das zugewiesene CSRF-Token enthält. Wenn es das falsche Token hat, lässt es der Server fallen. Das CSRF-Token wird aus Sicherheitsgründen nicht in Sitzungscookies im Browser des Clients gespeichert.
Potenzielle Schwachstellen von CSRF-Token
Obwohl CSRF-Token eine hervorragende Sicherheitsmaßnahme darstellen, ist diese Methode nicht angriffssicher. Einige der Schwachstellen, die CSRF-Token begleiten, sind:
- Validierungsumgehung – Einige Anwendungen überspringen den Überprüfungsschritt, wenn sie kein Token finden. Wenn ein Angreifer Zugriff auf Code erhält, der ein Token enthält, kann er dieses Token entfernen und erfolgreich einen CSRF-Angriff ausführen. Wenn also eine gültige Anfrage an einen Server so aussieht:
POST /change_password POST body: password=pass123&csrf_token=93j9d8eckke20d433Ein Angreifer muss nur den Token entfernen und wie folgt senden, um den Angriff auszuführen:
POST /change_password POST body: password=pass123- Gepoolte Token – Einige Anwendungen verwalten einen Pool von Token, um Benutzersitzungen zu validieren, anstatt einer Sitzung ein bestimmtes Token zuzuweisen. Ein Angreifer muss nur eines der bereits im Pool befindlichen Token abrufen, um sich als Benutzer der Website auszugeben.
Ein Angreifer kann sich mit seinem Konto bei einer Anwendung anmelden, um ein Token zu erhalten, z. B.:
[application_url].com?csrf_token=93j9d8eckke20d433Und da die Token gepoolt sind, kann der Angreifer denselben Token kopieren und verwenden, um sich bei einem anderen Benutzerkonto anzumelden, da Sie ihn erneut verwenden werden:
- CSRFs können als Token in das Cookie kopiert werden — Einige Anwendungen kopieren die Parameter, die sich auf ein Token beziehen, in das Cookie eines Benutzers. Wenn ein Angreifer Zugriff auf ein solches Cookie erhält, kann er problemlos ein weiteres Cookie erstellen, es in einem Browser platzieren und einen CSRF-Angriff ausführen.
Ein Angreifer kann sich also mit seinem Konto bei einer Anwendung anmelden und die Cookie-Datei öffnen, um Folgendes zu sehen:
Csrf_token:93j9d8eckke20d433Sie können diese Informationen dann verwenden, um ein weiteres Cookie zu erstellen, um den Angriff abzuschließen
- Ungültige Token – Einige Anwendungen ordnen CSRF-Token keiner Benutzersitzung zu. In solchen Fällen kann sich ein Angreifer wirklich in eine Sitzung einloggen, ein CSRF-Token ähnlich dem oben genannten erhalten und es verwenden, um einen CSRF-Angriff auf die Sitzung eines Opfers zu orchestrieren.
So verhindern Sie CSRF-Angriffe mit dem Referrer-Header
Eine weitere Strategie zur Verhinderung von CSRF-Angriffen ist die Verwendung des Referrer-Headers. In HTTP geben Referrer-Header den Ursprung der Anfragen an. Sie werden normalerweise verwendet, um Analysen, Optimierungen und Protokollierungen durchzuführen.
Sie können auch serverseitig die Überprüfung von Referrer-Headern aktivieren, um CSRF-Angriffe zu verhindern. Die Serverseite prüft den Quellursprung der Anfrage und bestimmt den Zielursprung der Anfrage. Wenn sie übereinstimmen, wird die Anfrage zugelassen. Bei einer Nichtübereinstimmung verwirft der Server die Anfrage.
Die Verwendung von Referrer-Headern ist viel einfacher als die Verwendung von Token, da keine individuelle Benutzeridentifikation erforderlich ist.
Mögliche Schwachstellen des Referrer-Headers
Wie CSRF-Token weisen Referrer-Header einige erhebliche Schwachstellen auf.
Erstens sind Referrer-Header nicht obligatorisch, und einige Websites senden Anfragen ohne sie. Wenn die CSRF nicht über die Richtlinie verfügt, Anfragen ohne Header zu verarbeiten, können Angreifer Anfragen ohne Header verwenden, um Zustandsänderungsangriffe auszuführen.
Darüber hinaus ist diese Methode mit der kürzlichen Einführung der Empfehlungsrichtlinie weniger effektiv geworden. Diese Spezifikation verhindert URL-Lecks zu anderen Domains und gibt Benutzern mehr Kontrolle über die Informationen im Referrer-Header. Sie können einen Teil der Referrer-Header-Informationen anzeigen oder deaktivieren, indem sie ein Metadaten-Tag auf der HTML-Seite hinzufügen, wie unten gezeigt:
<meta name="referrer" content="no-referrer">Der obige Code entfernt den Referrer-Header für alle Anfragen von dieser Seite. Dadurch wird es für Anwendungen, die auf Referrer-Header angewiesen sind, schwierig, CSRF-Angriffe von einer solchen Seite zu verhindern.
Wie Kinsta vor CSRF-Angriffen schützt
Zusätzlich zur Verwendung des Referrer-Headers und der CSRF-Token gibt es eine dritte und viel einfachere Option: Die Wahl eines sicheren Hosting-Dienstes wie Kinsta für Ihre Websites und Webanwendungen bietet eine viel stärkere und sicherere Barriere zwischen Angreifern und Ihren Benutzern.
Zusätzlich zu kritischen Sicherheitsfunktionen wie automatischen Backups, Zwei-Faktor-Authentifizierung und SFTP-über-SSH-Protokollen bietet die Cloudflare-Integration von Kinsta Schutz auf Unternehmensebene mit IP-basiertem und Firewall-Schutz.
Insbesondere verfügt Kinsta derzeit über rund 60 benutzerdefinierte Firewall-Regeln, um böswillige Angriffe zu verhindern und mit schwerwiegenden nicht authentifizierten Schwachstellen in Plugins und Themes umzugehen, einschließlich spezifischer, die nach CSRF-Schwachstellen suchen.
Zusammenfassung
Cross-Site Request Forgery (CSRF) ist ein Angriff, der authentifizierte Benutzer dazu verleitet, unbeabsichtigt Statusänderungsanforderungen zu initiieren. Sie zielen auf Anwendungen ab, die nicht zwischen gültigen und gefälschten Statusänderungsanfragen unterscheiden können.
CSRF kann nur bei Anwendungen erfolgreich sein, die auf Sitzungscookies angewiesen sind, um angemeldete Benutzer zu identifizieren, und eine schwache SameSite-Cookie-Richtlinie haben. Sie benötigen außerdem einen Server, der Anfragen akzeptiert, die keine unbekannten Parameter wie Passwörter enthalten. Hacker können böswillige Angriffe entweder mit GET oder POST senden.
Obwohl die Verwendung von CSRF-Token oder die Erzwingung der Referrer-Header-Überprüfung einige CSRF-Angriffe verhindern können, haben beide Maßnahmen potenzielle Schwachstellen, die Ihre vorbeugenden Maßnahmen nutzlos machen können, wenn Sie nicht vorsichtig sind.
Die Migration zu einer sicheren Hosting-Plattform wie Kinsta schützt Ihre Websites oder Web-Apps vor CSRF-Angriffen. Darüber hinaus verhindert die Integration von Kinsta mit Cloudflare spezifische CSRF-Angriffe.