Das neue Wordpress 1.5.2 soll endlich das lahme Posten - verursacht durch das Pingen - beheben, in dem das Pingen in den Shutdown geschoben wird, also hinter die eigentliche Request-Response-Kette. Auf Deutsch: mit der 1.5.2 sollte das Pingen nicht mehr ein ewiges Warten auf den Browser verursachen. Wäre ja sehr nett, wenn das auch klappt.
Da auch Security-Fixes drin sind, ist eh ein Upgrade sinnvoll. Wobei WordPress für eine PHP-Anwendung erstaunlich stabil funktioniert - aber eben trotzdem durchaus noch die eine oder andere Leiche im Keller gammelt.
Update: naja, schneller ist das ja nun doch eher nicht geworden beim Posten ...
Alex Knaub Aug. 14, 2005, 11:57 p.m.
ein Lesetip, passend zum Thema, http://blog.php-security.org/archives/4-WordPress-a-hackers-paradise.html
hugo Aug. 15, 2005, 9:14 a.m.
Nunja, register_globals ist ein krankes PHP-Problem das immer im Hintergrund lauert. Wer auf seinem Host das Flag aktiviert hat, hat eh mehr Probleme als sonstwas. Allerdings stimme ich der Meinung des von dir verlinkten Autors nicht zu, das es ordentliche PHP-Programme ohne Sicherheitslöcher gäbe - sorry, aber da sollte er besser die rosa Brille abnehmen, viele der Sicherheitsprobleme in PHP-Anwendungen liegen in der Plattform PHP begründet.
Hätte ich mehr Zeit, wäre WordPress wohl schon wieder runtergeflogen. Im Laufe des WordPress-Einsatzes habe ich viel mehr über PHP und die Probleme gelernt als mir lieb ist - und meine Abneigung gegen PHP und den glorifizierten Karteikasten noch verstärkt.
Mal gucken ob ich im Urlaub Zeit für vernünftige Lösungen finde. Wenigstens ne anständige Gummizelle für die PHP-Anwendungen werd ich hoffentlich zusammenbekommen, das reduziert zumindestens mal die Gefahr die sich aus einem Einbruch ergibt. Defacements kann man ja mit Backups beseitigen wenn der Einbruch wirklich nur auf die PHP-Anwendung begrenzt bleibt.
Zugegebenermaßen ist eines der Grundrisiken bei PHP allerdings weniger PHPs Fehler, sondern der Fehler der Betreiber, die PHP fast immer direkt in den Apache laden (mache ich hier ja auch noch - wird sich aber definitiv ändern), wärend man mittels FCGI und eigenem chroot-jail für PHP schon einiges sicherer fährt.
Alex Knaub Aug. 15, 2005, 8:54 p.m.
Ich stimme dir darin zu, dass die PHP-Plattform inhärent unsicher
ist, bzw. sehr wenig für Sicherheit tut.
Zusätzlich würde ich noch einen Aspekt anprechen wollen, der meiner Meinung nach oft nicht berücksichtigt wird, nämlich die Qualität der PHP-Community. Schau Dir das Niveau von de.compl.lang.php*, der aktuellen PHP-Bücher, der Folien der PHP-Gurus, die Qualität der Vorträge auf den PHP Konferenzen an. In der PHP-Community ist es gang und gäbe, dass man nach einem Semester Java sich dazu befähigt füllt ein OOP und/ oder Patterns Buch für PHP schreiben zu können.
Oder ohne die geringste Ahnung der funktionalen Programmierung einen Vortrag mit dem Thema "Funktionales Programmieren mit Iteratoren" auf der PHP-Konferenz in Frankfurt hält und sich dabei aufs übelste blamiert.
Weil PHP so ausdrucksarm ist, verfügt diese Sprache über keine anerkannten Idiome. Jeder Python-, Ruby-, Lisp - Programmierer weiss ganz genau, ob ein Stück Code "pythonic", "rubish" oder "lispy" (gut, beim LOOP - Macro ist man sich nicht so einig ;) ) ist. Und wenn man es nicht weiss, dann wird einem die entsprechende Community bei der Urteilsfindung schon helfen.
Man vermisst in der PHP-Community auch gute Programmierer, die als solche von vielen anerkannt sind. Man schaue sich die Postings der PHP-Devs auf der internals-Mailingliste an. Es ist immer wieder überraschend wie schlecht sich *alle* Devs mit OOP, dynamischen Sprachen, modernem Compilerbau auskennen. Immer wieder führen die Devs Java oder C++ als Referenzbeispiel an, wenn es darum geht einigermassen kreative, neue Sprachfeatures abzulehnen.
PHP fehlt einfach die Kultur und Tradition des guten Code. Es gibt keine Standards, keine Autoritäten, keine Vorbilder. Am deutlichsten sieht man den Unterschied der Mentalitäten zwischen der PHP-Community und z.B. der Ruby-Community, wenn man diese zwei Interviews der Erschaffer der beiden Sprachen liest. Der eine ist ein frustrierter Hacker, der ein, nach seiner Meinung hässliches, Problem lösen will. Der andere ist ein Sprachliebhaber, der für Eleganz und Ästhetik steht.
http://www.oracle.com/technology/pub/articles/php_experts/rasmus_php.html
http://www.cips.ca/news/national/news.asp?aID=1224
bwolf Aug. 15, 2005, 10:25 p.m.
Ja ein gutes Argument. Genauso habe ich es seit einiger Zeit am start. PHP als separater FASTCGI-Prozess pro Applikation in einem chroot, auf das lighty per unix-domain socket zugreift. Ein schlankes PHP mit auf die Applikation abgestimmter php.ini hilft.
hugo Aug. 16, 2005, 9:04 a.m.
PHP ist ähnlich entstanden wie Perl - jemand ohne Ahnung von Programmiersprachendesign hat erstmal nur einen Hack geliefert und dieser Hack ist leider nicht gleich ersäuft worden, sondern hat weiter gelebt und neue Versionen produziert. Perl hat ähnlich viele Warzen und komische Ecken. Allerdings haben die Perl-Leute relativ früh Ansätze für sichere Programmierung integriert - z.B. der Taint-Mode liefert automatisch bei ungeprüften Strings ein Flag welches bei kritischen Funktionen für einen Fehler sorgt, nur geprüfte Strings dürfen dann in diesen kritischen Funktionen (alles was ans System übergibt) genutzt werden.
Ähnliches ist bei PHP mit dem safe mode gemacht worden - mit ähnlichen Problemen. Kein Schwein benutzt es. Denn es ist optionale Sicherheit - und mit vielen Projekten kollidiert das ganze dann heftig, weil deren Programmierer von Security nicht die blasseste Ahnung haben und daher natürlich auch die entsprechenden Security-Modelle schlicht ignorieren.
Schon ziemlich nervig wie oft gerade diese beiden - PHP und Perl - in den Security-News auftauchen mit wieder einer tollen Lösung. Und man merkt dabei auch, das es nicht unbedingt daran liegt das die PHP-Sachen kein entsprechendes Alter haben - bei Perl tauchen auch immer wieder alte Schinken wieder auf mit neuen Löchern oder neu entdeckten Löchern.
Übrigens haben beide nochwas gemeinsam: beide haben ihre aktuelle Version (ok, Perl 6 ist noch in der Mache) die alle Probleme der Sprache bereinigen soll. Und bei beiden sehe ich irgendwie zwar eine aufgeräumtere Syntax und rudimentäre Bereinigungen der Semantik, aber am Security-Modell haben beide nix dazugelernt.
Aber zumindestens schreiben in der Perl-Community meistens Leute Bücher die von dem Thema über das sie schreiben auch wirklich Ahnung haben ;-)
Joe User Aug. 18, 2005, 4:26 a.m.
Von Stefan Esser gibt es auch den Hardening-Patch. Da ich von Beginn an einen weiten Bogen um PHP mache, kann ich leider nicht mit Erfahrungswerten dienen.
hugo Aug. 18, 2005, 9:04 a.m.
hab ich schon mal drüber geschrieben. Haber aber auch noch keine eigenen Erfahrungen damit gemacht - und der Patch nutzt eh nur Selbsthostern was, denn die meisten vorkonfigurierten Systeme haben halt das PHP drauf das der Provider meint auszusuchen. Und wenn man sich anguckt wie oft da das PHP mit register_globals=on installiert ist ...
bwolf Aug. 18, 2005, 10:26 a.m.
Ich finde nicht nur schlimm, dass bei PHP die Sprache gewachsen und zusammengestrickt ist, sondern wie mir scheint, oft auch wahllos Bibliotheken integriert werden, die evtl. nie dazu gedacht waren in einem Serverprozess integriert zu werden, der 24/7 im Betrieb ist. Eine Lib für Funktionalität X ist schnell geschrieben und wenn die ein mem-leak hat, dann ist das bei einem User-tool nicht so tragisch. Schließlich wird das irgendwann geschlossen und der Speicher wieder freigegeben.
Logisch, dass das bei Servern ganz anders aussieht. So führt ein Hack zum nächsten und man muss seinen Apache mit MaxRequestsPerChild kastrieren. Toll!