Beim Arbeiten in der Webentwicklung, insbesondere mit Cookies, hören wir oft Sätze wie "diese Einstellung hilft, CSRF zu verhindern". Viele Menschen haben jedoch nur eine vage Vorstellung davon, was "CSRF" wirklich bedeutet.
Heute werden wir einen tiefen Einblick in CSRF (Cross-Site Request Forgery), einen häufigen Websicherheitsfehler, nehmen. Dies wird uns helfen, CSRF-bezogene Probleme effektiver zu handhaben.
Was ist CSRF?#
CSRF (Cross-Site Request Forgery) ist eine Art von Webangriff, bei dem Angreifer authentifizierte Benutzer dazu bringen, unbeabsichtigte Aktionen auszuführen. Einfach gesagt: "Hacker geben sich als Benutzer aus, um unautorisierte Aktionen durchzuführen".
Wie funktioniert CSRF#
Um CSRF zu verstehen, müssen wir einige Schlüsselkonzepte begreifen:
Gleicher-Ursprung-Politik des Browsers#
Die Gleicher-Ursprung-Politik ist ein Sicherheitsmerkmal in Browsern, das einschränkt, wie ein Dokument oder Skript aus einem Ursprung mit Ressourcen aus einem anderen Ursprung interagieren kann.
Ein Ursprung besteht aus einem Protokoll (wie HTTP oder HTTPS), einem Domainnamen und einer Portnummer. Zum Beispiel ist https://example.com:443 ein Ursprung, während https://demo.com:80 ein anderer ist.
Die Gleicher-Ursprung-Politik beschränkt den Datenzugriff zwischen Seiten von verschiedenen Ursprüngen, was bedeutet:
- JavaScript von einem Ursprung kann das DOM eines anderen Ursprungs nicht lesen
- JavaScript von einem Ursprung kann die Cookies, IndexedDB oder den localStorage eines anderen Ursprungs nicht lesen
- JavaScript von einem Ursprung kann keine AJAX-Anfragen an einen anderen Ursprung senden (es sei denn, CORS wird verwendet)
Um jedoch die Offenheit und Interoperabilität des Webs aufrechtzuerhalten (wie das Laden von Ressourcen von CDNs oder das Senden von Anfragen an Drittanbieter-APIs zum Protokollieren), beschränkt die Gleicher-Ursprung-Politik nicht grenzüberschreitende Netzwerkzugriffe:
- Seiten können GET- oder POST-Anfragen an jeden Ursprung senden (wie Bilder laden oder Formulare absenden)
- Ressourcen aus jedem Ursprung können eingebunden werden (wie
<script>, <img>, <link>, <iframe> Tags)
Automatischer Cookie-Sendemechanismus#
Der automatische Cookie-Sendemechanismus ist ein wichtiges Merkmal von Browsern. Wenn ein Browser eine Anfrage an eine Domain sendet, fügt er automatisch alle Cookies für diese Domain hinzu. Dieser Prozess ist automatisch und erfordert keinen JavaScript-Code oder Benutzereingriffe.
Dieser Mechanismus ermöglicht es Websites, den Anmeldestatus der Benutzer einfach zu behalten, da jede Anfrage automatisch die Identitätsinformationen des Benutzers trägt.
Fett
Wenn du dich beispielsweise bei einer Bankseite (bank.com) anmeldest und ein Identitäts-Cookie erhältst, sucht der Browser automatisch alle Cookies, die mit bank.com übereinstimmen, und fügt sie der Anfrage zum Ansehen deines Kontoauszugs hinzu. Der Server der Bank kann dich anschließend aus dem Backend identifizieren und deine Kontoauszugsinformationen zurückgeben.
CSRF-Angriffsschritte#
-
Der Benutzer meldet sich auf der Zielwebsite (wie einer Bankseite) an und erhält ein Authentifizierungs-Cookie.
Dieser Schritt verwendet den automatischen Cookie-Sendemechanismus. Nachdem die Bankseite ein Identitätsauthentifizierungs-Cookie gesetzt hat, fügt der Browser dieses Cookie automatisch jeder an diese Seite gesendeten Anfrage bei.
-
Ohne sich abzumelden, besucht der Benutzer eine bösartige Website.
Zu diesem Zeitpunkt kann die bösartige Seite aufgrund der Gleicher-Ursprung-Politik das Cookie der Bankseite nicht direkt lesen oder ändern. Dies schützt die Identitätsinformationen des Benutzers vor direktem Diebstahl.
-
Die bösartige Seite enthält eine Anfrage an die Zielseite (wie einen Überweisungsvorgang).
Obwohl die Gleicher-Ursprung-Politik den grenzüberschreitenden Zugriff einschränkt, erlaubt sie grenzüberschreitende Netzwerkzugriffe, wie Anfragen, die über <img>, <form> Tags initiiert werden. Angreifer nutzen dieses "Schlupfloch" aus.
-
Der Browser des Benutzers sendet diese Anfrage automatisch zusammen mit dem Cookie der Zielseite.
Dies ist der Kern des CSRF-Angriffs. Er nutzt die Gleicher-Ursprung-Politik, die grenzüberschreitende Anfragen zulässt, und den automatischen Cookie-Sendemechanismus (selbst von bösartigen Seiten ausgelöste Anfragen tragen Cookies, die zur Domain passen).
-
Die Zielseite erhält die Anfrage, überprüft, ob das Cookie gültig ist, und führt die Operation aus.
Der Server kann nicht erkennen, ob diese Anfrage von einer legitimen Benutzeraktion stammt, da das beigefügte Cookie gültig ist.
Beispiel eines CSRF-Angriffs#
Lassen Sie uns veranschaulichen, wie ein CSRF-Angriff stattfindet, indem wir ein spezifisches Beispiel verwenden. Wir verwenden eine fiktive Bankwebsite bank.com als Beispiel.
Zuerst besucht der Benutzer https://bank.com und meldet sich bei seinem Konto an.
Nach erfolgreicher Anmeldung setzt der Server ein Authentifizierungs-Cookie, zum Beispiel:
Der Benutzer führt eine Überweisung auf der Bankwebsite durch, zum Beispiel $1000 an Alice. Diese Operation könnte eine Anfrage wie diese senden:
Angenommen, ein Angreifer erstellt eine bösartige Website https://evil.com mit folgendem HTML:
Wenn der Benutzer den https://evil.com Link anklickt, ohne sich aus seinem Bankkonto abzumelden, da er bereits bei bank.com eingeloggt ist, hat der Browser ein gültiges session_id Cookie.
Nachdem die bösartige Seite geladen wurde, übermittelt sie das versteckte Formular automatisch und sendet eine Überweisungsanfrage an https://bank.com/transfer.
Der Browser des Benutzers fügt dieser Anfrage automatisch das bank.com Cookie hinzu. Der bank.com Server erhält die Anfrage, überprüft, ob das Cookie gültig ist, und führt dann diese unautorisierte Überweisungsoperation aus.
Häufige Methoden zur Verhinderung von CSRF-Angriffen#
Hier sind mehrere häufig verwendete CSRF-Abwehrmethoden. Wir werden das Prinzip jeder Methode im Detail erklären und wie sie CSRF-Angriffe wirksam verhindern:
Verwendung von CSRF-Tokens#
CSRF-Tokens sind eine der gebräuchlichsten und wirksamsten Methoden, um CSRF-Angriffe zu verteidigen. So funktioniert es:
- Der Server generiert ein einzigartiges, unvorhersehbares Token für jede Sitzung.
- Dieses Token wird in alle Formulare für sensible Operationen eingebettet.
- Wenn der Benutzer ein Formular übermittelt, überprüft der Server die Gültigkeit des Tokens.
Da das CSRF-Token ein einzigartiger Wert ist, der mit der Benutzersitzung verknüpft ist, und der Angreifer diesen Wert nicht kennen oder erraten kann (da er für jede Sitzung unterschiedlich ist), wird die Anfrage, selbst wenn der Angreifer den Benutzer dazu bringt, eine Anfrage zu senden, von dem Server aufgrund des fehlenden gültigen CSRF-Tokens abgelehnt.
Implementierungsbeispiel:
Auf der Serverseite (mit Node.js und Express):
In Frontend JavaScript:
Der Referer-Header enthält die URL der Seite, die die Anfrage initiiert hat. Indem der Referer-Header überprüft wird, kann der Server feststellen, ob die Anfrage aus einer legitimen Quelle stammt.
Da CSRF-Angriffe normalerweise von verschiedenen Domains kommen, wird der Referer-Header den Domainnamen des Angreifers anzeigen. Indem überprüft wird, ob der Referer der erwartete Wert ist, können Anfragen aus unbekannten Quellen blockiert werden.
Es ist jedoch zu beachten, dass diese Methode nicht vollständig zuverlässig ist, da einige Browser den Referer-Header möglicherweise nicht senden und Benutzer den Referer-Header über die Browser-Einstellungen oder Plugins deaktivieren können.
Implementierungsbeispiel:
Verwenden des SameSite Cookie-Attributs#
SameSite ist ein Cookie-Attribut, das verwendet wird, um zu steuern, ob Cookies mit plattformübergreifenden Anfragen gesendet werden. Es gibt drei mögliche Werte:
Strict: Cookies werden nur bei gleichseitigen Anfragen gesendet.Lax: Cookies werden bei gleichseitigen Anfragen und in der obersten Navigationsebene gesendet.None: Cookies werden in allen plattformübergreifenden Anfragen gesendet (müssen mit dem Secure-Attribut verwendet werden).
Wenn SameSite auf Strict gesetzt ist, kann es vollständig verhindern, dass Drittanbieter-Websites Cookies senden, und so effektiv CSRF-Angriffe verhindern.
Wenn SameSite auf Lax gesetzt ist, schützt es sensible Operationen, während einige gemeinsame Cross-Site-Anwendungen (wie das Betreten einer Webseite von externen Links) erlaubt werden.
Implementierungsbeispiel:
Für AJAX-Anfragen können benutzerdefinierte Anforderungsheader hinzugefügt werden. Aufgrund der Einschränkungen der Gleicher-Ursprung-Politik können Angreifer keine benutzerdefinierten Header in plattformübergreifenden Anfragen setzen. Der Server kann das Vorhandensein dieses benutzerdefinierten Headers überprüfen, um die Legitimität der Anfrage zu überprüfen.
Implementierungsbeispiel:
Auf der Frontend-Seite:
Auf der Serverseite:
Doppelte Cookie-Überprüfung#
Die doppelte Cookie-Überprüfung ist eine effektive CSRF-Abwehrtechnik. Ihr Kernprinzip besteht darin, dass der Server ein zufälliges Token generiert, es sowohl als Cookie setzt als auch es in die Seite einbettet (normalerweise als verstecktes Formularfeld). Wenn der Browser eine Anfrage sendet, fügt er automatisch das Cookie hinzu, während das JavaScript der Seite das Token als Anforderungsparameter sendet. Der Server überprüft dann, ob das Token im Cookie mit dem Token in den Anfrageparametern übereinstimmt.
Obwohl Angreifer das Cookie der Zielwebsite in plattformübergreifenden Anfragen einfügen können, können sie den Cookie-Wert weder lesen noch ändern, noch können sie auf den Token-Wert auf der Seite zugreifen oder ihn ändern. Indem gefordert wird, dass die Anfrage sowohl Tokens vom Cookie als auch aus den Parametern enthält, wird sichergestellt, dass die Anfrage von einer Quelle stammt, die die Berechtigung hat, das Cookie zu lesen, und somit CSRF-Angriffe wirksam abwehrt.
Verwendung erneuter Authentifizierung für sensible Operationen#
Für besonders sensible Operationen (wie das Ändern von Passwörtern oder das Tätigen großer Überweisungen) können Benutzer aufgefordert werden, sich erneut zu authentifizieren.
Dies bietet den Benutzern einen zusätzlichen Sicherheitsüberprüfungspunkt. Selbst wenn ein Benutzer erfolgreich einen CSRF-Angriff initiiert, kann er den Authentifizierungsschritt nicht passieren.
Implementierungsvorschläge:
- Vor der Durchführung sensibler Operationen auf eine separate Authentifizierungsseite umleiten.
- Auf dieser Seite den Benutzer auffordern, ihr Passwort oder andere Identitätsüberprüfungsinformationen einzugeben.
- Nach erfolgreicher Überprüfung einen Einmaltoken generieren und dieses Token in nachfolgenden sensiblen Operationen verwenden.
Zusammenfassung#
Durch diese eingehende Diskussion hoffen wir, dass du nun ein umfassenderes Verständnis von CSRF-Angriffen hast.
Wir haben nicht nur gelernt, wie CSRF funktioniert, sondern auch verschiedene wirksame Abwehrmaßnahmen erkundet. All diese Methoden können die Sicherheit von Webanwendungen effektiv erhöhen.
Wir hoffen, dass dieses Wissen dir hilft, CSRF-bezogene Probleme in deiner täglichen Entwicklung besser zu lösen und sicherere Webanwendungen zu erstellen.
