Schwachstellen im Internet sind weit verbreitet und nehmen ständig zu. Die Sicherheit und der Schutz der Privatsphäre deiner Nutzer/innen ist daher wichtiger denn je. Wenn du Schwachstellen im Internet nicht behebst, kann das zu einem ruinierten Ruf und hohen Geldstrafen führen, und außerdem verlierst du das Vertrauen deiner Nutzer/innen.
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 beunruhigend, weil sie ohne das Wissen des Nutzers stattfinden können. Außerdem sind sie für Entwickler/innen oder Website-Besitzer/innen schwer zu erkennen, weil die böswilligen Anfragen den echten Anfragen sehr ähnlich sehen.
In diesem Artikel erfährst du, wie ein CSRF-Angriff funktioniert und welche Schritte du unternehmen kannst, um dich darauf vorzubereiten.
Schau dir unseren Video-Leitfaden an, um alles über CSRF-Angriffe zu verstehen
Was ist ein CSRF-Angriff?
Bei einem Cross-Site Request Forgery-Angriff, auch bekannt als CSRF-Angriff, wird ein authentifizierter Nutzer dazu gebracht, unbeabsichtigte Aktionen auszuführen, indem bösartige Anfragen gestellt werden, ohne dass er es merkt.
Bei einem CSRF-Angriff werden in der Regel Anfragen gestellt, die den Status ändern, weil 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. All dies kann ohne das Wissen des Nutzers geschehen.
Der böswillige Angreifer nutzt in der Regel Social Engineering, um einem ahnungslosen Nutzer einen Link per Chat oder E-Mail zu schicken.
Wenn der Nutzer auf den Link klickt, führt er die vom Angreifer festgelegten Befehle aus.
Wenn du auf den Link klickst, kannst du zum Beispiel Geld vom Konto des Nutzers überweisen. Oder er kann die E-Mail-Adresse eines Nutzers ändern und so verhindern, dass dieser wieder Zugang zu seinem Konto erhält.
Wie funktioniert ein CSRF-Angriff?
Der erste und wichtigste Schritt bei einem CSRF-Angriff ist es, den Nutzer dazu zu bringen, eine Anfrage zur Änderung des Status zu stellen, während er angemeldet ist. Bei CSRF-Angriffen versucht der Angreifer, einen authentifizierten Nutzer dazu zu bringen, unwissentlich eine bösartige Webanfrage an eine Website oder Webanwendung zu senden. Diese Anfragen können aus Cookies, URL-Parametern und anderen Datentypen bestehen, die für den 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 gefälschte Anfrage erstellen, die den Status ändert.
- Echte Anfragen, die vom Zielserver bearbeitet werden, sollten keine unvorhersehbaren Parameter enthalten. Die Anfrage sollte zum Beispiel kein Passwort als Parameter für die Verifizierung erwarten, bevor die zustandsändernde Anfrage gestartet 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 fügen Cookies automatisch und oft anonym ein und speichern die von einer Domain verwendeten Cookies in jeder Webanfrage, die ein Nutzer an diese Domain sendet.
Die SameSite-Cookie-Richtlinie legt fest, wie der Browser das Cookie in seitenübergreifenden 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ügt der Browser das Cookie in allen seitenübergreifenden Kontexten hinzu. Dadurch wird die Anwendung anfällig für CSRF-Angriffe.
Wenn ein Nutzer unwissentlich eine bösartige Anfrage über einen Webbrowser stellt, lassen die gespeicherten Cookies die Anfrage für den Server legitim erscheinen. Der Server antwortet dann auf die Anfrage, indem er das Konto des Nutzers ändert, den Sitzungsstatus ändert oder die angeforderten Daten zurückgibt.
Schauen wir uns zwei Beispiele für CSRF-Angriffe genauer an, einen mit einer GET-Anfrage und einen mit einer POST-Anfrage.
CSRF für eine GET-Anfrage
Betrachten wir zunächst eine GET-Anfrage, die von einer Webanwendung für Finanzdienstleistungen verwendet wird.
Angenommen, die GET-Anfrage für eine Geldüberweisung sieht etwa so aus:
GET https://xymbank.com/online/transfer?amount=1000&accountNumber=547895 HTTP/1.1In der obigen echten Anfrage bittet der Nutzer darum, 1.000 US-Dollar als Bezahlung für gekaufte Produkte auf ein Konto bei 547895 zu überweisen.
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öglicherweise nicht kennt. Um einen Angriff zu starten, 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 bei allen Nutzern der Bank wirksam, solange sie über eine laufende Cookie-verwaltete Sitzung verfügen.
So würde die gefälschte Anfrage zur Überweisung von 500 US-Dollar auf das Konto eines Hackers (hier die Nummer 654585) aussehen. Beachte, dass das Beispiel unten eine stark vereinfachte Version der Schritte ist, die bei einem CSRF-Angriff zur Erklärung nötig sind.
GET https://xymbank.com/online/transfer?amount=500&accountNumber=654585 HTTP/1.1Wenn das erledigt ist, muss der Angreifer einen Weg finden, den Nutzer dazu zu bringen, diese Anfrage zu senden, während er in seiner Online-Banking-Anwendung angemeldet ist. Eine Möglichkeit, dies zu tun, ist, einen harmlosen Hyperlink zu erstellen, der die Aufmerksamkeit des Nutzers erregt. Der Link kann wie folgt aussehen:
<a
href="https://xymbank.com/online/transfer?amount=500&accountNumber=654585">Click here to get more information</a>.Wenn der Angreifer die richtigen E-Mail-Adressen seiner Zielpersonen gefunden hat, kann er diesen Link per E-Mail an viele Bankkunden schicken. Diejenigen, die auf den Link klicken, während sie eingeloggt sind, würden die Aufforderung auslösen, dem Angreifer 500 Dollar von dem eingeloggten Konto zu schicken.
CSRF für eine POST-Anfrage
Sehen wir uns an, wie das gleiche Finanzinstitut einen CSRF erleben würde, wenn es nur POST-Anfragen akzeptieren würde. In diesem Fall würde die Übermittlung des Hyperlinks, die im Beispiel der GET-Anfrage verwendet wurde, nicht funktionieren. Für einen erfolgreichen CSRF-Angriff müsste ein Angreifer also ein HTML-Formular erstellen. Die echte Anfrage zur Übermittlung von 1.000 US-Dollar für ein gekauftes Produkt 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-Anfrage benötigt ein Cookie, um die Identität des Nutzers, den Betrag, den er senden möchte, und das Konto, von dem er senden möchte, zu ermitteln. Angreifer können diese Anfrage ändern, um einen CSRF-Angriff durchzuführen.
Der Angreifer muss nur ein echtes Cookie zu einer gefälschten Anfrage hinzufügen, damit der Server die Überweisung bearbeitet. Er kann dies tun, indem er einen harmlos aussehenden Hyperlink erstellt, der den Nutzer zu einer Trigger-Website 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>Wir haben den Betrag und die Kontoparameter bereits im Formular oben festgelegt. Sobald ein authentifizierter Benutzer die Seite besucht, fügt 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.
3 Wege zur Eindämmung von CSRF-Angriffen
Es gibt mehrere Methoden, um potenzielle CSRF-Angriffe auf deine Website oder Webanwendung zu verhindern oder drastisch zu entschärfen, darunter:
- Verwendung von CSRF-Tokens
- Verwendung des Referrer-Headers
- Auswahl einer sicherheitsorientierten Hosting-Lösung wie Kinsta
So verhinderst du CSRF-Angriffe mit CSRF-Tokens
Eine CSRF-sichere Website weist jeder Sitzung einen eindeutigen 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 sie das falsche Token enthält, verwirft der Server sie. Das CSRF-Token wird aus Sicherheitsgründen nicht in Session-Cookies im Browser des Kunden gespeichert.
Mögliche Schwachstellen von CSRF-Tokens
Obwohl CSRF-Tokens eine hervorragende Sicherheitsmaßnahme sind, ist diese Methode nicht angriffssicher. Einige der Schwachstellen, die mit CSRF-Tokens einhergehen, sind:
- Umgehung der Validierung – Einige Anwendungen überspringen den Verifizierungsschritt, wenn sie kein Token finden. Wenn ein Angreifer Zugang zu Code erhält, der ein Token enthält, kann er dieses Token entfernen und erfolgreich einen CSRF-Angriff durchführen. Wenn also eine gültige Anfrage an einen Server wie folgt aussieht:
POST /change_password
POST body:
password=pass123&csrf_token=93j9d8eckke20d433Ein Angreifer muss nur das Token entfernen und die Anfrage so senden, um den Angriff auszuführen:
POST /change_password
POST body:
password=pass123- Gepoolte Token – Einige Anwendungen unterhalten einen Pool von Token, um Benutzersitzungen zu validieren, anstatt ein bestimmtes Token einer Sitzung zuzuordnen. Ein Angreifer muss sich nur eines der Token aus dem Pool besorgen, um sich als ein beliebiger 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 dasselbe Token kopieren und verwenden, um sich bei einem anderen Benutzerkonto anzumelden, denn du wirst es wieder verwenden:
- CSRFs können Token in den Cookie kopieren – Einige Anwendungen kopieren die Parameter eines Tokens in den Cookie eines Nutzers. Wenn sich ein Angreifer Zugang zu einem solchen Cookie verschafft, kann er leicht ein anderes 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:93j9d8eckke20d433Mit diesen Informationen kann er dann ein weiteres Cookie erstellen, um den Angriff abzuschließen
- Ungültige Token – Manche Anwendungen passen die CSRF-Tokens nicht an eine Benutzersitzung an. In solchen Fällen kann sich ein Angreifer tatsächlich in eine Sitzung einloggen, ein CSRF-Token ähnlich den oben genannten erhalten und damit einen CSRF-Angriff auf die Sitzung eines Opfers durchführen.
Wie man CSRF-Angriffe mit dem Referrer-Header verhindert
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ür Analysen, Optimierungen und die Protokollierung verwendet.
Du kannst auch die Überprüfung der Referrer-Header auf der Serverseite aktivieren, um CSRF-Angriffe zu verhindern. Die Serverseite überprüft die Herkunft der Anfrage und bestimmt die Zielherkunft der Anfrage. Wenn sie übereinstimmen, wird die Anfrage zugelassen. Wenn sie nicht übereinstimmen, verwirft der Server die Anfrage.
Die Verwendung von Referrer-Headern ist viel einfacher als die Verwendung von Token, da sie keine individuelle Identifizierung des Nutzers erfordert.
Mögliche Schwachstellen des Referrer-Headers
Wie CSRF-Tokens weisen auch Referrer-Header einige erhebliche Schwachstellen auf.
Erstens sind Referrer-Header nicht verpflichtend, und manche Websites senden Anfragen ohne sie. Wenn die CSRF nicht über eine Richtlinie zur Behandlung von Anfragen ohne Header verfügt, können Angreifer Anfragen ohne Header nutzen, um statusändernde Angriffe durchzuführen.
Außerdem ist diese Methode mit der jüngsten Einführung der Referrer-Richtlinie weniger effektiv geworden. Diese Spezifikation verhindert die Weitergabe von URLs an andere Domains und gibt den Nutzern mehr Kontrolle über die Informationen im Referrer-Header. Sie können wählen, ob sie einen Teil der Referrer-Header-Informationen offenlegen oder sie deaktivieren wollen, 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 sich auf Referrer-Header verlassen, schwierig, CSRF-Angriffe von einer solchen Seite zu verhindern.
Wie Kinsta sich vor CSRF-Angriffen schützt
Neben der Verwendung des Referrer-Headers und von CSRF-Tokens gibt es noch eine dritte und viel einfachere Möglichkeit: Die Wahl eines sicheren Hosting-Dienstes wie Kinsta für deine Websites und Webanwendungen bietet eine viel stärkere und sicherere Barriere zwischen Angreifern und deinen Nutzern.
Zusätzlich zu wichtigen Sicherheitsfunktionen wie automatischen Backups, Zwei-Faktor-Authentifizierung und SFTP über SSH-Protokolle bietet die Cloudflare-Integration von Kinsta Schutz auf Unternehmensniveau mit IP-basiertem und Firewall-Schutz.
Kinsta verfügt derzeit über rund 60 benutzerdefinierte Firewall-Regeln, um böswillige Angriffe zu verhindern und schwerwiegende, nicht authentifizierte Sicherheitslücken in Plugins und Themes zu schließen, einschließlich spezieller Regeln, die nach CSRF-Schwachstellen suchen.
Zusammenfassung
Cross-Site-Request-Forgery (CSRF) ist ein Angriff, der authentifizierte Nutzer dazu bringt, unbeabsichtigt zustandsändernde Anfragen zu starten. 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 sich auf Sitzungscookies verlassen, um angemeldete Benutzer zu identifizieren, und die eine schwache SameSite-Cookie-Richtlinie haben. Außerdem brauchen sie einen Server, der Anfragen akzeptiert, die keine unbekannten Parameter wie z. B. Passwörter enthalten. Hacker können bösartige Angriffe entweder per GET oder POST senden.
Obwohl die Verwendung von CSRF-Tokens oder die Überprüfung des Referrer-Headers einige CSRF-Angriffe verhindern kann, haben beide Maßnahmen potenzielle Schwachstellen, die deine Präventivmaßnahmen nutzlos machen können, wenn du nicht aufpasst.
Die Umstellung auf eine sichere Hosting-Plattform wie Kinsta schützt deine Websites oder Webanwendungen vor CSRF-Angriffen. Außerdem verhindert die Integration von Kinsta in Cloudflare bestimmte CSRF-Angriffe.
Schreibe einen Kommentar