© saicle/Shutterstock.com
PHP Magazin
SSRF - was ist das, was kann das, und ist das etwa gefährlich?

Fälschungsalarm auf dem Server

Das Thema dieses Artikels ist eine Schwachstelle und ein Angriff, der oft nicht weiter beachtet wird. Ist diese Missachtung einer möglichen Gefahr gerechtfertigt, oder sollte man vor den Angriffen nicht doch besser auf der Hut sein?

Carsten Eilers


Sie kennen ja sicherlich die Cross-Site Request Forgery (CSRF), bei der eine Webseite eine Aktion auf einer anderen Website im Namen des aktuellen Benutzers ausführt, während dieser dort angemeldet ist. Ein beliebtes Beispiel ist ein IMG-Tag in der Seite des Angreifers, dessen SRC-Attribut den Link zum Ausloggen des Benutzers auf der angegriffenen Website enthält [1]. Also etwa sowas in der Art:

Wenn der Browser versucht, das Bild zu laden, sendet er einen Request an den URL http://www.angegriffene-­site.­example/benutzer/logout.php und fügt die von www.angegriffene-site.example gesetzten Cookies hinzu. An denen wird der Benutzer erkannt und ausgeloggt.

Wow, was für eine Gefahr!

Da zittern gleich alle vor Angst, oder? Natürlich nicht. Aber das ist auch gar nicht beabsichtigt. Dieses Beispiel zeigt nur, wie CSRF funktioniert. Tatsächlich sind sehr viel gefährlichere Angriffe möglich; einige neue Entwicklungen im Bereich der CSRF werden in der nächsten Ausgabe des PHP Magazins vorgestellt.

Wer aber nur das einfache Beispiel kennt, kommt zum Schluss, dass CSRF ja eigentlich harmlos ist. Und genauso sieht es auf den ersten Blick bei der mit der CSRF weitläufig verwandten Server-side Request Forgery (SSRF) aus. Beide gehen übrigens auf das uralte Problem des „Confused Deputy“ [2] zurück, falls Sie die Hintergründe interessieren.

Server-side Request Forgery in der Theorie

Server-side Request Forgery wird als CWE-918 im Common Weakness Enumeration Dictionary wie folgt beschrieben [3]: „The web server receives a URL or similar request from an upstream component and re­trieves the contents of this URL, but it does not suf­fi­ciently ensure that the request is being sent to the expected des­tination.“

Diese Beschreibung ist formal halbwegs richtig (es können auch andere Server als Webserver angegriffen werden), aber wenig anschaulich. Bei einem SSRF-Angriff sendet ein Angreifer einen Request an einen Server A, der diesen dazu bringt, selbst einen Request an einen anderen Server B zu senden und das Ergebnis an den Angreifer zurückzuliefern. Der Vorteil für den Angreifer: Für Server B kommt der Request von Server A. Das ist natürlich besonders nützlich, wenn Server B zwar Requests von Server A entgegennimmt, nicht aber von anderen Quellen. Aber ein Angreifer kann so auch seine Herkunft verschleiern, während er zum Beispiel nach angreifbaren Servern sucht.

Das alles lässt sich viel besser mit einem Beispiel...

PHP Magazin
SSRF - was ist das, was kann das, und ist das etwa gefährlich?

Fälschungsalarm auf dem Server

Das Thema dieses Artikels ist eine Schwachstelle und ein Angriff, der oft nicht weiter beachtet wird. Ist diese Missachtung einer möglichen Gefahr gerechtfertigt, oder sollte man vor den Angriffen nicht doch besser auf der Hut sein?

Carsten Eilers


Sie kennen ja sicherlich die Cross-Site Request Forgery (CSRF), bei der eine Webseite eine Aktion auf einer anderen Website im Namen des aktuellen Benutzers ausführt, während dieser dort angemeldet ist. Ein beliebtes Beispiel ist ein IMG-Tag in der Seite des Angreifers, dessen SRC-Attribut den Link zum Ausloggen des Benutzers auf der angegriffenen Website enthält [1]. Also etwa sowas in der Art:

Wenn der Browser versucht, das Bild zu laden, sendet er einen Request an den URL http://www.angegriffene-­site.­example/benutzer/logout.php und fügt die von www.angegriffene-site.example gesetzten Cookies hinzu. An denen wird der Benutzer erkannt und ausgeloggt.

Wow, was für eine Gefahr!

Da zittern gleich alle vor Angst, oder? Natürlich nicht. Aber das ist auch gar nicht beabsichtigt. Dieses Beispiel zeigt nur, wie CSRF funktioniert. Tatsächlich sind sehr viel gefährlichere Angriffe möglich; einige neue Entwicklungen im Bereich der CSRF werden in der nächsten Ausgabe des PHP Magazins vorgestellt.

Wer aber nur das einfache Beispiel kennt, kommt zum Schluss, dass CSRF ja eigentlich harmlos ist. Und genauso sieht es auf den ersten Blick bei der mit der CSRF weitläufig verwandten Server-side Request Forgery (SSRF) aus. Beide gehen übrigens auf das uralte Problem des „Confused Deputy“ [2] zurück, falls Sie die Hintergründe interessieren.

Server-side Request Forgery in der Theorie

Server-side Request Forgery wird als CWE-918 im Common Weakness Enumeration Dictionary wie folgt beschrieben [3]: „The web server receives a URL or similar request from an upstream component and re­trieves the contents of this URL, but it does not suf­fi­ciently ensure that the request is being sent to the expected des­tination.“

Diese Beschreibung ist formal halbwegs richtig (es können auch andere Server als Webserver angegriffen werden), aber wenig anschaulich. Bei einem SSRF-Angriff sendet ein Angreifer einen Request an einen Server A, der diesen dazu bringt, selbst einen Request an einen anderen Server B zu senden und das Ergebnis an den Angreifer zurückzuliefern. Der Vorteil für den Angreifer: Für Server B kommt der Request von Server A. Das ist natürlich besonders nützlich, wenn Server B zwar Requests von Server A entgegennimmt, nicht aber von anderen Quellen. Aber ein Angreifer kann so auch seine Herkunft verschleiern, während er zum Beispiel nach angreifbaren Servern sucht.

Das alles lässt sich viel besser mit einem Beispiel...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang