zurück zur Übersicht

CSRF Attacks (Teil 2): Schwache Gegenmaßnahmen

Einige Gegenmaßnahmen gegen CSRF Attacken sind wirkungslos oder scheitern an falscher ImplementierungCross-Site Request Forgery (CSRF) Attacken gehören zu den häufigsten Angriffen auf Web Anwendungen. Im ersten Artikel über CSRF Attacken hier haben wir auf verbreitete Missverständnisse bezüglich CSRF Attacken hingewiesen. Die erwähnten „Maßnahmen“ stellten absolut keine sinnvolle Abwehr dar.

In diesem Artikel beschäftigen wir uns mit Abwehrmechanismen, die zumindest begrenzt effektiv sind, entweder weil sie von ihrem Konzept her immerhin geringfügigen Schutz bieten oder weil sie im Prinzip hilfreich wären und oft nur falsch implementiert werden.

Referer/Origin Header

Der Referer/Origin Header in HTTP Headern dient dazu, die Webseite, von der Benutzer auf die aktuelle Seite gekommen sind, zu identifizieren. Dieser Parameter wird bei Logging, Caching und Sicherheitschecks verwendet. Ohne zusätzliche Angriffsmethoden wie XSS CORS (Cross Origin Resource Sharing) Attacken ist es sehr schwierig, den Referer/Origin Header zu fälschen, da der CSRF Request von dem Browser des Opfers gesendet wird und so auch der richtige Referer/Origin Header gesetzt wird.

Obwohl das Prüfen von Referer/Origin ein gutes Mittel für Abwehrmechanismen ist, müssen folgende Szenarien betrachtet werden:

  • Der Referer Header wird in einem HTTP Request nicht gesendet, wenn der Referer von einer HTTPS Webseite kommt. In diesem Fall wird allerdings der Origin Header immer noch gesetzt.
  • Einige Browser schicken keinen Origin Header wenn die rufende und gerufene Domäne gleich sind (Same Origin).

Diese Maßnahmen können außerdem durch bestimmte XSS Schwachstellen umgangen werden. Zum Beispiel triviale Origin Checks gegen den Wert “client.de” können durch den Origin “client.attacker.de“ erfolgreich durchgehen.

Mehrstufige Transaktionen

Der Gedanke, aus einer Transaktion wie Zahlung eine Transaktion mit mehr Schritten zu bauen, ist prinzipiell gut, denn dies erschwert dem Angreifer den Weg zum letzten Schritt – dem Absenden der Transaktion. Der Angreifer muss dadurch mehrmals mit dem Server interagieren und die Komplexität des Angriffs steigt.

Diese Maßnahme ist allerdings nur effektiv, wenn der Angreifer nicht die ganze Transaktion problemlos automatisieren kann. In der Regel ist dies möglich. Dann kann der Hacker weiterhin alle Parameter selber bestimmen. Ein Skript mit AJAX könnte im Hintergrund eine Reihe von POST und GET Requests ausführen, ohne dass der Benutzer es merkt.

Tipp: Dem kann man entgegenwirken, indem man an dieser Stelle ein Element einführt, welches dem Angreifer unbekannt oder zufällig ist. Wie Transaktionen zusätzlich abgesichert werden können, wird im nächsten Artikel zusammen mit anderen Empfehlungen erläutert.

Secret Cookies

Dieser Ansatz weist darauf hin, dass es sowohl beim Verständnis der Cookie-Funktion als auch der CSRF Attacke einen Mangel gibt. Der Inhalt von Cookies kann zwar gut verschlüsselt und geschützt, ein JWT Token könnte sogar signiert werden. Es geht jedoch gar nicht um den Inhalt des Cookies, sondern darum, dass dieser Cookie bei jedem Browser-Request bei dem validen Benutzer mitgeschickt wird (falls der Benutzer eine valide Session hat). Das ist nicht automatisch gegeben.

Anti-CSRF Tokens

Anti-CSRF Tokens, auch Synchronizer Token Pattern genannt, gehören zu den etwas effektiveren Abwehrmechanismen gegen CSRF Attacken. Der Gedanke liegt darin, dass ein Challenge-Response Mechanismus implementiert wird, bei dem das Challenge vom Server kommt und die Response vom Client. Ohne Challenge soll der Client nicht in der Lage sein, die Response zu erraten, da diese unberechenbar ist. Es reicht auch, wenn Challenge und Response übereinstimmen. Technisch wird dieser Mechanismus als Hidden Field umgesetzt.

Einige Fehler, die bei der Umsetzung oft auftreten:

  • Das Anti-CSRF Token wird korrekt vom Server gesendet, wird in der Response aber nicht geprüft
  • Das Anti-CSRF Token ist nicht zufällig und wird immer rotiert. Dies kann eine Analyse mit einem Web Scanner zeigen, in dem ein paar tausend Tokens gesammelt werden und deren Entropie geprüft wird. Ein Token, das zufällig aussieht und einen langen Wert hat, kann einfach ein Hash oder einen Base64 Wert darstellen:

