Was ist CSRF? Wie können wir CSRF verhindern?

Im digitalen Zeitalter hat sich das Internet in den Stoff unseres täglichen Lebens eingewoben. Wir haben zahlreiche Aktivitäten ins Internet verlagert, vom Einkaufen über das Sozialisieren auf verschiedenen Plattformen bis hin zur Abwicklung von Bankgeschäften. Da finanzielle Interaktionen immer weiter verbreitet sind, sind die Auswirkungen der Netzwerksicherheit deutlicher geworden. Eine der häufigsten Cyber-Bedrohungen im Internet ist CSRF (Cross-Site Request Forgery), und es ist unerlässlich, sich mit seinen Nuancen auseinanderzusetzen.

Was ist CSRF?

CSRF-Angriffe nutzen Schwachstellen in den Anfragevalidierungsmechanismen einer Zielwebsite aus. In bestimmten Situationen führen Benutzer unwissentlich bösartige Anfragen aus, während sie auf der Zielwebsite angemeldet sind. Angreifer verwenden in der Regel Adressen, die der Domain der Zielwebsite ähneln, um Benutzer zum Klicken zu verleiten. Sie betten bösartigen Code ein, indem sie ihn als Bildladungen oder versteckte Formulare tarnen, leiten Anfragen an die Zielwebsite weiter und führen heimlich unbefugte Aktionen aus. Ziele wie die Änderung von Benutzerpasswörtern oder die Initiierung unbefugter Banküberweisungen können zu erheblichen Verlusten für die Benutzer führen.

Beispiel aus dem wirklichen Leben

Stellen Sie sich eine Website namens e-bank.com vor, die elektronische Bankdienstleistungen anbietet und eine Seite namens /transfer für die Übermittlung von Überweisungsanfragen enthält. Wenn Benutzer auf die Seite e-bank.com/transfer zugreifen, wird ein Formular angezeigt, das die vom Benutzer eingegebenen Details anzeigt. Nachdem das Formular ausgefüllt und übermittelt wurde, wird eine HTTP-POST-Anfrage an die Adresse der Seite gesendet, die Parameter wie den Empfänger und den vom Benutzer eingegebenen Betrag enthält.

An diesem Punkt kann ein Angreifer eine bösartige Seite mit einem unsichtbaren Formular erstellen, das die Übermittlungsadresse auf e-bank.com/transfer verweist. Der Angreifer füllt das Formular im Voraus mit den spezifischen Empfänger- und Betragsparametern aus. Wenn Benutzer dazu verleitet werden, auf diese bösartige Seite zu klicken, führt der Browser JavaScript-Code aus und übermittelt das Formular.

Wenn der Benutzer nicht auf e-bank.com registriert oder angemeldet ist, kann die Überweisungsanfrage nicht ausgeführt werden. Wenn der Benutzer jedoch kürzlich den Dienst genutzt hat und der Anmeldestatus bestehen bleibt, kann die Überweisungsanfrage erfolgreich ausgeführt werden.

Dies fasst CSRF-Angriffe zusammen – einfach im Prinzip, aber mit enormem Schadenspotenzial. Glücklicherweise gibt es zahlreiche ausgereifte Methoden, um solche Angriffe zu verhindern. Lassen Sie uns diese unten erkunden.

Wie können wir CSRF verhindern?

Die Lösung dieses Problems erfordert proaktive und passive Maßnahmen.

HTTP-Methoden- und Referer-Einschränkungen

Als Entwickler können wir strengere Einschränkungen für sensible Adressen innerhalb des Dienstes durchsetzen, wie z.B.:

• Für Adressen, die die Übermittlung von Daten erfordern, die Verwendung von HTTP-GET-Anfragen verbieten und die Verwendung von POST-Anfragen erzwingen. Dies erhöht die Komplexität für Angreifer, die versuchen, bösartige Seiten zu erstellen.

• Darüber hinaus können wir das Referer-Feld im HTTP-Anfrageheader (Referer) einschränken, indem wir es nur von bekannten legitimen Adressen zulassen und bösartige Anfragen blockieren.

