„Sicherheit“ mit PHP/CGI, MySQL

Im Rahmen der Ausbildung zum Mathematisch-Technischen Assistenten ist unser Jahrgang teilweise zufällig über gravierende Sicherheitsmängel bei diversen Webseiten gestolpert; auch war das Thema Sicherheit regelmäßig Gegenstand der Unterrichts-Diskussion. Wie wir dabei während eines Referates über PHP und MySQL (bei dem ich HTML-Code in das vorgestellte Gästebuch injizierte) sowie auf der Schulbanker-Seite (einige Formulare waren 2004 nicht XSS-sicher) gesehen haben, ist es teilweise recht einfach, eigenen Code in fremde Webseiten zu injizieren. Die folgenden Hinweise und Gedanken beziehen sich größtenteils auf PHP und MySQL, können aber auch unkompliziert auf andere Programmiersprachen für CGI-Anwendungen, wie z.B. Perl, Ruby, … übertragen werden.

Viele Beispiele und Ideen, die in diesem Dokument erläutert werden, basieren dabei teilweise auf eigenen Erfahrungen: Der unbedarfte Hobby-Webseitenprogrammierer betrachtet viele Probleme eher naiv oder ist für manche Probleme gar nicht sensibilisiert. Das Aufzeigen und Verdeutlichen von Sicherheitsproblemen und die Sensibilisierung des Programmierers ist Zweck dieses Artikels.

Eins vorweg: Obwohl PHP versucht es dem Anwender möglichst einfach zu machen, sollte man doch daran denken, was man bei C alles falsch machen kann und mit dieser fast schon paranoiden Vorsicht seine Programme schreiben.

… werden zur Ermittlung von „handgeschriebenen“ Daten des Nutzers verwendet und sind daher Bestandteil fast aller Webformulare. Als Übertragungswege vom Client zum Server stehen dabei die HTTP-Methoden GET und POST zur Verfügung, wobei für große Datenmengen (von einem <textarea>) und für nicht offensichtliche Daten besser POST verwendet wird (ich glaube in irgendeinem RFC ist eine maximale Größe des Datenstroms angegeben). Damit ist es allerdings noch längst nicht getan. Im folgenden werde ich zuerst die Risiken ungeprüfter Benutzereingaben allgemein besprechen, danach speziell die Gefahren der Übermittlung per GET.

Eine besondere Sicherheitslücke im Zusammenhang mit Eingabefeldern gleich welchen Typs (einzeilig, Dropdown, Radiobuttons, …) ist, dass sich viele Programmierer darauf verlassen, dass der Anwender auch tatsächlich ihr HTML-Formular benutzt hat, um Daten an ihr CGI-Skript zu senden. Sie gehen also davon aus, dass bestimmte Felder keine Zeilenumbrüche enthalten und andere Felder nur bestimmte Werte. Tatsächlich hindert einen kreativen Benutzer allerdings gar nichts daran, das CGI-Skript von seinem eigenen Formular aus aufzurufen. Um mögliche Sicherheitslücken zu finden könnte der Besucher z.B. ein Formular erstellen, in dem jedes Feld als Textarea ausgelegt ist oder gleich viel flexibler ein Programm schreiben, welches das CGI-Skript mit Daten füttert. Überlegen sie sich daher vor dem Erstellen eines Formulares, welche Form die zu übertragen Daten haben und richten sie die Plausibilitätsprüfungen in ihrem CGI-Skript danach.

Eine nützliche Hilfe beim Testen von Formularfeldern ist die Firefox-Erweiterung Firebug, mit der man u.a. den HTML-Code einer Webseite live verändern kann.

Es gibt Anwendungen, für die GET gut geeignet ist, z.B. Suchmaschinen, bei denen man dem User die Möglichkeit zur Speicherung seiner Abfrage ermöglichen möchte oder bei PHP-basierten CMS (Content Managment Systeme). Erstens gilt das gleiche wie für die verschiedenen Wege der Injektionen, man kann aber auch zusätzliche Variablen in PHP injizieren, sofern in der php.ini die Einstellung register_globals auf On steht. Wenn register_globals aktiviert ist, hat man als Programmierer zwar (etwas) weniger Aufwand die Variablen nach PHP hereinzubekommen, dadurch ergeben sich allerdings auch große Sicherheitslücken:

Nehmen wir an, wir rufen eine Seite per folgender URI auf: http://www.example.org/secret/login.php, wobei im Login-Formular die Werte Name und Passwort gesetzt wurden. Das zugehörige PHP-Script check.php soll so aussehen:

<?php
$base = 'http://www.example.org/';

if (userExists($Name)) {
   if ($Passwort == getStoredPwd($Name)) {
         $is_a_user = true;
    }
}

// etwas später im Code ...

if ($is_a_user)
	header("Location: ${base}secret/very-secret.html");
else
	header('Location: ' . $base);

exit;
?>

