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 Scripting88
Teilzeit-»Moderator« und »Sicherheitsexperten« beim Privatfernsehen
bis hin zu Routenplanungs-Datenbanken oder großen Konzernwebsei-
ten bleibt niemand verschont. Oft sind die scherzhaften »Angriffe«
jedoch Vorboten für ernsthaftere Blackhat-Aktionen wie Datenklau,
Phishing oder dauerhaftes Defacement.
Anwendungen mit
XSS-Problemen
Die Archive der Security-Mailinglisten BugTraq und Full Disclos-
ure liefern eine Fülle von XSS-Lücken. Die Liste der vertretenen PHP-
Applikationen liest sich wie ein »Who’s who«:
phpMyAdmin 2.9.0.2 erlaubte über vier verschiedene XSS-Lücken
die Anzeige beliebiger vom Benutzer vorgegebener Informationen;
Angreifer konnten so in den Besitz der Session-Cookies eines
Datenbank-Administrators gelangen.
Der Banner-Server phpAdsNew hatte in allen Versionen bis 2.0.8
ebenfalls mit XSS zu kämpfen.
Das beliebte Weblog Serendipity hatte im Administrationsinterface
eine XSS-Lücke, die in Versionen bis 1.0.1 die Einbettung von
Scriptcode erlaubte.
Es scheint, als ob jeder Entwickler ab und an versäumen würde, sich
den ersten Merksatz sicherer Webapplikationen ins Gedächtnis zu
rufen: Vertraue nie Eingaben, die vom Benutzer kommen! An vielen
Stellen ist eine XSS-Lücke nicht mit vertretbarem Aufwand für wirk-
lich böse Zwecke zu nutzen, sehr oft jedoch ist ein Cookie-Diebstahl
unsagbar einfach möglich – Sie sollten XSS nicht unterschätzen.
Außerdem ist es höchst peinlich, wenn Skriptcode im Sicherheitskon-
text Ihrer Website ausgeführt wird, um lustige Popups wie »Doofer
PHP-Programmierer« zu erzeugen.
4.8 Ein klassisches XSS
Es ist bei vielen dynamischen Webseiten – gerade solchen, deren Betrei-
ber ihre ersten Gehversuche mit PHP unternehmen – populär, einige
Daten des Besuchers abzufragen und sie dann in einer Art personali-
sierter Ansprache anzuzeigen. Beispielsweise könnte man zunächst den
Vornamen des Surfers abfragen (per JavaScript-Popup oder normalem
HTML-Formular) und diesen dann anzeigen. Das könnte so aussehen
wie im folgenden Listing:
894.8 Ein klassisches XSS
<?php
if (isset($_GET['vorname']) {
echo '<h1>Hallo, ' . $_GET['vorname'] . '</h1>';
} else {
echo '<form method="GET" action="'. $_SERVER['PHP_SELF'] . '">';
echo 'Bitte Vornamen eingeben: ';
echo '<input type="text" name="vorname">';
echo '<input type="submit"></form>';
}
?>
Angreifbarer Code zur
Personalisierung
Ist die GET-Variable »vorname« gesetzt, so wird der Besucher persön-
lich angesprochen – ist dies nicht der Fall, fragt ein kurzes Formular
zunächst den Namen ab, um ihn im folgenden Request dann anzuzeigen.
Der erste Angriffspunkt in diesem Skript ist offensichtlich – der
Entwickler hat keinerlei Überprüfung der über GET an das Skript
durchgereichten Variablen vorgesehen. Damit können Benutzer belie-
bige Werte übergeben, die ohne Validierung angezeigt werden. Von
besonderem Interesse ist es für Angreifer, ein Stück JavaScript im
angeblichen »Vornamen« unterzubringen, das dann im Client des arg-
losen Benutzers zur Ausführung kommt.
Geben Sie als Vorname im Formularfeld den String
<script>alert
(document.cookie)</script>
an, sollten Sie nach dem Abschicken des
Formulars ein leeres JavaScript-Popup sehen. Hätte Ihre Anwendung
ein Cookie beim Benutzer gesetzt, sähen Sie es jetzt als Ausgabe des
JavaScripts.
Ein zweiter Angriffsvektor für XSS ist in der Variablen
$_SERVER
['PHP_SELF']
versteckt. Diese Variable enthält neben dem nicht mani-
pulierbaren Skript-Dateinamen noch ein zweite Komponente, die soge-
nannte PATH_INFO. Hängt ein Angreifer an den Dateinamen im
URL, etwa
test.php, noch einen / und weitere Stringelemente an, so
wird diese Information von PHP in die Variable
$_SERVER['PATH_INFO'],
aber eben auch in PHP_SELF übernommen. Dieses Formular kann also
auch ganz einfach über den URL
http://irgendwas.de/test.php/
"><script>alert('xss')</script> angegriffen werden.
Wenn Sie etwas mit verschiedenen HTML- oder Skript-Tags expe-
rimentieren, stellen Sie schnell fest, dass (bei einem Standard-PHP) z.B.
der String
<script>alert("Hallo, XSS");</script> nicht das gewünschte
Ergebnis zeitigt – Sie erhalten keine Ausgabe. Das liegt daran, dass PHP
in der Standardeinstellung Anführungszeichen jeder Art (also Single
und Double Quotes) »escapt«, ihnen also einen Backslash voranstellt.
Aus
<script>alert("Hallo, XSS")</script> wird demnach <script>alert
(\"Hallo,
XSS\")</script> und das so veränderte Skript wird kein
JavaScript-Parser ausführen.

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