Dies stellt eine einfache, proaktive Schutzmaßnahme mit geringen Kosten dar, die jedoch immer noch anfällig für Angriffe ist.

CSRF-Token

CSRF-Token ist eine weit verbreitete Lösung, die serverseitige Sitzungsmechanismen kombiniert, um CSRF-Angriffe zu verhindern. Konkret bettet das serverseitige Programm ein verstecktes Eingabefeld auf Seiten ein, die geschützt werden müssen, mit einem zufällig generierten CSRF-Token im Ausgabeformular. Gleichzeitig wird auf der Serverseite eine Sitzung erstellt, die diesen zufälligen String mit einer Ablaufzeit speichert.

Wenn ein Benutzer die Seite anfordert, initialisiert der Server die Sitzung, speichert Daten auf der Serverseite und setzt ein Cookie im Browser des Clients, das die Sitzungs-ID zur Zuordnung enthält. Der CSRF-Token wird in der Sitzung gespeichert. Bei der Übermittlung des Formulars wird der CSRF-Token gesendet. Das serverseitige Programm vergleicht diesen Token mit dem gespeicherten Teil in der Sitzung. Bei erfolgreicher Validierung wird die nachfolgende Logik ausgeführt; andernfalls wird ein Fehler zurückgegeben. Gleichzeitig wird ein neuer CSRF-Token in das Formular für die nächste Übermittlung eingefügt.

Dies stellt eine proaktive Schutzmaßnahme dar, die einige Anstrengungen erfordert, aber einen robusten Schutz bietet.

Cross-Origin-Schutz

Wir stoßen oft auf eine Technologie namens CORS (Cross-Origin Resource Sharing), eine Spezifikation, die angibt, ob Browser Cross-Origin-Anfragen zulassen. Moderne Browser unterstützen diese Spezifikation. Wenn eine Fetch/XHR-Anfrage auf einer bestehenden Seite initiiert wird, sendet der Browser eine HTTP-OPTIONS-Anfrage, um vorab zu prüfen, ob der Ziel-Dienst Anfragen von der aktuellen Quelladresse zulässt. Der Server wird eine Liste von Antwort-Headern bereitstellen, die zulässige Quellen, Anfragemethoden und Header angeben. Der Browser hält sich an diese Angaben und verhindert verbotene Anfragen auf der Client-Seite.

Dies dient als weitere proaktive Schutzmaßnahme, die auf der Serverseite konfiguriert werden kann, aber beachten Sie, dass normale Benutzer diese Funktion zwar wahrscheinlich nicht deaktivieren, dies auf der Client-Seite jedoch möglich bleibt.

Blockierung von Drittanbieter-Cookies

Dienste, die wir entwickeln, speichern manchmal Benutzer-Sitzungs-IDs in Cookies, um den Anmeldestatus aufrechtzuerhalten. Cookies unterstützen SameSite-Einstellungen, die verhindern, dass der Browser Cookies an Cross-Origin-Sites sendet. Der Versuch, CSRF-Angriffe durchzuführen, führt zu einem nicht authentifizierten Status auf der Zielseite.

Darüber hinaus haben sich Browser-Entwickler aufgrund des Missbrauchs von HTTP-Cookie-Mechanismen zur Client-Verfolgung entschieden, Drittanbieter-Cookies (Cookie Countdown) schrittweise einzuschränken und zu blockieren. Wenn eine Seite auf Domain A versucht, einen Aufruf an Domain B zu tätigen, sendet der Browser, selbst wenn die CORS-Regelprüfungen bestanden werden, keine Cookies an diese Cross-Origin-Site.

Zusammenfassung

Als API-Gateways unterstützen sowohl Apache APISIX als auch API7 Enterprise CSRF-Token und CORS – zwei der zuvor erwähnten Schutzmaßnahmen – um CSRF-Angriffe zu verhindern.

Zusammenfassend lässt sich sagen, dass die Verhinderung von CSRF-Angriffen einen vielschichtigen Ansatz erfordert, der verschiedene Techniken auf der Serverseite, im Browser, im HTTP-Protokoll und mehr kombiniert, um einen umfassenden Schutz zu gewährleisten.