Glossar

Cross Site Request Forgery (CSRF)

Was ist CSRF?

Cross-Site Request Forgery wird oft mit CSRF abgekürzt und bedeutet auf Deutsch Website-übergreifende Anfragenfälschung. Hierbei handelt es sich um einen möglichen Angriff, wenn eine bösartige Website, E-Mail-Nachricht, Sofortnachricht, Webanwendung oder ein bösartige Blog eine unerwünschte Aktion eines Webbrowsers auf einer vertrauenswürdigen Seite verursacht, bei der ein Benutzer aktuell authentifiziert ist. Die Folgen eines CSRF-Angriffs sind davon abhängig, in welchem Ausmaß die anfällige Anwendung getroffen wird. Im einfachsten Fall setzen Angreifer CSRF-Angriffe ein, um zu erreichen, dass ein Zielsystem verfügbare und bösartige Funktionen über den Browser des Ziels ausführt, ohne dass der Zielbenutzer dies weiß. Diese Funktion ist dem Opfer in der Regel erst nach ihrem Auftreten bekannt.

Durch eine CSRF-Schwachstelle kann ein Angreifer einen authentifizierten, angemeldeten Benutzer dazu zwingen, eine wichtige Aktion ohne dessen Zustimmung oder Wissen auszuführen. Es ist das digitale Äquivalent zu jemandem, der die Unterschrift eines Opfers auf einem wichtigen Dokument fälscht, mit dem Unterschied, dass es effektiver ist, weil der Angreifer keine Spuren hinterlässt. Dies liegt daran, dass die gefälschte Anfrage alle Informationen enthält und von derselben IP-Adresse stammt wie eine echte Anfrage des Opfers. In der Konsequenz heißt das: Jede Anwendung, mit der ein Benutzer Daten senden oder aktualisieren kann, ist ein mögliches Ziel für einen Angreifer.

Wichtig bei CSRF ist, dass diese Angriffe nur funktionieren, wenn das Opfer auf der Zielwebsite angemeldet ist. Das mag für Angreifer eine Erschwernis darstellen, aber auf vielen Websites können Benutzer so etwas wie „Angemeldet bleiben“ anklicken. Dadurch wird der Zeitraum, in dem ein CSRF-Angriff erfolgen kann, massiv ausgedehnt.

Mögliche schädliche Einsätze von CSRF

Das häufigste Ziel einer CSRF ist Diebstahl – entweder geht es um Daten, Identitäten oder Finanzen. Hier sind einige der häufigsten Fälle für CSRF:

  • Überweisen von Geld von einem Bankkonto auf ein anderes: Ihre Online-Sitzung bei Ihrer Bank wird kompromittiert und behandelt einen Auftrag als legitim und sendet 1.000 USD von Ihrem Konto an Martins Konto. Alles weist darauf hin, dass Sie diese Transaktion legitim über Ihren angemeldeten Browser ausgeführt haben.
  • Hinzufügen/Löschen von Inhalten auf einer Website mithilfe eines Content-Management-Systems: Falls das Opfer ein Benutzer mit Administratorrechten ist, bringt der Angreifer die gesamte Website unter seine Kontrolle.
  • Ändern des Passworts eines Benutzers: Wenn jemand bei seinem Konto angemeldet ist, kann der Angreifer ganz einfach eine Anfrage zum Ändern der E-Mail fälschen. Sobald diese bearbeitet wurde und wenn der Angreifer auch eine Anfrage zum Zurücksetzen des Passworts fälscht, kann er so nach und nach die volle Kontrolle über das Konto des Opfers übernehmen.
  • Hinzufügen von Artikeln zum Warenkorb eines Benutzers oder Ändern der Lieferadresse einer Bestellung: Auf vielen Websites gibt es eine „Mein Konto“- oder eine ähnliche Seite, auf der die Informationen eines Benutzers gespeichert werden. Häufig können Benutzer dort auch ihre Adresse ändern oder ihren Einkaufswagen anpassen. Mit einer CSRF kann ein Angreifer diese Informationen anpassen. Auf der Website sieht es dann so aus, als hätte das Opfer die Änderungen vorgenommen.

CSRF-Schwachstellen verhindern

Cross-Site Request Forgery kann vornehmlich durch zwei Methoden verhindert werden:

  1. Aufhalten, dass der Browser Cookies von Drittanbietern an die Webanwendung sendet
  2. Synchronisieren des Cookies mit einem CSRF-Schutz-Token, das dem Browser bereits bereitgestellt wurde
  3. Anfordern einer „Challenge-Response“, was häufig in Verbindung mit den beiden anderen Präventionsmethoden zum Einsatz kommt.

Methode Nr. 1: Same-Site-Cookies

