de.comp.lang.php.* FAQ

• Über...
• Allgemein
• Installation
• Konfiguration von PHP
• PHP Interpreter
• Datentypen
• Strings
• Regexps
• Arrays
• Objekte
• Formulare
• Sicherheit
  • Wie unterscheide ich böse Variablen von guten?
  • Was genau bewirkt safe_mode und ist das sicher?
  • Warum ist es schlecht, mit dem Referer zu arbeiten?
  • Für welche Zwecke ist der Referer zu gebrauchen?
  • Kann ich PHP-Dateien kompilieren und so vor Dritten schützen?
  • Apache: Wie kann ich ein Verzeichnis mit einem Passwort schützen?
  • Apache: Wie kann ich ein Verzeichnis mit PHP mit einem Passwort schützen?
  • Kann ich mit CGI PHP ein Verzeichnis mit einem Passwort schützen?
  • Wie kann ich Passwörter sicher speichern?
  • Vermeide globale Variablen
  • Prüfe importierte Parameter. Traue niemandem
  • Was sind Race Conditions? Wie kann ich sie vermeiden?
• Dateien
• Datumsprobleme
• Mail mit PHP
• Datenbanken
• DB: MySQL
• DB: Oracle
• DB: Sybase
• DB: MSSQL
• DB: phpMyAdmin
• Grafik
• PDF
• CMS
• Codeschnipsel
• Standardscripte
• Guter Code
• Fehlermeldungen
• Sessions
• PEAR
• FAQ Lizenz
• PHP 3

12.2. Was genau bewirkt safe_mode und ist das sicher?

Antwort von Kristian Köhntopp

Die hier aufgeführte Liste basiert auf einer Analyse einer bestimmten, inzwischen veralteten Version des PHP-Sourcecodes. Die grundsätzlichen Informationen sind korrekt, aber die Liste der einzelnen Teileinschränkungen dürfte nicht mehr abschließend sein.

Es gibt eine Konfigurationsvariable safe_mode , die in der php.ini gesetzt werden kann. Weiterhin gibt es die Konfigurationsvariablen safe_mode_exec_dir und sql_safe_mode .

Wenn safe_mode aktiv ist, sind verschiedene PHP-Funktionen privilegiert oder eingeschränkt. Zumeist gilt die safe_mode Einschränkung, dass auf eine Datei oder ein Verzeichnis nur eingewirkt werden darf, wenn die Datei oder das Verzeichnis denselben Eigentümer hat wie das Script. Im Einzelnen:

• Alle Dateifunktionen einschließlich include() und require() können nur noch mit lokalen Dateien arbeiten, die denselben Eigentümer (uid) haben wie der Eigentümer des Scriptes.

• • Auch ftp-Pfadnamen werden so geprüft.

  • Auch zlib-Pfadnamen werden so geprüft.

  • mkdir() und posix_mkfifo() sind nur in Verzeichnissen zugelassen, die die Einschränkung erfüllen.

  • Das Ziel eines link() und symlink() (Parameter 1 von symlink() ) muss die Einschränkung erfüllen.

  • Die Subjekte der Funktionen unlink() , chgrp() , chown() , chmod() , touch() , rmdir() , rename() und copy() müssen die Einschränkung erfüllen.

• Lokalen, absoluten Pfadnamen wird document_root vorangestellt.

• In den Funktionen popen() , system() und exec() können nur Kommandos ausgeführt werden, die im safe_mode_exec_dir stehen. Auf die ausgeführten Kommandos wird von den Funktionen popen() , system() und exec() automatisch EscapeShellCmd() angewendet.

• Dynamisch ladbare Erweiterungen ( dl() -Funktion) stehen in safe_mode nicht zur Verfügung ("Dynamically loaded extensions aren't allowed when running in SAFE MODE.").

• Es kann kein neues CPU-Zeitlimit festgelegt werden ("Cannot set time limit in safe mode").

• Wird mod_php verwendet, steht in der Funktion getallheaders() der Wert des Headers "Authorization" (Loginname und Passwort) nicht zur Verfuegung.

• Die Funktion header() wird dem Header "WWW-authenticate" immer den Eigentümer des Scriptes als Bestandteil des Realms hinzufügen.

• Das filepro Map-File "dir/map" (wobei dir der Parameter der filepro()-Funktionen ist) muss die Einschränkung erfüllen. Dies gilt für filepro() , filepro_rowcount() und filepro_retrieve() .

• Das dbase-Modul verlangt in dbase_open() und dbase_create() , dass die dbf-Datei die Einschränkung erfüllt.

• Das DBM-Modul setzt voraus, dass in dbmopen() das Verzeichnis, in dem die DBM-Datenbank angelegt wird, die Einschränkung erfüllt. Dies ist bei den DBA-Funktionen nicht der Fall.

Wenn sql_safe_mode aktiv ist, können bei einem MySQL-Connect host, user und password nicht angegeben werden ("SQL safe mode in effect - ignoring host/user/password information").

safe_mode ist nicht sicher: Ein Fehler in der popen() -Funktion ist erst mit 3.0.14 korrigiert worden, ein weiterer Fehler in der mail() -Funktion erst in 3.0.15. Spätere Versionen von PHP hatten weitere Lücken. Man sollte stattdessen die CGI-Version in einem chroot-Environment verwenden und mit setrlimit noch weitergehende Einschränkungen definieren.