CSRF: Was ist das, wie funktioniert es, Beispiele und Schutzmaßnahmen

Wer im Bereich Webentwicklung oder -sicherheit arbeitet, sollte genau wissen, was Cross-Site Request Forgery ist. CSRF (Cross-Site Request Forgery) Es handelt sich um eine Art Stealth-Angriff, der eine bereits laufende Sitzung des Benutzers ausnutzt, um dessen Browser dazu zu bringen, Aktionen ohne dessen Zustimmung durchzuführen.

Dieses Phänomen ist nicht neu, bleibt aber relevant, da Browser bestimmten Anfragen automatisch Anmeldeinformationen wie Cookies oder Header hinzufügen. Der Server „vertraut“ dem Benutzer und verarbeitet die Anfrage, selbst wenn sie von einer bösartigen Seite, einem iFrame oder einem getarnten Link initiiert wurde.

Was ist CSRF und warum bereitet es immer noch Probleme?

Kurz gesagt, CSRF liegt vor, wenn Website A den Browser eines authentifizierten Benutzers dazu veranlasst, eine Anfrage an Website B zu senden, auf der dieser Benutzer bereits angemeldet ist, sodass B die Operation als gültig verarbeitet. Entscheidend ist das Vertrauen der Website in den Nutzer.nicht das Vertrauen des Nutzers in die Website.

Im Gegensatz zu XSS, das das Vertrauen des Nutzers in eine Seite ausnutzt, um Code in deren Kontext einzuschleusen und auszuführen, missbraucht CSRF die Tatsache, dass der Server jede Anfrage akzeptiert, die mit einem bestimmten Parameter eingeht. gültige Anmeldeinformationen (z. B. Session-Cookies)Beide Probleme können sich gegenseitig verstärken und die Auswirkungen verschlimmern.

Ein wenig Geschichte und forensische Schwierigkeiten

Derartige Schwachstellen sind seit Ende der 90er Jahre bekannt, und der Begriff CSRF/XSRF wurde 2001 von Peter Watkins geprägt. Die Spuren des Angriffs weisen in der Regel auf die legitime IP-Adresse hin. vom Benutzer, was die Zuordnung von Verantwortlichkeiten erschwert und eine spezialisierte forensische Analyse erfordert.

Jahrelang gab es nur wenige gut dokumentierte öffentliche Fälle von Sicherheitslücken, doch das Problem trat immer wieder auf und ist mehrfach in Erscheinung getreten. OWASP Top 10 aufgrund seiner Auswirkungen und Häufigkeit.

Wie der Angriff funktioniert (Bedingungen und Ablauf)

Für einen erfolgreichen CSRF-Angriff müssen mehrere Bedingungen erfüllt sein. Der Benutzer muss in der Zielanwendung angemeldet bleiben; der Browser muss automatisch eine Sicherheitslücke schließen. Cookies, Basis-/Digest-Anmeldeinformationen oder Authentifizierungskontext in den Anfragen; und die Anwendung akzeptiert Zustandsänderungen ohne zusätzlichen Verifizierungsmechanismus.

Der Angreifer verleitet das Opfer durch Social Engineering (z. B. per E-Mail, Chat oder über eine attraktive Website) dazu, eine Seite aufzurufen, die die schädliche Anfrage an die anfällige Website auslöst. Der Benutzer kann nichts tun. Mehr als nur der Besuch der Seite: Ein selbst ausgefülltes Formular, ein eingebettetes Bild oder ein iFrame genügen, um die Anfrage auszulösen.

Typische Vektoren: GET, POST und sogar „gespeichert“.

Leider ändern manche Anwendungen ihren Zustand mithilfe von GET. In diesem Fall genügt ein einfacher Auf einer Drittanbieterseite wird die Aktion beim Laden des Bildes ausgeführt. Daher sollte eine GET-Anfrage grundsätzlich keine Ressourcen verändern.

Bei POST handelt es sich üblicherweise um ein getarntes HTML-Formular, das entweder mit JavaScript automatisch übermittelt wird oder vom Benutzer in der Annahme, es handle sich um etwas anderes, abgeschickt wird. Der Browser speichert den Session-Cookie. der legitimen Domain und der Server verarbeitet die Änderung (Geld überweisen, einen Datensatz löschen, eine E-Mail-Adresse ändern usw.).