Warum sollte man sich bei diesem Script noch die Mühe machen per Brute-Force Benutzername und Passwort zu erraten? Man kann diese zwar auch bequem per URI übermitteln, denn bei aktiviertem register_globals unterscheidet PHP nicht, ob eine Variable per GET oder POST hereinkommt. Die entsprechenden Anfragen braucht man nur zu generieren, indem man viele „sinnvolle“ Buchstaben-Kombinationen ausprobiert, am Besten automatisiert mit einem kleinen Programm. Viel einfacher ist es allerdings die Seite direkt mit /login.php?is_a_user=1 aufzurufen. Aus diesem Grund wurden in PHP die assoziativen Arrays $_POST, $_GET sowie $_COOKIE eingerichtet. Wenn es wirklich gleichgültig ist, woher die Daten stammen, kann man immer noch $_REQUEST verwenden. Außerdem mag es vielleicht hilfreich sein zu wissen, dass Konstanten in PHP nicht von außen gesetzt werden können.

Cookies werden auf Webseiten überall da verwendet, wo benutzerspezifische Daten wie Session-IDs, Warenkörbe, etc. auf dem Rechner des Nutzers gespeichert werden sollen. Da der Standardanwender im Allgemeinen nicht weiß, wie Cookies auf seinem System gespeichert werden und wie er diese bearbeiten kann, geht man davon aus, dass man den Daten eines Cookies vertrauen kann.

An dieser Stelle möchte ich eine Diskussion in unserem Wirtschaftswissenschaften-Unterricht einbringen, in der es um manipulierte Cookies im Zusammenhang mit Webshops ging. In einem konkreten Rechtsfall hatte wohl ein Onlineshop in den Cookies die Preise der Waren gespeichert. Ein findiger Nutzer hatte dies entdeckt und die Preise seines Einkaufs gesenkt. Nach dem Absenden der Bestellung bekam er seinen Einkauf mit den „neuen“ Preisen sogar bestätigt.

Das Ändern eines Cookies ist nicht so schwierig, auch wenn die aktuellen Browser dazu keine Funktion bereitstellen. (Mittlerweile gibt es sogar Cookie-Editoren als Bookmarklets.) Aus der Tradition heraus werden Cookies als Textdatei(en) gespeichert, beim Internet Explorer in einem Verzeichnis namens Cookies, bei Mozilla-Browsern in der Datei cookies.txt im Verzeichnis des eigenen Profiles. Das herauszufinden ist keine Kunst, ebenso wenig, wie das Format der Cookie-Datei(en) aufgebaut ist, d.h. welche Werte man wie ändern kann. Deshalb kann man sich nicht auf die Werte von Cookies verlassen.

Für manche Anwendungen kann es unerlässlich sein, dass Dateinamen oder Teile davon per URI übergeben werden. Als abschreckendes Beispiel gilt dafür immer file.php?name=subdir/file.ext. Das mag bösartige Menschen zwar herausfordern, muss aber gar nicht so gefährlich sein: Wenn Dateinamen an eine CGI-Anwendung übergeben werden, muss beachtet werden, dass die Dateien nicht nach den Regeln des Webservers, sondern des zugrunde liegenden Systems behandelt werden. D.h. / steht für das Wurzelverzeichnis, nicht für die Document Root. Daraus ergibt sich, das Dateien entweder gar nicht oder nur kontrolliert die Server-Umgebung verlassen dürfen. Vor allem auf führende Slashes und /../ ist zu achten! Besser ist es aber die Dateinamen aus verschiedenen Parametern zusammenzubauen, z.B. file.php?category=subdir&name=file&type=ext; Achte darauf, dass das Muster dahinter nicht zu offensichtlich ist, d.h. file.php?category=/etc&name=passwd&type= darf nicht den (vom Hacker) beabsichtigten Zweck erfüllen. Andere Möglichkeiten sind Script-interne Vorgaben wie z.B. $dir = 'dieses/hier/'; – oder besser define('DIR', 'dieses/hier/'), wobei dann alle Dateien aus $dir stammen (müssen). Die PHP-Konfigurations-Einstellung open_basedir erledigt genau dies, allerdings sehr wahrscheinlich besser. Relativ sicher ist den endgültigen Dateinamen erst im Script zusammenzusetzen, z.B.

// URI: file.php?category=sub&name=file&type=ext

$filename = $category . 'dir/' . $name . '.' . $type;

// ergibt 'subdir/file.ext'

So schön das Beispiel auch aussieht, damit es wirklich sicher ist, müssen wir allerdings voraussetzen, dass alle drei Bestandteile category, name sowie type vorher mit basename() behandelt worden sind, um führende ../ und enthaltende NULL-Bytes auszufiltern. Dann ist selbst folgendes Beispiel harmlos (als Kommentar dahinter immer das, was basename() liefert):

// URI: file.php?category=/etc&name=passwd%00&type=interessiertNicht

