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

10 PHP intern224
Ein weiteres Problem tritt ein, sobald Ihre Programme neue
Dateien anlegen. Viele PHP-Skripte erlauben dem Nutzer, Dateien
hochzuladen, die zur späteren Verwendung auf dem Server gespeichert
werden. Im Safe Mode kommt es an dieser Stelle oft zu Problemen:
Das ausgeführte Skript gehört in der Regel einem FTP-Benutzer, also
beispielsweise dem Benutzer »ftpuser1« aus der Gruppe »ftpusers«.
Obgleich es für den Webserver les- und ausführbar ist (dieser ist Mit-
glied der Gruppe ftpusers), werden hochgeladene oder neu angelegte
Dateien stets unter dem Benutzer und der Gruppe des Webservers
angelegt – und das ist normalerweise httpd/nogroup oder ähnlich.
Somit gehören gerade hochgeladene Dateien direkt nach dem Upload
nicht mehr dem Nutzer, der das PHP-Skript ausführt, und können von
diesem Benutzer somit auch nicht mehr manipuliert werden. Ein frisch
übertragenes Foto kann somit nicht mehr automatisch verkleinert oder
mit einem Schriftzug versehen werden, weil das Programm, das Mani-
pulationen ausführen soll, keinen Zugriff auf diese Datei mehr hat.
Um derlei Probleme etwas zu mildern, gibt es eine Konfigurations-
variable, die die Überprüfung statt auf korrekte UID lediglich auf die
Group ID (GID) durchführt. Diese Konfiguration ist jedoch recht
unnütz, denn damit der Safe Mode eine Sicherheitswirkung hat, müss-
ten sich die Gruppen-IDs verschiedener Benutzer unterscheiden – und
dann müsste entweder der Webserver in jeder dieser Gruppen Mitglied
sein oder das Ursprungsproblem wäre nicht gelöst.
10.8 Weitere PHP-Einstellungen
10.8.1 open_basedir
Die Konfigurationsdirektive open_basedir stellt in vielen Fällen einen
wirksameren Schutz als der Safe Mode dar, obgleich auch diese Maß-
nahme von ausreichend motivierten Angreifern ausgehebelt werden
kann. PHP-Skripte dürfen nur Dateien lesen und schreiben, die in dem
oder den – frei übersetzt – »offenen Grundverzeichnissen« liegen – alle
anderen Verzeichnisse sind tabu. Damit ist das
open_basedir eine Art
»schwaches chroot für PHP« – schwach, weil die Funktion nicht auf
Betriebssystemebene implementiert ist und somit prinzipbedingt auch
umgangen werden kann. So können Dateien, die per Shell-Funktionen
wie
system() ausgeführt werden, grundsätzlich aus dem open_basedir
ausbrechen – ein ähnliches Problem wie beim Safe Mode.
Für viele Zwecke ist das
open_basedir jedoch ausreichend sicher,
und im Gegensatz zum Safe Mode stellt es in der Regel keine Ein-
schränkung der Features für den Kunden dar.
22510.8 Weitere PHP-Einstellungen
Mit einer Einstellung in php.ini oder einem VirtualHost-Block
können Sie ein oder mehrere Verzeichnisse als
open_basedir definieren.
Diese Verzeichnisse und alle Unterverzeichnisse stehen Skripten dann
offen:
open_basedir = /home/www/kunde1:/usr/local/lib/php
Wie für die PHP-Konfiguration üblich, werden mehrere Verzeichnisse
in der Direktive durch Doppelpunkte getrennt.
Bei der Aktivierung von
open_basedir sollten Sie einige Punkte
beachten, um Probleme mit PHP-Anwendungen zu vermeiden. Zunächst
sollten Sie dafür sorgen, dass der Zugriff auf die globale Version der
PEAR-Bibliotheken erhalten bleibt. Neben dem Pfad zum Wurzelver-
zeichnis des aktuellen virtuellen Hosts sollten Sie also auch den Pfad zu
PEAR zu den freigegebenen Verzeichnissen hinzufügen.
Zum anderen sollte das
upload_tmp_dir (siehe unten) stets unter-
halb eines der freigegebenen Pfade sein – sonst können PHP-Skripte
keine Uploads entgegennehmen und weiterverarbeiten, da diese nicht
im richtigen Verzeichnis zwischengespeichert werden.
Wir empfehlen dringend, für jeden virtuellen Host ein
open_base-
dir
zu setzen.
10.8.2 disable_functions
Einige PHP-Funktionen gelten als Garanten für Sicherheitsprobleme –
allen voran die diversen Systemfunktionen, mit denen externe Kom-
mandos ausgeführt werden können. Alle vom Administrator als
gefährlich oder unerwünscht erachteten Funktionen können mit der
Direktive »
disable_functions« global deaktiviert werden – und das
heißt leider auch, dass die so deaktivierten Funktionen nicht für ein-
zelne Kunden wieder angeschaltet werden können.
Häufig werden die System- und Prozesskontrollfunktionen in PHP
ausgeschaltet, vielfach ist es auch sinnvoll, einige Funktionen aus dem
POSIX-Repertoire zu deaktivieren – insbesondere in Verbindung mit
mod_suid. Einige »ungeliebte«, weil ressourcenintensive Funktionen
wie
mysql_pconnect() gehören auch oft zu den Opfern von disable_
functions
.
Die Konfigurationsvariable
disable_functions erwartet eine kom-
maseparierte Liste von Funktionen und kann ausschließlich in
php.ini
stehen. Eine getrennte Konfiguration für jeden VirtualHost ist – wie
oben erwähnt – leider nicht möglich. Ein Beispiel könnte so aussehen:
disable_functions = pcntl_exec, system, shell_exec, mysql_pconnect,
posix_setuid, posix_seteuid

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