<input type=”hidden” name=”antiCSRF” value=”c9f0f895fb98ab9159f51fd0297e236d”>

In diesem Beispiel wird hier lediglich “8” mit der MD5 Funktion gehashed.

  • Das Anti-CSRF Token ist nicht zufällig und sein Wert lässt sich von den Benutzerangaben ableiten, z.B. Anti-CSRF Token= {Benutzername + Timestamp + TransaktionsID + Betrag). Dieses Verfahren erfordert zwar eine längere Analyse. Aber bei einer ausreichenden Menge an Mustertokens ist das relativ einfach machbar.

Bei XSS Attacken oder anderen Schwachstellen ist selbst ein Anti-CSRF Token ohne 2-Faktor Challenge-Response Mechanismus nicht hilfreich. In diesem Zusammenhang werden wir hier zwei Beispiele zeigen, wie Anti-CSRF Tokens umgegangen werden konnten. Wir werden die Angriffe nicht im Detail in diesem Artikel beschreiben, weil der Schwerpunkt bei der Erläuterung des Mechanismus liegt. Dass diese Thematik auch große Akteure betrifft, zeigt das Beispiel mit Facebook (siehe Link unter dem Artikel).

Beispiel 1: Zufällige Anti-CSRF Tokens mit kleiner Entropie

Mit einer Token-Analyse wurde herausgefunden, dass anti-CSRF Tokens zwar zufällig sind, jedoch immer nur einen Wert zwischen 100 und 300 haben. Angenommen, dass das Opfer keine Abwehrmechanismen wie IDS oder eine WAF (Web Application Firewall) hat, könnte ein Brute-Force Mechanismus zum Einsatz kommen, denn es werden höchstens 200 Versuche benötigt, um den richtigen Anti-CSRF Token zu schicken.

Das bedeutet, dass wir ein Script brauchen, welches 200 Forms schickt. Zur Realisierung kann eine einfache Programmschleife genutzt werden. Das reicht bereits.

Einen noch gerisseneren Ansatz bietet das Feature von HTML5 – Web Workers, mit dem sich das Brute-Forcing auf der Client-Seite parallelisieren lässt und so noch schneller zum Erfolg führt.

Beispiel 2: Starke Anti-CSRF Tokens mit anderen Schwachstellen

In diesem Fall hat eine XSS Schwachstelle dem Angreifer ermöglicht, das Anti-CSRF Token vom Server auszulesen und es als Response zurück zu schicken. Das Angriffszenario ist, dass die Anwendung XSS Schwachstellen hat.

Dieser Vorgang besteht in der Regel aus 3 Schritten:

  1. Request mit dem Anti-CSRF Token anfordern
  2. Anti-CSRF Token von dem Request extrahieren
  3. Die Response mit dem Anti-CSRF Token zurück an den Server senden

Der erste Schritt lässt sich mit einem Ajax Request und und Property responseText realisieren. Im zweiten Schritt kann durch das DOM Modell das Token extrahiert werden. Wenn das nicht geht, weil wir den Namen des HTML Elements nicht kennen, hilft uns das Regex Matching. Der dritte Schritt ist unkompliziert – einfach den Wert von dem Anti-CSRF Token richtig einstellen.

Denkbar wäre auch ein zweites Angriffszenario: Nur ein Administrator hat die Berechtigung, die personenbezogenen Daten von allen Benutzern im GUI zu sehen. Da der Parameter SessionID schwach ist, kann die Administrator-Session problemlos ohne XSS übernommen werden. Jetzt brauchen wir ein Skript, mit dem alle personenbezogenen Daten ausgelesen werden können. In diesem Fall können wir auf Javascript verzichen und ein BASH Script entwickeln, in dem Tools wie CURL und ein HTML Parser genutzt werden, um die drei oben beschriebenen Schritte zu realisieren.

Fazit

Das Ziel dieses Artikels war, auf schwache Mechanismen gegen CSRF-Attacken hinzuweisen. In dem nächsten und letzten Artikel zum Thema CSRF werden wir uns mit den wirklich guten Methoden und deren Implementierungen beschäftigen.

 


Weitere Links:

https://en.wikipedia.org/wiki/Cross-site_request_forgery

https://www.owasp.org/index.php/Top_10_2017-Top_10

http://amolnaik4.blogspot.de/2012/08/facebook-csrf-worth-usd-5000.html

https://www.html5rocks.com/en/tutorials/workers/basics/

Bild: ©iT-CUBE SYSTEMS AG 2017

Schreibe einen Kommentar