Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03257.jsonl.gz/153

TIBER-EU Framework
Dominik Altermatt
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.
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.
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:
Nun kann man sich den Ablauf einer CSRF-Attacke gut vorstellen; ein mögliches Szenario könnte wie folgt von statten gehen:
123abcsetzen.
Ändere Passwort auf "123abc"abgegeben hat, fügt der Browser das Session-Cookie der konstruierten Request hinzu und sendet sie an die Web-Applikation.
123abc.
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" }
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:
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.
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.
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.
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.
Unsere Spezialisten kontaktieren Sie gern!
Dominik Altermatt
Dominik Altermatt
Dominik Altermatt
Unsere Spezialisten kontaktieren Sie gern!
Weitere Artikel im Archiv