Achtung: Dieses Blog ist umgezogen auf die Adresse blog.xwolf.de
Bitte ändern Sie Ihre Bookmarks entsprechend.

Montag, 25. Oktober 2004
Lästern über PHP - Teil 2
Kommentar
Zu meinem vorherigen Lästern zu PHP passt folgender Artikel auf den sunflyer aufmerksam macht: PHP's safe_mode or how not to implement security.

Ein Satz daraus, den ich nur unterstreichen kann:

Perhaps, my biggest pet peeve pertaining to safe_mode is that it is not really safe, merely offering an illusion of safety that does not stand to closer examination. A creative attacker will be able to easily to bypass it.

Wobei ich das creative attacker doch noch abschwächen würde. Eigentlich sollte jeder, der sich etwas mit Filerechten und Multiuser-Systemen auskennt, leicht in der Lage sein, die Sicherheitslücken zu finden und auszunutzen.


Am Ende des Artikel gibt der Autor einige Lösungsmöglichkeiten vor.
Meine wäre diese:

1. PHP wird mit Safe_Mode = On konfiguriert, aber gleichzeitig auch mit open_basedir.

2. Der Zugriff auf die Verzeichnisse eines virtuellen Hosts wird beschränkt auf den User, seine Group und den Apache-Server. Andere User, die Zugriff auf das Filesystem haben, erhalten kein Zugriff. Bei einem Mass Hosting Provider wird es hier zwar Probleme geben, wenn man einfache Unix-Groups nutzt, jedoch läßt sich dies über dynamisch zugeordnete NIS-Maps lösen.

3. Der Zugriff wird nicht allein mittels CHMOD 755 gelöst, was ja "others" reinlassen würde oder mit CHMOD 750 (sinnlos, wenn der User in gruppe web ist- weil andere User wären da ja auch drin - also kein Schutz gegen die anderen User), sondern mit ACLs:
Der Benutzer einer Domain erhält beispielsweise eine Kennung
kuAB00wm
und eine Gruppe
kuABwm

Sein DOCUMENT-Root-Verzeichnis erhält dann
chown kuAB00wm:kuABwm DIR
und
chmod 750 DIR

Damit der Webserver-User www reinkann wurd ein ACL gesetzt:
setfacl -m user:kuAB00wm:rwx,user:www:r-x,mask:rwx DIR


Folge: In das Verzeichnis kommt der User, etwaige Kollegen, die in der selben Gruppe sind und der Webuser.
Andere User auf dem Filesystem kommen nicht rein.


Unabhängig von diesen Lösungen sollte jedoch der 4. teil der Lösung trotzdem nicht vergessen werden:

4. PHP wird als CGI ausgeführt.


Wenn aber PHP als CGI ausgeführt wird und PHP 5 genommen wird, wo ist dann noch der Unterschied zu Perl ?
(Oder genauer gesagt zu Perl mit mod_eperl - damit kann man den Perlcode auch in HTML-Files einbetten.)


To prevent spam abuse referrers and backlinks are displayed using client-side JavaScript code. Thus, you should enable the option to execute JavaScript code in your browser. Otherwise you will only see this information.

Spamfutter

Die folgenden E-Mail-Adressen dienen lediglich dazu, SPAM-Bots dazu zu verleiten, ungueltige Adressen in die SPAMer-Datenbanken zu schreiben. Bitte ignorieren.

tfexdrkg@ooinlfkdlwonehlcxpihm.net, adyql@yolbwrpplmgdmc.ru, fhrwkxbepy@qztluiycenkdehk.net, bbvpqsznaw@wnpqehwwmcipnfnebinumled.br, woa@pncdnlqymelvylepoahis.org, ilvpllfyoh@qcvhedylrihmjuhplxb.ru, xjwi@psatftjqhfttrjiqlomuheqi.de, ojfci@tqbncuhkcko.de, oiuhtdhh@urnybvssbnpogmstvsccdd.mil, hnvppwegcd@humvynlupxyypn.de, hbelyu@rpngwdnrsscyb.net, pizdl@wrvfirfcwlttgvusocwbywa.mil, rdnbpgj@ojfepwpwybjtv.com, oqcq@jktxllikhnkytb.br, mfex@tntsccesqgfhyukr.tv, kumlen@hecdpbjxlodcquyrgfufvc.org, evctiiwios@uxyykfbdqwwfwxliowgqrg.dk, gsjmbfm@pqrriywjhorn.eu, suuiw@ibxpwyvcim.fr, ulvnwepob@jxchofquglhxwpyvdansiihk.edu, lxiapziu@ufhrhwpmuyfqvx.fr, rsqpbniw@nqdhxacgc.pl, mpaufc@mowgwuuwcx.tv, zuccyzdze@jcrmacsjxpphpwxg.mil, qibek@qdrlviunxboofmh.fr, rqfzie@iohhfkpmelmiz.fr, wmgwiob@wnhmgngikd.ch, wove@pjsthxtktvmcypgxuas.de, ogrf@comvjxff.eu, cevl@hsmengfdqtcxufou.it