Anmerkungen zum Artikel in der aktuellen ct (Nr. 18) S. 178ff.

  • was leider gar nicht hervorgeht, das man viele Einstellungen per httpd.conf (und dort eigebundener Dateien) per VirtualHost / Directory setzen kann (bei mod_php), prinzipiell alle, die nicht mit „php.ini only“ im Manual (http://www.php.net/manual/de/ini.php) markiert sind.
    Das erlaubt eine Konfiguration pro Benutzer / Anwendung, sofern man Zugriff auf die httpd.conf hat. Das wird zwar in Shared Hosting Umgebungen nicht der Fall sein, aber wahrscheinlich lesen auch viele Anwender mit, die einen eigenen Server betreiben.
  • Bei den Einstellungen vermisse ich memory_limit (sinnvoll erst per Suhosin beschränkbar, da sonst im Script änderbar) und die Größenbeschränkungen allgemein (post_max_size, upload_max_filesize, max_execution_time, max_input_time), expose_php abzuschalten kann auch nicht schaden
  • Bei „disable_functions“ fallen mir noch einige mehr ein, die potientiell gefährlich sind, z.B. curl_*, fsockopen und die ftp Funktionen, ggfs. kann man diese aber auch gleich beim Kompilieren abschalten
  • open_basedir auf das webroot zu beschränken dient _nicht_ unbedingtder Sicherheit, da man dann sensible Daten nicht mehr außerhalb des Webroot ablegen kann. Ich bevorzuge dort eher eine Konfiguration mit open_basedir=/srv/projekt, /srv/projekt/www ist das Webroot und in /srv/projekt/data liegen die Daten.
  • Leider komischerweise viel zu selten erwähnt: Wo man kein PHP braucht, kann man das auch abschalten (php_flag engine off), insbesondere in Verzeichnissen, wo hochgeladene Dateien landen ist das sinnvoll, aber auch in Verzeichnissen, wo nur includes liegen. Zusätzlich sollte man in Include – Verzeichnissen dann aber auch gleich per Order Allow,Deny; Deny from All den Zugriff per ttp komplett abschalten oder diese gleich außerhalb des web_root legen. Bei hochgeladenen Dateien natürlich auch, sofern auf diese nur per Script zugegriffen wird. Damit kann man auf einfache Weise verhindern, das Includes missbraucht werden, die eigentlich nur innerhalb des Hauptscripts verwendet werden sollen.
  • Ein paar mehr Hinweise auf ggfs. auftretende Probleme wären auch nett, z.B. das im safe_mode ein Script nicht mehr in ein Verzeichnis schreiben kann, das es selbst angelegt hat, wenn es als Server-Benutzer läuft.
    Damit funktionieren z.B. die meisten Anwendungen nicht mehr ohne Änderungen, die das Template-System Smarty benutzen. Bei display_errors=off hätte man gleich noch error_log erwähnen können, damit man die Fehler sieht, sofern man keinen Zugriff auf die
    Server-Logs hat.
  • sql.safe_mode kann durchaus sinnvoll sein, da man die Benutzerdaten per mysql.default_* vorgeben kann.
  • Das eine php.ini im Scriptverzeichnis ausgewertet (–with-config-file-scan-dir=) wird halte eher für ein Sicherheitsproblem als ein Feature, da dann jeder Nutzer eigene, noch so unsichere Einstellungen setzen kann und man damit systemweite Einstellungen ggfs. überschreiben kann.
  • Ein Problem bleibt leider komplett außen vor: die mail()-Funktion und ihre unsichere Anwendung. Es gibt leider immer noch sehr viele Scripte, die per Formular entgegengenomme Daten ungeprüft an mail() übergeben, leider auch z.B. eine eingegebene Absenderadresse als „From“ in den Header. Damit lässt sich dann prima Spam versenden. Leider ist mir da auch kein Mittel dagegen bekannt, wie man das Einschränken kann, ohne „gute“ Scripte zu behindern und z.B. per Suhosin zusätzliche Zeilen in Mailheadern ganz zu verbieten.
Dieser Beitrag wurde unter ohne Kategorie veröffentlicht. Setze ein Lesezeichen auf den Permalink.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.