zurück zur Übersicht

CSRF Attacks: Häufige Trugschlüsse und Missverständnisse

Falsches Spiel: CSRF liefert gezielt falsche HTTP-Requests an den WebserverAttacken vom Typ Cross-Site-Request-Forgery (CSRF) gehören zu den häufigsten Angriffen auf Webanwendungen. Eine manipulierte HTTP-Anfrage wird innerhalb einer gültigen Session mittels Browser gesendet. Da der betroffene User den HTTP-Request z.B. über ein manipuliertes Formular selbst initiiert hat, können der Browser und die Anwendung selbst diese Manipulation nur schwer erkennen. Eine Kombination mit anderen Schwachstellen wie Cross-Site-Scripting (XSS) kann schwere Auswirkungen haben.

CSRF-Attacken haben zwar bisher im Vergleich zu SQL-Injection und XSS-Attacken für weniger Aufmerksamkeit gesorgt, zählen jedoch schon lange zu den OWASP TOP10 Attacken und sind auch im  Release Candidate der OWASP 2017 gelistet. 

Das Konzept hinter CSRF wird oft nicht vollständig verstanden. Des Öfteren sehe ich in Penetration Tests oder Security Assessments interessante und gleichzeitig unwirksame Anti-CSRF-Maßnahmen. Grund genug also, um das Thema in Form einer dreiteiligen Beitragsreihe zu behandeln. In diesem Beitrag soll es zunächst um Anwendungen gehen, die überhaupt nicht gegen CSRF geschützt sind. Das kann z.B. deswegen der Fall sein, weil während der Entwicklung angenommen wurde, dass bereits Maßnahmen vorhanden sind, die diesen Angriffsvektor auszuschalten. Die Absicherung gegen CSRF wurde somit beim Anwendungsdesign nicht in Betracht gezogen.

Basics first

In einem Projekt wurde als Maßnahme gegen CSRF eine Checkbox vorgeschlagen, die im selben Schritt wie das auf der Webseite vorhandene Formular zur Verfügung stand, das mit Daten befüllt werden sollte. Dieser Ansatz könnte zwar bei Transaktionen mit niedriger Kritikalität ausreichen, ist aber grundsätzlich ineffektiv. Der Angreifer kann dies sehr einfach in seiner Anfrage manipulieren. Diese Methode kann also (wenn überhaupt) nur empfohlen werden, wenn keine sensitiven, personenbezogenen Daten oder finanziellen Daten in der Transaktion bearbeitet werden sollen.

Ein weiteres Missverständnis beruht darauf, dass CSRF entweder nur für GET oder POST Requests relevant ist und es schwierig ist, einen CSRF-Angriff mit dem POST Request durchzuführen, ohne dass der Benutzer das merkt. Auch heute sind noch Anwendungen zu sehen, die sowohl POST als auch GET Requests für eine Transaktion akzeptieren. Einen GET Request in einen POST Request umzuwandeln oder umgekehrt ist einfach und kann schnell getestet werden. Zudem können sowohl GET als auch POST Requests ohne Benutzerinteraktion ausgeführt werden. 

  • Die URL in dem GET Request kann obfuskiert, also unkenntlich gemacht werden, so dass der Benutzer die Parameter nicht erkennen kann
  • HTML5 bietet neue Elemente, die auf Benutzerinteraktion verzichten wie audio, video oder object Tags. In HTML4 können stattdessen iframe oder script Elemente benutzt werden.
  • Für POST Requests stehen zwei Ansätze zur Verfügung:
    • mit einem HTML Formular (ohne weitere aktive Inhalte) was der Anwender vor dem Absenden allerdings bemerken würde
    • mit HTML und Javascript kann ein POST Request mit der XMLHttpRequest(XHR) Methode ausgeführt werden

Hier ist ein Beispiel zur letztgenannten Methode:

var url= “URL”;
Var params= “old=myemail@victim.site&new=evil@hacker.site”;
Var CSRF = new XMLHttpRequest();
CSRF.open(“POST”,url,false);
CSRF.setRequestHeader(“Content-type”,”application/x-www-form-urlencoded”);
CSRF.send(params);

In diesem Beispiel wird ein manipulierter POST Request geschickt, welcher die E-Mail Adresse ändert, ohne dass die Webseite wieder geladen werden muss.

Schulung und Aufklärung helfen

Manchmal wird auch die Auffassung vertreten, dass Authentifizierung und ein entsprechendes Berechtigungskonzept gegen CSRF helfen. Dies stimmt so nicht, da der Angriff erfolgt, wenn der Benutzer schon erfolgreich angemeldet ist. Ist dies noch nicht der Fall, wird er zur Anmeldung aufgefordert, oft ohne dabei Verdacht zu schöpfen. Ob für Session Management Cookies, Local Storage, oAuth Token oder andere Mechanismen verwendet werden, spielt keine Rolle, denn der Benutzer ist in dem Moment, in dem die manipulierte HTTP-Anfrage geschickt wird, authentisiert und somit berechtigt. Solche Fehleinschätzungen sollten durch  entsprechendes Security Awareness Trainings vermieden werden. 

Im nächsten Teil der Beitragsreihe werden wir uns mit Maßnahmen gegen CSRF beschäftigen, die oft leider nicht die gewünschte Wirksamkeit entfalten und somit zu trügerischer Sicherheit führen.


 

Bild: ©iT-CUBE SYSTEMS AG 2017

Schreibe einen Kommentar