O'Reilly logo

PHP-Sicherheit: PHP/MySQL-Webanwendungen sicher programmieren by Stefan Esser, Christopher Kunz

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

4 Cross-Site Scripting112
4.18 Cross-Site Request Forgery (CSRF)
Obgleich der Begriff »Cross-Site Request Forgery« im Gegensatz zum
wesentlich bekannteren XSS nur wenigen Entwicklern bekannt sein
dürfte, ist der unter diesem Namen bekannte Angriffsvektor nicht zu
unterschätzen – erlaubt er doch zumeist die Ausführung potenziell
sicherheitsriskanter Aktionen ohne das Wissen des Ausführenden.
CSRF ist im Grunde genommen genau das Gegenteil von XSS
während XSS eine Website dazu nutzt, Code im Browser des Benutzers
auszuführen, werden bei CSRF die im Browser eines Nutzers gespei-
cherten Informationen (z.B. sein Session-Cookie) missbraucht, um auf
einer Site in dessen Namen Aktionen auszuführen.
Session Riding
Der in vielen Abhandlungen zum Thema ausschließlich aufge-
führte Einsatzzweck von CSRF ist das sogenannte »Session Riding« –
also das Ausnutzen einer legitimen Session –, allerdings kann mittels
CSRF auch recht effektiv ein Denial-of-Service-Angriff gegen eine
dynamische Website ausgeführt werden. Session Riding ist technisch
jedoch anspruchsvoller und seine Behebung für Entwickler meist
höher priorisiert – daher wollen wir uns zunächst auf diesen Teilaspekt
der CSRF konzentrieren.
Wie ein Angriff über Session Riding genau abläuft, soll die fol-
gende Abbildung illustrieren:
Der Angreifer bereitet den CSRF vor, indem er über sein(e) Opfer
genauere Informationen einholt. Im vorliegenden Beispiel erfährt er,
dass das Opfer im »Forum XY« regelmäßig mitliest und ein Konto bei
der Onlinebank »MeineBank« besitzt. Als Nächstes ermittelt der
Blackhat, ob diese Bank gegen CSRF ungeschützt ist und welche URL
Abb. 4–2
CSRF-Ablauf
1134.18 Cross-Site Request Forgery (CSRF)
und URL-Parameter notwendig sind, um eine Überweisung auf das
Konto des Angreifers vorzunehmen.
Mit diesen Informationen ausgestattet, veröffentlicht der Angrei-
fer ein Posting im Forum XY, in das er eine Bild-URL einfügt. Die
meisten Foren erlauben von Remote-Sites nachgeladene Bilder per
BBCode o.Ä. – schließlich ist hier kein schädlicher Skriptcode enthal-
ten. Diese Bild-URL ist zwar syntaktisch korrekt, aber tatsächlich ent-
hält das Bild den vorher vom Angreifer ermittelten Aufruf von Meine-
Bank, um eine Überweisung zu tätigen:
<img src="http://www.meinebank.de/ueberweisung.php?betrag=
9999&suffix=foo.png">
Der Parameter betrag steht für den zu überweisenden Betrag – um die
URL für dieses Beispiel so kurz wie möglich zu halten, haben wir auf
zusätzlichen Ballast wie Zielkontonummer und Überweisungsbetreff
verzichtet. Mit dem zusätzlichen GET-Parameter
suffix=foo.png sollen
Filter ausgetrickst werden, die in manchen Foren prüfen, ob die angege-
bene Bild-URL auch tatsächlich zu einem Bild führt – tatsächlich aber
lediglich die Dateiendung mittels
strrpos() o.Ä. anhand einer Whitelist
überprüfen.
Dieses präparierte
<img>-Tag ist nun im Forums-Posting des An-
greifers eingebettet – und jeder Besucher des entsprechenden Forums-
Threads sieht lediglich ein »Broken Image«-Icon.
Im Hintergrund setzt jeder Webbrowser einen GET-Request auf die
entsprechende URL ab und versucht, das versprochene Bild abzurufen.
Da die meisten Besucher des Forums jedoch bei der »MeineBank« kein
Konto besitzen, ist dieser Request nicht von Belang – die Bank wird
lediglich eine Fehlerseite zurückliefern, die der Client eines Forumsnut-
zers nicht als Bild rendern kann – daher das »Broken Image«-Icon.
Bei einem bestimmten Forumsnutzer sieht die Sache jedoch etwas
anders aus: Es handelt sich um das eigentliche Opfer des CSRF-Angrif-
fes. Dieser Nutzer hat vorher eventuell seinen Kontostand bei der Bank
überprüft und versäumt, sich ordnungsgemäß auszuloggen – seine Ses-
sion bei »MeineBank« ist somit noch gültig.
Wird nun auf der Website der Bank die URL
/ueberweisung.php
aufgerufen, führt das dazu, dass das entsprechende PHP-Skript im
Kundenbereich des Kreditinstitutes die gültige Session des Opfers ver-
wendet, um ihm die Überweisungsanforderung zuzuordnen. Zwar
erwartet die Bank eigentlich einen POST-Request vom korrekten Über-
weisungsformular, da intern jedoch nur das superglobale Array
$_REQUEST verwendet wird, werden auch GET-Variablen anerkannt.
Sie ahnen vermutlich bereits, worauf wir hinauswollen: Über das
im XY-Forum eingebettete
<img>-Tag ruft das Opfer die Überweisungs-

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required