Grundsicherung für PHP-Software

Seite 4: Probleme und Lösungen

Inhaltsverzeichnis

Bei einer stark einschränkenden php.ini kann es zu Problemen kommen. Mit allow_url_fopen = off kann beispielsweise das Forensystem phpBB keine Avatare mehr von externen Servern nachladen. Daher sind möglichst umfangreiche Funktionstests mit einem vorübergehend gesetzten display_errors = on unentbehrlich. Bei Störungen oder nicht hinnehmbaren Funktionsbeschränkungen müssen in der zugehörigen php.ini die Restriktionen gelockert werden. Geben die Fehlermeldungen keinen Aufschluss über das Problem, hilft nur das Experimentieren mit den einzelnen Optionen.

Der Installer der kommenden phpBB-Version 3 gibt vorbildliche Erläuterungen zu den angetroffenen Sicherheitseinstellungen.

Bei einigen modernen PHP-Anwendungen liefert aber bereits die Installationsroutine Hinweise auf mögliche Probleme durch zu laxe oder feste Daumenschrauben. Beispielsweise fragt die kommende Version 3 von phpBB einige PHP-Sicherheitsoptionen ab und gibt entsprechende Hinweise. Das Content-Management-System Joomla hingegen spuckt bei register_globals = on eindeutige Warnhinweise zur unsicheren Serverkonfiguration aus.

In Shared-Webhosting-Umgebungen verdienen Dateien mit Zugangsdaten und Passwörtern ein besonderes Augenmerk. Die meisten Webanwendungen mit MySQL-Anbindung legen ihre Datenbankpasswörter im Klartext im Webverzeichnis ab. Bei Wordpress heißt die Datei beispielsweise wp-config.php, bei phpBB config.php. Im Idealfall sollten diese Dateien nur für den Besitzer lesbar sein, was sich mit den meisten FTP-Programmen über die Dateieigenschaften festlegen lässt.

Das Content-Management-System Joomla warnt vor unsicherer Serverkonfiguration.

Doch bei all-inkl und Server4u ist es erforderlich, dass sowohl PHP-Dateien als auch Include-Dateien Leserechte für alle Nutzer haben müssen. Andernfalls liefert der Server Fehlermeldungen oder ein leeres Dokument an die Web-Browser aus. Zwar ist es uns bei beiden Providern nicht gelungen, auf fremde Web-Homes zuzugreifen und an die Datenbankpasswörter zu gelangen, doch solche Dateien mit vollen Leserechten auzustatten, hinterlässt ein ungutes Gefühl.

Wer besonders sicher gehen will, kann bei php.ini-Dateien und den Verzeichnissen, in denen sie liegen, auch die Schreibrechte entfernen und mit Hilfe von disabled_functions dafür sorgen, dass PHP-Skripte nicht mit chmod() an den Zugriffsrechten drehen können. Ein gekapertes PHP-Programm könnte die Dateien dann nicht mehr mit eigenen Werten füttern oder löschen und so die Sicherheitsvorkehrungen aushebeln.

Wer funktionelle Einschränkungen oder Fehlfunktionen vermeiden möchte, darf bei den Sicherheitsvorkehrungen nicht übertreiben.

Allerdings müssen die Schreibrechte etwa zum Einspielen von Updates vorübergehend wieder zurückgedreht werden. Diese Maßnahme ist sehr zeitaufwendig und fehleranfällig und daher in der Regel nicht die Mühe wert. Wordpress beschwert sich bei deaktiviertem chmod() zum Beispiel, dass es Zugriffsrechte von Dateien und Upload-Verzeichnissen nicht automatisch anpassen kann, was noch mehr Handarbeit für den Hobby-Admin bedeutet.

Auch die gezeigten User-seitigen Mechanismen können nicht jeden Angriff vereiteln. Insbesondere entbinden sie den Webspace-Nutzer nicht von der Pflicht, sich über Aktualisierungen seiner PHP-Anwendungen auf dem Laufenden zu halten und regelmäßig Updates einzuspielen. Wenn schludrige PHP-Skripte Nutzereingaben unzureichend gefiltert an die SQL-Datenbank durchreichen, können Angreifer beziehungsweise Schadprogramme trotz aller Absicherung an den Anwendungsdaten herummanipulieren.

Außerdem lässt sich allow_url_fopen = off unter Umständen mit Hilfe sogenannter Streams ("php://input" und "data://") umgehen. Lediglich die Suhosin-Erweiterung kann das unterbinden. Ist dem Angreifer das Datenbankpasswort in die Hände gefallen, kann er möglicherweise auch über den MySQL-Server Dateien außerhalb des open_basedir auslesen. Ebenfalls ist zu beachten, dass PHP-Beschränkungen nicht für externe Programme und andere Skriptsprachen gelten.

Allerdings bringen schon die wenigen aufgeführten Schritte eine Web-Anwendung aus der Schusslinie der täglich tausendfach einprasselnden Webattacken. Hinter fast allen schädlichen Zugriffen stecken automatisierte Angriffsprogramme, die vornehmlich auf die Standardkonfigurationen zielen und nur äußerst selten versuchen, besondere Sicherheitsmaßnahmen zu umgehen. Denn auch ohne aufwendige Tricks finden Bösewichte mit ihren Massen-Exploits genügend viele verwundbare Web-Applikationen, die sie für ihre Zwecke missbrauchen können.

Diese Tabelle gibt einen Überblick über die PHP-Konfiguration der Webspace-Angebote 1&1 Homepage Perfect, all-inkl Privat, Goneo Homepage Premium, Server4u Racer, Strato Powerweb A und wie man einen eigenen Root-Server einrichten kann.

[1] Christiane Rütten, Tobias Glemser, Gesundes Misstrauen, Sicherheit von Webanwendungen, c't 26/06, S. 234

[2] Informationen zur PHP-Sicherheitserweiterung Suhosin

[3] Dokumentation des PHP-Safe-Mode

[4] Offizielle PHP-Dokumentation zum Thema Sicherheit

[5] Tipps zur php.ini-Konfiguration