Manchmal kann der Angriffscode (aufgrund zusätzlicher Sicherheitslücken) in die eigene Website des Opfers eingebunden werden, indem er in IMG-Tags oder iFrames gehostet wird. Dieser „gespeicherte CSRF“ Es mindert Misstrauen, da die Interaktion scheinbar im Bereich des Vertrauens verbleibt.

Reale Auswirkungen auf Konten und Systeme

Die Folgen reichen von unautorisierten Finanztransaktionen über Konfigurationsänderungen, Neuzuweisung von Berechtigungen bis hin zur Löschung von Daten. Wenn das Opfer über eine Administratorrolle verfügtDer Angreifer kann die Anwendungslogik verändern oder Hintertüren aktivieren, die weitere Benutzer betreffen.

Selbst scheinbar geringfügige Aktionen, wie beispielsweise die Änderung der E-Mail-Adresse im Profil, können die Wiederherstellung des Kontos verhindern oder nachfolgenden Betrug erleichtern. Das Hauptproblem besteht darin, dass alles „im Namen des Benutzers“ geschieht. und oft, ohne dass er es merkte.

Konkrete (und sehr häufige) Beispiele

Stellen Sie sich ein Administrationspanel vor, mit dem Sie einen Benutzer per GET-Anfrage über eine URL wie /users/delete/63 löschen können. Wenn ein authentifizierter Administrator eine Drittanbieterseite besucht, die eine solche URL enthält, … Der Browser wird die Anfrage stellen und das Konto wird verschwinden.

Ein weiterer Klassiker: Online-Banking. Wenn eine Überweisung mit GET orchestriert werden kann – zum Beispiel, /transfer?amount=500&account=XXXX—Ein scheinbar harmloser Link genügt, damit ein eingeloggter Benutzer die Überweisung von Geld auf das Konto des Angreifers auslöst.

Bei POST ist das Vorgehen ähnlich: Ein verstecktes Formular mit den Feldern „Betrag“ und „Konto“ wird beim Laden der Seite automatisch übermittelt. Sitzungscookie der Bank von der legitimen Domain und der Server verarbeitet die Übertragung.

Browser- und Protokollfaktoren

Die Verwendung von HTTPS allein verhindert den Angriff nicht: Eine bösartige Website kann den Browser leicht dazu bringen, eine sichere Anfrage zu stellen. Auch die Basisauthentifizierung und der Digest-Algorithmus sind anfällig.Sobald sich der Benutzer authentifiziert hat, leitet der Browser die Anmeldeinformationen automatisch weiter, bis die Sitzung beendet ist.

SameSite-Cookie-Richtlinien sind hilfreich, aber es gibt Feinheiten. Bei SameSite=Strict sendet der Browser den Cookie nicht in seitenübergreifenden Kontexten und Ein großer Teil des CSRF wird an der Wurzel abgeschnitten.Bei SameSite=None (und Secure) wird der Cookie jedoch zwischen Websites übertragen und vergrößert so die Angriffsfläche.

Bewährte Vorgehensweisen für Benutzer

Obwohl das Problem grundsätzlich bei der Anwendung liegt, gibt es Gewohnheiten, die das Risiko verringern. Nach Gebrauch abmeldenDurch das gelegentliche Löschen von Cookies und das Vermeiden der Option „Angemeldet bleiben“ werden die Angriffsfenster minimiert.

Es hilft auch, Aufgaben zu trennen: Verwenden Sie einen Browser für sensible Aufgaben und einen anderen für allgemeines Surfen, oder verwenden Sie den Inkognitomodus, um das Speichern von Anmeldeinformationen zu vermeidenErweiterungen, die Skripte blockieren, schränken die Automatisierung ein (obwohl sie keine vollständige Lösung darstellen).

Abwehrmaßnahmen für Anträge

Erste goldene Regel: Ändern Sie den Zustand nicht mit GET.Die Reservierung von POST/PUT/DELETE für Operationen, die Ressourcen verändern, reduziert triviale Angriffsvektoren wie Bilder oder versteckte Links.