$category	= basename($_GET['category']);	// 'etc'
$name		= basename($_GET['name']);	// 'passwd'
$type		= basename($_GET['type']);	// 'interessiertNicht'

$filename = $category . '/' . $name . '.' . $type;

// Ergibt 'etc/passwd.interessiertNicht' anstelle von
// "/etc/passwd\x0.interessiertNicht", also '/etc/passwd'.

// $file ist unser "geprüfter" Parameter, d.h. ohne '../' am Anfang
// $file enthält nun "CON\x0"

readfile('verzeichnis/' . $file . '.htminc');

// $file ist komplett ungeprüft, wir verlassen uns auf basename()
// $file enthält "../../CON\x0"

readfile('verzeichnis/' . basename($file) . '.htminc');

Eine – wenn auch eher bei C – beliebte Methode ist es Variableninhalte mit der Funktion printf() auszugegen, weil puts() automatisch einen Zeilenvorschub ausführt: printf(stringvar); Was ist nun, wenn der Variableninhalt ein String ist und printf-Formatcodes enthält? PHP-Fehler werden zum Glück durch den Interpreter abgefangen, aber C-Programme werden in solchen Fällen wegen Zugriffsfehler auf Grund eines Buffer Overflows gerne vom Betriebssystem gekillt, sofern es dies bemerkt. Die printf-Familie für C und Perl kennt den Formatcode n, mit dem in der übergebenem Variable die Anzahl der aktuell geschriebenen Bytes (C) bzw. Zeichen (Perl) gespeichert wird. Damit hat man einen direkten Stackzugriff und kann die Rücksprung-Adresse von printf verändern, so dass nach dem Ende der Funktion nicht zur aufrufenden Funktion zurückgekehrt wird, sondern der, vom Angreifer mit %n geschriebene, (Maschinen-) Code ausgeführt wird. Diese Form des Ausnutzens von Buffer Overflows ist dank schlampiger C-Programmierung eine ausgesprochen beliebte Methode Zugriff auf ein System zu erlangen (siehe auch Wikipedia-Artikel Pufferüberlauf).

Deshalb, wenn man printf() verwendet, dann z.B. so: printf("%s", stringvar);.

Neben der oben genannten Vorsicht, gerade bei Verzeichniszugriffen, gibt es noch weitere Gefahren im Zusammenhang mit Funktionsaufrufen. Viele eingebaute Funktionen geben im Fehlerfall eine Menge an Meldungen direkt an den Browser aus. Dies können Hinweise für potenzielle Kriminelle sein, nicht nur wo auf dem Serverrechner die Homepage liegt. Deshalb gibt es bei vielen (allen?) PHP-Funktionen die Möglichkeit durch ein vorangestelltes @ die Ausgabe von Fehlermeldungen zu unterdrücken, was bei Anwendungen auf Produktivsystemem auf jeden Fall zu empfehlen ist; Fehlermeldungen und Debug-Ausgaben sind nur beim Testen „erlaubt“.

Eine weitere Funktion, die man nur bedächtig einsetzen sollte, ist mail(). Wie der Name schon sagt, kann man damit Emails versenden. Durch schlampige Programmierung kann man dies ausnutzen um große Mengen Spam zu versenden. Da freuen sich neben dem Webhoster vor allem alle Menschen, die ein Emailpostfach besitzen – wer bekommt nicht gerne Post! Die Funktionsdeklaration mail sieht folgendermaßen aus:

Laut Dokumentation der Funktion mail() kann der Parameter subject die Emailadressen mehrerer Empfänger enthalten. Ganz große Vorsicht gilt außerdem dem Parameter additional_headers, der u.a. dazu benutzt werden muss, wenn eine Absenderadresse angegeben werden soll. Anwender dürfen hier unter keinen Umständen Newlines oder die Steuerzeichensequenz \r\n angeben, da sie sonst eigene Mailheader setzen können.

Externe Sourcecodemodule werden als normale Dateien behandelt, d.h. für includes unter Benutzung von Variablen (z.B. include('pfad/zu/' . $inc) ist die gleiche Vorsicht wie beim Öffnen von Dateien notwendig. Weiterhin sollte man verschiedene Funktionalitäten in verschiedene Dateien ausgliedern, die sich die gleichbleibenden Funktionen per include holen. Der Grund ist, dass wir uns bei nur einer Datei mit vielen includes den flachen Namensraum „zumüllen“, d.h. zwei gleichlautende Funktionen führen sehr schnell zu Problemen, da PHP kein Überladen wie C++ oder Java erlaubt. Im Gegensatz zu einer Compilersprache konvertiert PHP einfach zwischen verschiedenen Typen, d.h. aus einem Array als Argument kann schnell ein int werden.

// in der Includedatei
if (! defined('canInclude'))
	die('Zugriff verweigert!');

// im Hauptprogramm
define('canInclude', 1);
include(modul);