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:

• Eine Web-Applikation, welche CSRF-Schwachstellen sowie Funktionen aufweist, die in irgendeiner Art für einen Angreifer von Interesse sind.
• Ein Benutzer, der sich an der Web-Applikation autorisieren kann.
• Der Browser des Benutzers, durch dessen Verhalten die Attacke erst möglich wird.
• Eine durch den Angreifer konstruierte HTTP-Request. Diese enthält die Anfrage an die Web-Applikation, eine Aktion im Sinne des Angreifers auszuführen. Daher auch der Begriff Forgery (zu Deutsch: schmieden, konstruieren).
• Social Engineering-Fähigkeiten des Angreifers, um den Benutzer dazu zu bringen, die konstruierten Requests auszuführen.
• Ein gutes Timing des Angriffs, da die konstruierte Request nur dann erfolgreich ausgeführt wird, wenn der Benutzer zur selben Zeit in der gewünschten Web-Applikation angemeldet ist.

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

• Cross Site Requests: Eine Eigenschaft von Browsern sind sogenannte Cross Site Requests ausführen zu können. Dieser Mechanismus erlaubt es dem Browser, Inhalte von Dritt-Webseiten als Ergänzung der effektiv aufgerufenen Webseiten zu laden. Das sind oft Bilder, Werbeanzeigen oder Scripts. Diese Inhalte werden ohne das Zutun des Benutzers durch den Browser mittels HTTP-Requests angefordert und eingebunden. Damit ist auch die Namensgebung der Cross Site Request Forgery-Attacke geklärt.
• HTTP State Management Mechanism: Da HTTP ein zustandsloses Protokoll ist, werden unter anderem Session Cookies für das Herstellen eines Zustands eingesetzt. Diese werden im Browser gespeichert, sobald ein Benutzer sich erfolgreich an der Web-Applikation autorisiert hat. Fortan werden automatisch durch den Browser diese Session Cookies mit jeder Request an den Webserver der Web-Applikation geschickt. Die Web-Applikation prüft dieses Cookie und kann damit sicherstellen, dass der Benutzer an diesem Browser berechtigt ist, eine Aktion als autorisierten Benutzer auszuführen. Nach einem Logout oder Session-Timeout wird das Cookie zerstört und die Web-Applikation akzeptiert keine Aktionen mehr, die nur durch diesen autorisierten Benutzer getätigt werden können.

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:

• Verwendung von CSRF-Token in Kombination einer Prüfung der Herkunft (Origin) der Requests
• Konsequentes Setzen des same-site Cookie Attribut
• Explizit geforderte Benutzereingaben bevor, eine Aktion ausgeführt werden kann
• CSRF-Token und Vergleichen der Source und Target Origin. Dies ist eine Kombination von verschiedenen Massnahmen, um CSRF-Attacken zu verhindern. Einerseits soll geprüft werden, ob die Source und Target Origin Informationen der entsprechenden Server Header (OWASP Secure Header Project) schlüssig sind und andererseits ob das Einsetzen von expliziten CSRF-Token stattfindet.

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:

• Double Cookie Defense
• Encrypted Token Pattern
• Custom Header, z.B. X-Requested-With: XMLHttpRequest

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 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

• http://www.cap-lore.com/CapTheory/ConfusedDeputy.html
• https://developer.mozilla.org/en-US/docs/Glossary/Forbidden_header_name
• https://scotthelme.co.uk/csrf-is-dead/
• https://tools.ietf.org/html/rfc7231#section-4.2.1
• https://vuldb.com/de/?search
• https://www.owasp.org/
• https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet
• https://www.owasp.org/index.php/OWASP_Secure_Headers_Project