Der am weitesten verbreitete Ansatz zur Minderung von CSRF ist das Synchronizer-Token-Muster: Der Server stellt ein eindeutiges, zufälliges Token aus, das mit der Identität des Benutzers verknüpft ist, und der Client sendet es in der nächsten zustandsverändernden Anfrage zurück. Wenn das Token nicht übereinstimmt Die Anfrage wurde aufgrund der Identitäts- und Cookie-Informationen abgelehnt.

Eine weitere nützliche Ebene ist die Validierung der Ursprünge: Dabei werden die Origin-/Referer-Header überprüft, sofern vorhanden. Stammt die Anfrage nicht von der erwarteten Domain, Die Verarbeitung ist blockiertHinweis: Einige Clients verbergen den Referrer aus Datenschutzgründen, daher muss diese Überprüfung sorgfältig durchgeführt werden.

WAFs sind ebenfalls hilfreich. Unternehmenslösungen wie beispielsweise F5 BIG-IP ASM oder in Hosting-Plattformen integrierte Schutzdienste, Regeln hinzufügen, um verdächtige Muster zu erkennen und zu stoppen, bevor sie Ihre App erreichen.

Grenzen und häufige Fehler bei Tokens

Tokens bieten Schutz, sofern sie korrekt implementiert sind. Wenn die Anwendung den Verifizierungsprozess umgeht, weil ein Token fehlt, muss der Angreifer lediglich ein leeres Token senden. Die Nutzung eines wiederverwendbaren Pools ist genauso gefährlich. Statt eines Tokens pro Benutzer: Man stiehlt einfach einen gültigen Token, um die Sitzungen anderer Benutzer zu imitieren.

Das Speichern des Tokens in einem Cookie, auf das JavaScript zugreifen kann, ist ebenfalls keine gute Idee, wenn keine Kontrollmechanismen vorhanden sind: Ein XSS-Angriff könnte es auslesen. und wiederverwenden. Robustheit wird dadurch erreicht, dass Session-Cookie und Token in einem separaten Formular oder Header kombiniert und beides validiert wird.

Beziehung zu SPA, Tokens und XSS

Bei Anwendungen mit tokenbasierter Authentifizierung (z. B. JWT) senden Sie das Token im Authorization-Header als Bearer und nicht in einem Keks Dadurch wird das Risiko von CSRF-Angriffen verringert, da der Browser die Sicherheitslücke nicht automatisch anhängt. Trotzdem könnte ein Angreifer im Falle eines XSS-Angriffs die Sicherheitslücke aus dem Browser stehlen. Lagerung Lokale.

Daher ist es neben der CSRF-Abwehr notwendig, den Serverausgang zu sichern und Angriffe zu verhindern. Unmaskiertes HTML rendern und wenden Sie CSP an. CSRF und XSS verstärken sich gegenseitig, wenn Sie auf beiden Seiten Lücken lassen.

CSRF in ASP.NET Core: Das Wichtigste für Entwickler

ASP.NET Core beinhaltet integrierte Schutzmechanismen. Formulare mit der Methode "post" können automatisch Anti-Forgery-Token in Razor-Ansichten einfügen (TagHelpers und Hilfsmethoden wie BeginForm fügen diese standardmäßig ein). Sie können sie auch explizit einfügen. und validieren Sie auf dem Server mithilfe von Filtern.

Die Validierung wird mit Attributen wie ValidateAntiForgeryToken oder, bequemer, AutoValidateAntiforgeryToken aktiviert, wodurch ein Token in unsicheren Methoden (POST/PUT/DELETE) erforderlich ist und die Anforderung in GET/HEAD/OPTIONS/TRACE vermieden wird. Falls Sie Ausnahmen benötigen, IgnoreAntiforgeryToken hebt die Anforderung konkreter Aktionen auf.

