Cross Site Request Forgery - Ist CSRF tot?

Cross Site Request Forgery

Ist CSRF tot?

Dominik Altermatt
von Dominik Altermatt
am 21. September 2017
Lesezeit: 11 Minuten

Keypoints

  • CSRF steht für Cross Site Request Forgery
  • Hierbei handelt es sich um eine Angriffstechnik auf Webapplikationen
  • Durch das unbewusste externe Aufrufen einer Ressource wird durch den legitimen Benutzer ungewollt eine Aktion ausgeführt
  • Erweiterte Einstellungen für Cookies schränken die Angriffsmöglichkeiten ein
  • Durch dynamische CSRF-Token kann dieser Angriff verhindert werden

Cross Site Request Forgery (CSRF) Attacken sind schon einige Jahre bekannt und bieten einen interessanten Ansatz, um eine Privilege Escalation in einer Web-Applikation zu durchzuführen. Das zugrundeliegende Konzept dieser Attacke wurde bereits erstmals 1988 von Norm Hardy beschrieben und trägt den Namen Confused Deputy Problem. Es diskutiert, wie ein Angreifer über einen Stellvertreter auf eine Ressource zugreifen kann. Wobei der Aktor selbst keine Privilegien auf der Ressource hat, jedoch die Privilegien des Stellvertreters nutzt, um entsprechende Aktionen auszuführen.

Das Ziel

Mit einer CSRF-Attacke lassen sich als Angreifer Aktionen in einer Web-Applikation im Namen eines autorisierten Benutzers ausführen. Dabei eröffnet sich ein breites Band von Anwendungen. Dazu gehören Kommentare in Social-Media Plattformen absetzen oder Klicks auf entsprechende Inhalte des Internets (Beeinflussung von Trends oder klick-finanzieren Werbemodellen). Weitaus kritischer wird es wenn über eine CSRF-Attacke zum Beispiel Zahlungen in Online-Banking ausgelöst werden können oder auch das Erstellen von privilegierteren Benutzer in einer Management-Konsole einer Ressource, um darauf basierend weiter Attacken oder Manipulationen auszuführen.

Ein Blick auf VulDB (Suche nach CSRF) zeigt: Es werden fast täglich neue CSRF-Schwachstellen identifiziert. Viele davon werden mittels CVSS als Low, einige als Medium und sehr Wenige als High eingestuft. Trotzdem sollte eine CSRF-Attacke ernstgenommen werden, da sich ihre Komplexität doch in Grenzen hält und das Angreifer-Profil zur Durchführung dieser Attacken in einer einfachen Form keine hohen Anforderungen stellt.

Aufbau der Attacke

Die involvierten Komponenten einer CSRF-Attacke sind die Folgenden:

Das Verhalten der Browser spielt bei der CSRF-Attacke eine besondere Rolle. Dazu sind zwei Faktoren zu nennen:

Mögliches Angriffsszenario

Nun kann man sich den Ablauf einer CSRF-Attacke gut vorstellen; ein mögliches Szenario könnte wie folgt von statten gehen:

  1. Ein Angreifer hat eine Webseite unter seiner Kontrolle. Diese Webseite enthält Cross Site Requests. Jedoch nicht um einfache Bilder von Dritt-Webseiten zu laden, sondern CSRF-Requests, die z.B. das Passwort des Benutzers auf 123abc setzen.
  2. Durch Social Engineering und gutes Timing bringt nun der Angreifer den Benutzer dazu, die präparierte Webseite zu besuchen. Eventuell ist der Benutzer ein Fan von schönen Uhren und die Webseite des Angreifers enthält günstige Angebote dazu. Durch das Laden der Uhren-Webseite werden auch die Cross Site Requests durch den Browser ausgeführt.
  3. Gleichzeitig ist der Benutzer in der Ziel-Web-Applikation autorisiert. Da der Browser des Benutzers nicht unterscheiden kann, wer nun den Request Ändere Passwort auf "123abc" abgegeben hat, fügt der Browser das Session-Cookie der konstruierten Request hinzu und sendet sie an die Web-Applikation.
  4. Die Web-Applikation hat keine Möglichkeit zu unterscheiden, ob eine Request durch eine echte Benutzereingabe oder eine CSRF-Attacke ausgelöst wurde und ändert das Passwort des Benutzers auf 123abc.
  5. Der Angreifer kann sich nun als diesen Benutzer einloggen und weitere Manipulationen im Namen des Benutzers vornehmen.

Es ist zu beachten, dass das Nutzen des Session Cookies als eine Ausprägung der CSRF-Attacke zu sehen ist, was Session-Riding genannt wird. Weiter sind auch andere Sitzungsbezeichner wie z.B. Basic/Digest Authentication von CSRF-Attacken nicht ausgeschlossen.

Folgend einige simple Beispiele von http Requests, um das Passwort von Bob auf der Web-Applikation management-console.example zu ändern:

Simpler GET-Request:

GET http://management-console.example/change_pwd.do?usr=BOB&paswd=123abc HTTP/1.1

Fake-Image:

<img src="//management-console.example/change_pwd.do?usr=BOB&paswd=123abc" width="0" height="0" border="0">

PUT-Request:

PUT http://management-console.example/change_pwd.do HTTP/1.1
{ "usr":"BOB", "pwd":"abc123" }

CSRF-Schutz

Um sich vor CSRF zu schützen, empfiehlt OWASP verschiedene Ansätze:

Um zu prüfen, ob Source und Target Origin schlüssig sind, können die Standard Server-Header Referer, Origin und/oder Host verwendet werden. Hat man Source und Target Origin evaluiert, kann man diese einfach vergleichen. Stimmen sie nicht überein, soll die Request geblockt werden, um eine CSRF-Attacke zu verhindern. Grundsätzlich sind Server-Header leicht durch einen Angreifer zu manipulieren, jedoch sind die genannten Header etwas mehr geschützt, da diese in der Forbidden Header Name List zu finden sind. Dadurch können diese Header browserseitig nicht mittels JavaScript gesetzt werden, wodurch sie gegen XSS Attacken geschützt sind.

Das Vergleichen der vorhandenen Server-Header bietet jedoch nicht ausreichen Schutz gegen CSRF-Attacken, daher muss dazu ein CSRF-Token kongruiert werden. Ein CSRF-Token soll bei jeder Status-Verändernden Aktion mitgesendet werden. Analog des Session Cookies, jedoch nicht für die gesamte Sitzung, sondern für jeden Request neu generiert. Im Prinzip gelten für eine CSRF-Token dieselben Anforderungen an Komplexität und Entropie wie für Session Cookies.

Unter den CSRF-Token gibt es wiederum verschiedene Ansätze. OWASP nennet dazu noch folgende Optionen:

Meist sind in modernen Frameworks für Webentwickler bereits CSRF-Token Funktionalitäten verfügbar. Daher ist die Empfehlung diese in erster Linie zu nutzen. Reichen diese Schutzmassnahmen nicht aus, kann auf explizit entwickelte CSRF-Token-Konzepte zurückgegriffen werden.

Same-Site Cookie Header

Als weitere Option eine Web-Applikation gegen CSRF-Attacken zu schützen, bietet das konsequente Umsetzen des Same-Site Cookie Attribute, was auch Scott Helme in einem seiner Artikel empfiehlt. Darin bezeichnet er CSRF als tot, sprich nicht mehr ausnutzbar, wenn nur das Same-Site Cookie Attribute beim Session Cookie konsequent gesetzt wird.

Set-Cookie: sess=abc123; path=/; SameSite

Das SameSite Cookie kommt mit zwei Ausprägungen: Strict und Lax, wobei wenn ohne explizite Angabe des Modus, die Strict Policy verwendet wird.

SameSite=Strict
SameSite=Lax

Mit dem Setzen des Same-Site (Default/Strict) Attributes, wird dem Browser befohlen nie Requests, die von einer Cross Site-Quelle stammen zu öffnen. Damit können aber Effekte zum Vorschein kommen, die allenfalls vom Seitenbetreiber nicht gewünscht sind. Ist ein Benutzer auf einer Webseite eingeloggt und möchte von derselben Seite einen weiteren Tab im Browser öffnen, wäre dieser Tab, nicht wie in den meisten Fällen, bereits auch auf entsprechender Webseite eingeloggt.

Daher steht der Modus Lax zur Verfügung. Dieser birgt eine Ausnahme für den Browser und dessen Umgang mit dem Senden von Cookies. Nämlich darf der Browser Requests z.B. an Top-Level-Domains (von der Webseite, in der man bereits eingeloggt ist) senden, jedoch nur mit als sicher geltenden HTTP-Methoden.

Benutzereingaben fordern

Es kann für gewisse Fälle auch Sinn machen, dass man sich überlegt, explizite Benutzeraktionen zu fordern, bevor kritische Aktionen erlaubt werden, wie z.B. ein Passwort neu zu setzen. Dazu können CAPTCHA, One-time Token oder Re-Authentisierung genutzt werden.

Fazit

CSRF-Attacken nutzen eine Schwachstelle, welche per Design durch den Aufbau von Webseiten und dem Verhalten der Browser ermöglicht wird. Durch eine saubere Planung inklusive einer wirksamen Social Engineering-Kampagne, können CSRF-Attacken grossen Schaden anrichten. Z.B. in Form einer Privilege Eskalation, als wichtiger Zwischenschritt, einer mehrstufigen Attacke. Schutzmassnahmen sind in verschiedenen Facetten vorhanden. Als tot kann man CSRF noch nicht bezeichnen, jedoch ist das Nutzen des Same-Site-Cookie Attribute schnell umzusetzen und sehr effektiv. Das Einführen von CSRF-Token-Konzepten bedarf mehr an Arbeit und sollte gut durchdacht werden. Dazu bieten die meisten modernen Web-Entwicklung-Frameworks bereits geeignete Funktionen an. Setzt man CSRF-Token ein, sollte auf jeden Fall darauf geachtet werden, dass serverseitig auch effektiv das Token geprüft und die Request bei einer nicht Übereinstimmung verworfen wird.

Über den Autor

Dominik Altermatt

Dominik Altermatt arbeitet seit 2003 in der IT-Branche. Unter anderem hat er sich mehrere Jahre mit Data Leakage Prevention bei einer Grossbank beschäftigt. Heute liegen seine Schwerpunkte neben klassischen Penetration Tests bei der Einführung und der Weiterentwicklung von IT-Security-Management-Prozessen. (ORCID 0000-0003-4575-4597)

Links

Sie brauchen professionelles Vulnerability Management?

Unsere Spezialisten kontaktieren Sie gern!

×
TIBER-EU Framework

TIBER-EU Framework

Dominik Altermatt

Traffic-Analyse mit Windows-Boardmitteln

Traffic-Analyse mit Windows-Boardmitteln

Dominik Altermatt

Cisco WebEx Online Meeting Security

Cisco WebEx Online Meeting Security

Dominik Altermatt

Sie wollen mehr?

Weitere Artikel im Archiv

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

Sie wollen mehr?

Weitere Artikel im Archiv