Private Blogs und Foren sind ein beliebtes Angriffsziel -- auch wegen der vielen Sicherheitslücken darin. Wer sich jedoch nicht mit den unsicheren PHP-Voreinstellungen seines Providers zufrieden gibt, kann dem meisten Ärger aus dem Weg gehen.
PHP gilt gemeinhin als unsichere Programmiersprache. Täglich liest man neue Meldungen über Schwachstellen in PHP-Programmen, sodass Hobby-Admins mit dem Einspielen von Patches und neuen Versionen kaum nachkommen. Doch inzwischen gibt es in der verbreiteten Skriptsprache durchaus ein ganze Reihe von Sicherheitsmechanismen, die dafür sorgen können, dass sich Lücken nicht ausnutzen lassen oder zumindest kein größerer Schaden resultiert.
Das Problem ist jedoch, dass die Sicherheitsoptionen aus Kompatibilitätsgründen in der PHP-Standardkonfiguration allesamt deaktiviert sind. Jeder der Mechanismen geht mit speziellen Einschränkungen oder besonderen Programmiervorgaben einher [1]. Weil aufgrund der vorherrschenden laxen PHP-Sicherheitskonfiguration der Webserver kaum ein Web-Entwickler dazu gezwungen ist, beispielsweise die Einschränkungen des Safe-Mode zu berücksichtigen, ist die PHP-Welt voller Applikationen, die auf abgesicherten Servern Probleme machen oder sogar den Dienst komplett verweigern.
Das PHP-Dilemma
Shared-Webhosting-Provider können es sich nicht leisten, die Sicherheitsschraube für alle Serverkunden gleichsam anzuziehen. Dies hätte massenweise Support-Anfragen wegen nicht funktionierender Webapplikationen zur Folge. Die leidige Konsequenz ist, dass im Shared-Webhosting-Bereich keine nennenswert gesicherten PHP-Umgebungen anzutreffen sind. Wir haben uns exemplarisch fünf Angebote angesehen, und keiner der untersuchten Provider traute sich, wenigstens die wichtigste Sicherheitsoption register_globals = off zu setzen. Damit ist der Teufelkreis komplett, denn so entsteht wiederum kein Druck auf die Entwickler, ihre Anwendungen an den Sicherheitsmechanismen ausrichten zu müssen.
Auf serverseitige Sicherungsmaßnahmen wie etwa den Einsatz der PHP-Erweiterung Suhosin [2] hat man als Webspace-Kunde keinen Einfluss. Aber es gibt auch nutzerseitige Möglichkeiten, die PHP-Konfiguration zu beeinflussen. Wie dafür vorzugehen ist und wie weit der Einfluss geht, hängt jedoch wieder von der Serverkonfiguration des Providers ab - und dort herrscht ein ausgeprägter Wildwuchs (siehe Tabelle).
Bei den untersuchten Webspace-Angeboten kommt durchweg der Webserver Apache zum Einsatz, doch allein bei ihm gibt es zwei grundverschiedene Arten, PHP einzubinden: als Apache-Modul mod_php sowie über den althergebrachten CGI-Mechanismus. Einen brauchbaren Zustandsbericht über den eigenen Webspace liefert ein kurzes PHP-Skript mit dem Inhalt
<?php phpinfo(); ?>
Steht in der Skriptausgabe im Feld "Server API" der Wert "Apache Handler", läuft mod_php, andernfalls steht dort "CGI". Weitere Informationen über den Webspace, etwa die User-ID, lassen sich beispielsweise mit Zusatzprogrammen wie der PHPShell abfragen.
Mit diesem Wissen gerüstet, kann man daran gehen, seinen Webspace abzusichern.