Für APIs und SPAs ermöglicht der IAntiforgery-Dienst das Generieren und Speichern von Tokens und deren Empfang in einem benutzerdefinierten Header (zum Beispiel, X-XSRF-TOKENFrameworks wie Angular lesen üblicherweise ein „XSRF-TOKEN“-Cookie und senden dessen Wert in diesem Header, den der Server validieren muss.

Minimal-APIs können das Token explizit validieren (mittels Middleware oder Endpunktfiltern), und es ist ratsam, die Anti-Fälschungs-Middleware auszuführen. nach Authentifizierung und AutorisierungDas unnötige Lesen des Anfragetextes sollte vermieden werden, sofern dies nicht angebracht ist.

Feinkonfiguration: Mit AntiforgeryOptions können Sie den Namen des versteckten Feldes, den erwarteten Header und die Ausgabe des X-Frame-Options-Headers (standardmäßig SAMEORIGIN) anpassen. Während der Entwicklung tritt die Marke Secure manchmal in den Hintergrund. des Cookies; in realen Umgebungen wird empfohlen, HTTPS zu erzwingen.

Beachten Sie, dass bei Verwendung des Synchronisierungstoken-Musters das Öffnen mehrerer Tabs und das Navigieren durch verschiedene Abläufe die Gültigkeit vorheriger Token beeinträchtigen kann: nur die neueste Seite Es verfügt in der Regel über ein gültiges Token. Ziehen Sie Alternativen in Betracht, wenn Ihre Benutzererfahrung auf mehreren gleichzeitig geöffneten Tabs basiert.

Ein weiterer Bereich, auf den man achten sollte, ist Shared Hosting unter derselben Domain oder Subdomain. Teilen Sie *.domain.com Dadurch kann eine App die Cookies einer anderen App beeinflussen, daher erhöht die Trennung von Apps durch verschiedene Domains die Isolation.

Schließlich die Authentifizierung von Windows (NTLM/Kerberos) befreit Sie nicht: Der Browser sendet implizit den Authentifizierungskontext und, ohne Token oder Ursprungsprüfungen, CSRF kann ebenfalls vorhanden sein.

CDN, Crossloading und warum Vorsicht geboten ist

Es ist üblich, dass eine Website Inhalte von Drittanbietern anfordert (YouTube-Videos, CDN-Bibliotheken usw.). Wenn dieser Austausch nicht ordnungsgemäß kontrolliert wirdEin Angreifer kann Cross-Site-Routen ausnutzen, um Anfragen zu erzwingen, die der Browser mit angehängten Anmeldeinformationen abschließt.

Neben strengen Cookie-Richtlinien sollten Sie die Verwendung von iFrames und eingebetteten Objekten überprüfen und SRI bei der Verwendung von CDNs anwenden. Grenzen akzeptierte Ursprünge mit klar definierten CSP- und CORS-Standards.

Zusätzliche bewährte Praktiken für Teams

Führen Sie Sicherheitsüberprüfungen für Formularänderungen und Endpunkte ein, die den Zustand ändern. Automatisierte Tests die das Vorhandensein und die korrekte Validierung des Tokens überprüfen und jede Regression, die GET mit Nebenwirkungen wieder einführt, als „blockierend“ kennzeichnen.

Es verwendet Protokollierung, um ungewöhnliche Muster zu erkennen (z. B. Formularübermittlungen ohne Token oder mit unerwarteten Quell-Headern) und Unterstützung durch eine WAF Das reduziert Störungen und unterbindet bekannte Ausbeutungspraktiken.

Wichtiger Hinweis: Was CSRF allein nicht löst

Das Anti-Fälschungs-Token behebt weder das Problem der Skripteinschleusung noch ersetzt es die Autorisierungskontrollen. Zunächst sollte überprüft werden, ob der Benutzer die Aktion ausführen kann.Anschließend das Token validieren und gegebenenfalls Ursprung/Referrer überprüfen. Sicherheit geht vor.

Und vergessen Sie nicht, dem Produktteam den Grund dafür zu erläutern: Das Vermeiden von GET-Anfragen, die den Zustand ändern, oder das Anfordern eines zusätzlichen Tokens bei bestimmten Operationen ist keine rein technische Laune. Es handelt sich um einen direkten Schutz des Unternehmens. gegen Betrug und Manipulation.

Die Gefährlichkeit von CSRF liegt in seiner Heimlichkeit: Die Anfragen stammen vom Browser des Opfers, verwenden dessen Zugangsdaten und wirken legitim. gut implementierte TokenUrsprungsvalidierung, angemessene Cookie-Richtlinien, verantwortungsvolles REST-Design und, wo angebracht, WAF-Schutz reduzieren das Angriffsfenster drastisch, ohne die Benutzerfreundlichkeit zu beeinträchtigen.