zurück zur Übersicht

Effektive Abwehr gegen CSRF Attacken

Cross-Site Request Forgery (CSRF) Attacken gehören zu den häufigsten Angriffen auf Webanwendungen. Dennoch werden sie gern unterschätzt.

Aus diesem Grund haben wir dem Thema bereits zwei Artikel gewidmet. In dem ersten Artikel über CSRF Attacken hier wiesen wir auf die gründlichen Missverständnisse bezüglich CSRF Attacken hin. In dem zweiten Teil haben wir uns mit Abwehrmechanismen beschäftigt, die nur begrenzt effektiv sind.

In diesem letzten Artikel werden wir uns auf die effektive Abwehr konzentrieren. Da CSRF ein Design- bzw. architekturelles Problem ist, setzen die richtigen Mechanismen auf Prüfungen auf einem Server innerhalb oder außerhalb der Anwendung. Anders formuliert – die Prüfungslogik kann nicht nur auf dem Client implementiert werden.

Drei Wege für die Abwehr

Generell können die Abwehrmechanismen wie folgt klassifiziert werden:

  • Prüfung von HTTP Headers (Same Origin)
  • Anti-CSRF Token
  • Re-Authentifizierung

Die Vorteile jedes Ansatzes sind in der Tabelle dargestellt:

Abwehrmechanismus Vorteile
Prüfung von HTTP Headers(Same Origin)
  • Keine Benutzerinteraktion notwendig
  • Implementierung innerhalb oder außerhalb der Anwendung (Proxy, WAF)
Re-Authentifizierung
  • Einfache Implementierung
Anti-CSRF Token
  • Zuverlässige Methode
  • bei richtiger Implementierung für den Benutzer transparent

Am besten sollen nach dem „Defense-In-Depth“ Prinzip mehr als ein Mechanismus aktiv werden, z.B. die Prüfung von HTTP Headers seitens des Proxy oder Web Servers und Anti-CSRF Tokens innerhalb der Anwendung.

XSS-Schwachstellen beheben

Als erste Voraussetzung gilt es, dass die Anwendung keine XSS Schwachstellen aufweisen soll, sonst kann nur ein 2-Faktor Element (am besten Out-of-the-Band wie SMS oder mTAN Verfahren), Re-Authentifizierung oder ein Captcha helfen.

Same Origin

HTTP Referer und Origin Headers kommen bei diesem Ansatz in Frage. Dabei sind die Checks von dem Origin Header weiter verbreitet, da dieser Header auch in einem HTTP Request von der HTTPS Seite verfügbar ist, was beim HTTP Referer nicht der Fall ist. Die Origin- und Referer Headers (=Source) sollen mit dem Host Header (=Target) verglichen werden und müssen dabei übereinstimmen.

Auf den ersten Blick scheint dies eine einfache Lösung ohne grossen Aufwand zu sein, da die HTTP Headers auf dem Proxy/Web Server oder einer WAF (Web Application Firewall) geprüft werden können. Leider haben Browser unterschiedliche Implementierungen für das Schicken eines Origin Headers. Z.B. wird IE 11 bei einer Trusted Domäne überhaupt keinen Origin Header schicken. Des Weiteren wird der Origin/Referer Header aus Datenschutzgründen nicht immer geschickt oder wird auf dem Proxy Server für die ausgehenden Requests entfernt. Wer diese Besonderheiten nicht sorgfältig testet, riskiert, dass die Prüfung nicht korrekt funktioniert und einige User ohne Headers keine normale HTTP Response 200 auf ihren HTTP Request bekommen.

Wenn weder HTTP Referer noch Origin Header vorliegt, ist es empfohlen, den Request zu blockieren, vor allem wenn keine anderen Checks seitens der Anwendung implementiert sind. Dies und auch das Verhalten mit dem Proxy Server muss ebenfalls getestet werden. In dem zweiten Fall kommt häufig der Einsatz eines Header X-Forwarded-Host in Frage; dieser enthält den Host Header des ursprünglichen HTTP Requests. Die Auswertung von Statistiken bei den HTTP Requests unterstützt gut dabei, die Checks von HTTP Headern anzupassen.

