Websecurity: Angriffe mit SSRF, CSRF und XML

Von Carsten Eilers

Stetig gibt es neue SSRF- und CSRF-Angriffe; einige sind gefährlicher als anfänglich vermutet. Dieser shortcut erklärt und untersucht SSRF- sowie CSRF-Schwachstellen und zeigt Ihnen, mit welchen Mitteln Sie diesen entgegentreten können. XML ist schon bei der SSRF nicht unbeteiligt; ebenso spielt es bei zahlreichen weiteren Sicherheitsangriffen eine tragende Rolle, die ebenfalls vom Autor ins Visier genommen werden.

• Sprache: Deutsch
• Herausgeber: entwickler.press
• Erscheinungsdatum: 14. Dez. 2015
• ISBN: 9783868025699

Buchvorschau

Angriffe.

1 SSRF – was ist das, was kann das, und ist das etwa gefährlich?

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

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:

http://www.angegriffene-site.example/benutzer/logout.php>

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 im folgenden Kapitel 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 retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination."

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 erklären. Ein klassisches Beispiel für SSRF ist eine Webanwendung, der man zum Beispiel einen URL zum Laden eines Bilds übergeben kann und die dabei auch Portangaben auswertet. Lässt sich dann je nach Fehlermeldung auch noch feststellen, ob der Port offen oder geschlossen ist, handelt es sich um eine SSRF-Schwachstelle.

Auch das ist noch nicht wirklich anschaulich. Also nehmen wir besser ein Beispiel, das es „in the Wild" wirklich gab. Oder zwei. Oder drei.

Beispiel 1: Eine Schwachstelle auf „marketplace.mozilla.org"

Fangen wir mit einer im Juli 2013 gemeldeten Schwachstelle auf marketplace.mozilla.org an [4]. Beim Anmelden einer App konnte ein URL für das App-Manifest angegeben werden. Der URL konnte eine Portangabe enthalten, die auch ausgewertet wurde. Wurde als URL http://scanme.nmap.org:22 angegeben (Port 22 ist ein offener Port), wurde die Fehlermeldung

Your app failed validation with 1 error. Manifests must be served with the HTTP header Content-Type: application/x-web-app-manifest+json. See https://developer.mozilla.org/en/Apps/Manifest#Serving_manifests for more information.

zurückgeliefert. Beim URL http://scanme.nmap.org:21 mit einem geschlossenen Port gab es dagegen die Fehlermeldung: „Your app failed validation with 1 error. No manifest was found at that URL. Check