Immer wieder hört man von Sicherheitslücken in PHP anwendungen welche Ausführen von beliebigem PHP-Code erlauben. Gerade habe ich wieder einen solchen Artikel gelesen [1] und ich frage mich, warum es immer PHP-Projekte trifft. Ich kenne mich leider mit PHP zuwenig aus und kann deshalb nicht beurteilen ob das ein allgemeines PHP-Problem ist, oder von den Entwicklern einfach nur massig Mist gebaut wird.
Ich habe mir jedenfalls mal den Code von Mambo näher angeschaut und muss sagen, dass mir dieser nicht gerade geheuer ist. Wochen später bestätigen sich dann meine Befürchtungen und es wurde in Mambo eine solche Sicherheitslücke bekannt.
In Perl wäre so etwas ja nur möglich, wenn über einen Userinput explizit ein eval laufen würde - aber wer programmiert denn sowas?
Was ist so Grundverschieden an PHP und Perl, dass PHP massig solche Dinge zulässt? Muss man bei PHP-Code prinzipiell vorsichtiger sein?

[1] http://www.heise.de/security/news/meldung/73872

naja, prinzipiell muss man da nicht allzu viel angst haben. register_globals immer auf off halten.

ich denke, es geht da ja um code- und sql-injections

sql ist insofern bei php oft problematisch, weil sich bei phpprogrammierern offenbar nie durchgesetzt hat, dass man userinput quotet (am besten auch prüft, aber quoten ist ja schon mal was), so ist es möglich, sql an die db zu senden und dann teils beliebige tabellen zu löschen oder daten zu verändern.

die code-injections stelle ich mir erstmal so vor, dass a) mit url_fopen = on gearbeitet wird, dh wenn man eine url mit include einbindet, holt php sie und führt fröhlich das aus, was zurückkommt. wenn nun irgendwer mit dynamischen includes arbeitet und man kann diese umbiegen und auf eine beliebige url schicken, dann ist's einfach. b) dynamische includes und irgendeine datei wird mit userinput geschrieben und kann dann includet werden. kA, ob's noch was gibt, aber ich bezweifle, dass es etwas grundlegendes ist, sonst wäre ja jedes phpscript angreifbar. ich denke, es liegt eher daran, dass bei größeren opensource-projekten bei php eine ganze menge amateure hacks beisteuern oder an der core-entwicklung beteiligt sind. man schaue sich nur mal schön oscommerce an und erfreue sich daran :)

sowas ist dann meistens nicht die schuld der programmiersprache, sondern liegt oft an der Unwissenheit der Authoren.

Naja nun kann es die Programmiersprache dem Autor gerade sehr leichtmachen etwas so falsch zu machen, dass daraus eine Sicherheitslücke resultiert.
Wenn z.B. prinzipiell alles Ausgeführt würde was man zuteilt; ausser man verhindere das mit uneval wären daraus resultierende Sicherheitslücken auch des Autors Schuld:


Es scheint mir bei der oben erwähnten Sicherheitslücke doch ziemlich komisch, dass der Inhalt bei "[[ inhalt ]]" ausgeführt wird. Und irgendwie bezweifle ich, dass die Entwickler einen eval auf den Input ausführen...
Wenn man den Securityfix anschaut, lässt sich nämlich für einen Normalsterblichen-Nicht-PHPler nicht erkennen wo der Fehler war. Auch ist weit und breit kein eval zu sehn... (habe das Beispiel leider nicht zur Hand).
Ich glaube mal erfahren zu haben, dass mitgegebene Variablen in PHP prinzipiell gleich den mitegebenen Namen tragen:



Wenn das nämlich so wäre, wäre das ein solches Beispiel wo die Programmiersprache die Fehleranfälligkeit herausfordert.

Quote

Ich glaube mal erfahren zu haben, dass mitgegebene Variablen in PHP prinzipiell gleich den mitegebenen Namen tragen:

das ist nur so, wenn register_globals = on in der php.ini definiert ist. schwachsinnige idee am anfang, mittlerweile ist es per default auf off.

Leider gibts aber immer noch PHP-Anwendungen, die register_globals=on brauchen...
Ausserdem: fuer den Anfaenger isses so doch schoen praktisch :p

daher sollte man dann auf solche anwendungen lieber verzichten, was anderes nehmen oder sie selbst implementieren. dauert länger, kostet mehr. aber auch wenn man mir für jede backdoor, die ich auf meinem server installiere, 5 euro gibt, werde ich's nicht tun.

auf den meisten servern, die ich betreue, ist php einfach gar nicht installiert und der apache hat anweisung, jeden request, der auf .php endet, direkt umzuleiten auf ein script, das dann temporär die ip vollständig blockt. trotzdem haben wir endlos viele scriptkiddies täglich in den logs, die auf phpbb/joomla/insertphpapp-exploits-jagd sind.

@jan: n * 5 Euro.... hmmm, wenn n gross genug ist und du den server ausgeschaltet lassen kannst, warum eigentlich nicht? ;-)

ja, schade eigentlich, dass zend php nicht besonders promoten will und geld für jede phpbb-installation zahlt ;)