Re-Authentifizierung

Die Logik hinter Re-Authentifizierung ist einfach – der Benutzer muss sich bei einer sensitiven Transaktion mit dem Passwort erneut authentifizieren. Am häufigsten wird dieser Mechanismus bei einem Passwortwechsel gesehen. Jedoch ist der Ansatz bei häufigem Vorkommen nicht benutzerfreundlich. Es ist also abzuwägen, wann dieses Prinzip wirklich Sinn macht und dem Nutzer zuzumuten ist.

Anti-CSRF Token

Anti-CSRF Tokens, auch Synchronizer-Tokens genannt, werden häufig zuerst vom Server geschickt und müssen im HTTP-POST Request im HTTP Header mitgeschickt werden. Sehr wichtig dabei ist, dass die Tokens eindeutig, zufällig generiert und geschützt werden. Ein Angreifer kann ansonsten einfach die Tokens analysieren und deren Entropie auswerten um festzustellen, wie groß seine Chance ist, innerhalb einer überschaubaren Anzahl von Requests den richtigen Wert für einen gefälschten Anti-CSRF Token zu finden.

Ebenfalls wichtig zu erwähnen ist, dass der Server die Anti-CSRF Tokens richtig validieren muss. Wir haben schon Anwendungen gesehen, die nur den String „Anti-CSRF Token“ gesucht haben, wobei der Wert des Tokens selbst ignoriert wurde!

Der Token soll am besten für jeden Request generiert werden (nicht nur einmal pro Sitzung) und beim Transfer mit TLS geschützt werden.

Diese Technik setzt voraus, dass keine anderen Schwachstellen wie XSS oder sitzungsbasierte Probleme auftreten – sonst ist es einfach, den Wert des Anti-CSRF Tokens zu extrahieren und in einem manipulierten HTTP-POST Request mitzuschicken.

Andere Abwehrmechanismen

Zu anderen effektiven Maßnahmen zählen One-Time Tokens (oft bei Online-Banking genutzt). Als Out-Of-Band Mechanismus werden SMS, mTAN, PhotoTAN oder E-Mail verwendet. Hier muss aufgepasst werden – der Benutzer hat einerseits einen deutlich höheren Aufwand und zweitens kann es zu Verfügbarkeitsproblemen führen. Z.B. wenn die PhotoTAN App auf dem Android Gerät unstabil ist oder der Benutzer gerade kein GSM Signal hat (SMS). Idealerweise soll der Benutzer zur Auswahl haben, über welchen Kanal er das Token erhalten möchte.

Captcha ist auch ein Abwehrmechanismus, wird jedoch nicht oft eingesetzt. Eleganter an dieser Stelle sind die für den Benutzer unsichtbaren Anti-CSRF Tokens.

Fazit

CSRF Attacken findet man kontinuierlich seit 2007 unter den häufigsten Attacken in den OWASP TOP 10. Wir empfehlen, die Checks bereits im Designprozess innerhalb jeder Webanwendung zu implementieren. Es ist gegebenenfalls sehr aufwändig, CSRF-Schwachstellen aufgrund von Pentest-Findings nachträglich zu beheben. Für viele Frameworks sind Unterstützungsmechanismen verfügbar, so dass es für Entwickler leichter ist, die effektive Abwehr richtig zu implementieren.

Auch hier gilt: Im gesamten SDLC Prozess sollte die Sicherheit von Anfang an eine wichtige Rolle spielen.

 


Links:

https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)

https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet

https://seclab.stanford.edu/websec/csrf/csrf.pdf

 

Bild: ©iStock/sanjeri/Boxen power

Schreibe einen Kommentar