Das Same-Site-Cookie-Attribut wurde gerade erst neu entwickelt und kann für Cookies gesetzt werden, damit der Browser für bestimmte Cookies die Verwendung durch Dritte deaktiviert. Das Attribut wird vom Server festgelegt, während gleichzeitig das Cookie selbst gesetzt wird und sendet eine Anfrage an den Browser, das Cookie nur in eigenen Kontexten zu senden. Aus diesem Grund muss die Anfrage vom gleichen Standort stammen und daher können Anfragen von Seiten Dritter das Same-Site-Cookie nicht enthalten. Auf diese Weise werden CSRF effektiv beseitigt, ohne dass Synchronizer-Tokens erforderlich wären. Einziger Nachteil bei dieser Methode ist, dass Same-Site-Cookies nur in einigen modernen Browsern verfügbar sind.

Methode Nr. 2: Anti-CSRF-Tokens

Ein Anti-CSRF-Token ist die empfohlene und am weitesten verbreitete Präventionsmethode für Cross-Site Request Forgery. Diese Tokens werden auch als Synchronizer-Tokens bezeichnet. Wenn ein Benutzer Informationen sendet, mit der Site interagiert oder etwas anderes tut, das ein Cookie generiert, sollte das Anti-CSRF-Token auch in der Cookie-Anfrage enthalten sein. Bevor die Anfrage verarbeitet wird, wird sie geprüft und dabei die Authentizität oder sogar das Vorhandensein dieses Tokens überprüft. Wenn das Token fehlt oder falsch ist, kann die Anfrage abgelehnt werden.

Damit bei Anti-CSRF-Tokens die Qualität des Schutzes gewährleistet ist, muss die Bibliothek bekannter Token unbedingt regelmäßig aktualisiert werden, um vorhandene Bedrohungen zu reflektieren. Viele dieser Bibliotheken sind Open Source und leicht zugänglich. Idealerweise werden zum Schutz vor einem CSRF-Angriff beide Methoden miteinander kombiniert.

Methode Nr. 3: Challenge-Response

Als zusätzliche Schutzschicht können Benutzer beim Senden eines Formulars zu einer Sicherheitsabfrage aufgefordert werden. Es gibt zum Beispiel Folgende Challenge-Response-Verfahren:

  • Erneute Authentifizierung des Passwortes oder persönlicher Daten
  • CAPTCHA-Validierung
  • Ausstellung eines Einmal-Tokens

Challenge-Response kann CSRF-Angriffe zwar durchaus wirksam abschrecken, wenn es entsprechend konzipiert und implementiert wird, hat jedoch Auswirkungen auf das Benutzererlebnis. Bei Anwendungen mit hohen Sicherheitsanforderungen sollten, um diese durchzusetzen, sowohl Tokens als auch Challenge-Response eingesetzt werden.

Warum das Thema CSRF wichtig ist

CSRF-Angriffe lassen sich auf eine Vielzahl von Websites anwenden. Wenn eine Site das Ändern von Daten auf der Benutzerseite zulässt, ist das für Angreifer ein potenzielles Ziel. Mit einigen der oben aufgeführten Methoden kann die Sicherheit Ihrer Website um ein Vielfaches erhöht werden.

Die Folgen eines erfolgreichen CSRF-Angriffs können je nach Berechtigungen des Opfers sehr unterschiedlich sein. War das Ziel ein einfacher Benutzer, kann alles, von persönlichen Informationen bis zu Site-Berechtigungen, gefährdet sein. Das mag schlimm klingen. Wenn aber das Konto eines Administrators kompromittiert wird, kann ein Angriff die gesamte Site lahm legen. Das zeigt also das mögliche Ausmaß eines Angriffs und warum CSRF-Schutz ein wesentlicher Bestandteil jedes Sicherheitspakets für Webanwendungen ist.

CSRF – weiterführende Ressourcen

Weiterführende Ressourcen

Wie Barracuda Sie unterstützen kann

Die Barracuda Web Application Firewall schützt Ihre Website und Webanwendungen automatisch vor CSRF-Angriffen und Tausenden anderer Cyber-Bedrohungen, darunter auch OWASP-Top-10-Bedrohungen. Wenn Sie noch keine Web Application Firewall haben, fordern Sie gerne eine kostenlose Testversion von Barracuda an. Außerdem haben Sie die Möglichkeit, Ihre Website mit dem Barracuda Vulnerability Manager kostenlos zu scannen und so zu überprüfen, ob sie für einen CSRF-Angriff anfällig ist.

Neben firewallbasiertem Schutz bietet Barracuda auch im Rahmen des Barracuda Load Balancer ADC CSRF-Schutz an. Der Load-Balancer ist eine Lösung für sichere Applikationsbereitstellung, mit der die Verfügbarkeit, Beschleunigung und Kontrolle von Websites gewährleistet wird. Automatische Updates gewährleisten umfassenden Schutz vor bestehenden und neu hinzukommende Layer-7-Bedrohungen wie Cross-Site Scripting, SQL-Injections und Cross-Site Request Forgery.

Haben Sie weitere Fragen zum Thema Cross-Site Request Forgery? Wir freuen uns auf Ihre Nachricht!