Die (Un)sicherheit von PHP - und ein nicht-PHP-Jobangebot

PHP wird von man­chen Per­so­nen­krei­se als "per se un­si­cher" ver­schrien; un­glück­li­cher­wei­se sind die meis­ten Web­an­wen­dun­gen in PHP ge­schrie­ben, so daß die­je­ni­gen, die PHP ver­mei­den wol­len, eine sehr ein­ge­schränk­te Aus­wahl an Soft­ware haben. Im­mer­hin gibt es unter die­sen Leu­ten nicht nur Nörg­ler, son­dern auch Be­stre­bun­gen, die Si­tua­ti­on zu än­dern: So gibt es als Re­ak­ti­on dar­auf die­ses Job­an­ge­bot, einen Web­shop in Py­thon zu ent­wi­ckeln - vor­zugs­wei­se mit Djan­go, Ruby mit Rails ist als Op­ti­on aber auch nicht aus­ge­schlos­sen.

Das Ar­gu­ment von PHP-Freun­den, das ich immer wie­der höre, lau­tet, daß ge­ra­de die Menge an Web­an­wen­dun­gen doch ein Indiz dafür sei, daß die Mei­nung der Kri­ti­ker über­trie­ben sei; ein Blick auf die Ent­ste­hungs­ge­schich­te von PHP er­läu­tert, wieso das nicht ganz kor­rekt ist.

PHP war ur­sprüng­lich gar keine se­pa­ra­te Spra­che, son­dern eine Samm­lung von Perl-Funk­tio­nen, wel­che das Er­stel­len einer pri­va­ten, dy­na­mi­schen Home­page er­leich­tern soll­ten. Daher auch das Akro­nym: PHP steht für nichts an­de­res als "Per­so­nal Home­Page". Mit stei­gen­der Zahl an Funk­tio­nen (und der Pro­ble­ma­tik, daß man­che davon in Perl ein­fach lang­sam waren) ent­schied sich der Ent­wick­ler, die Bi­blio­thek in C neu­zu­schrei­ben; die we­ni­gen Sprach­fea­tures, die man von Perl noch be­nutz­te, im­ple­men­tier­te man kur­zer­hand mit. Kurz nach der Ver­öf­fent­li­chung die­ser Ver­si­on (PHP/FI 2.0) bil­de­te sich eine Grup­pe von Ent­wick­lern, die zu­sam­men mit dem ur­sprüng­li­chen Autor einen er­neu­ten Re­wri­te der Spra­che in An­griff nah­men, da ihrer Mei­nung nach die Mäch­tig­keit für eCom­mer­ce-Ap­pli­ka­tio­nen zu ge­ring war. Die­ser Re­wri­te wurde schlie­ß­lich als PHP 3.0 ver­öf­fent­licht.
All das ge­schah im Zeit­raum zwi­schen 1995 und 1998 - also ge­ra­de in dem Zeit­raum, in dem die Dot-Com-Bla­se ge­ra­de be­gann, sich so rich­tig auf­zu­blä­hen. "Das In­ter­net"und eCom­mer­ce waren in aller Munde, In­ves­to­ren waren be­reit, as­tro­no­mi­sche Sum­men her­zu­ge­ben, wenn nur das ver­spro­che­ne Pro­dukt eher ges­tern als heute fer­tig wäre. In diese "Gold­grä­ber-Stim­mung" stie­gen viele Ent­wick­ler (oder sol­che, die es noch wer­den woll­ten) ein - und such­ten nach Tools, wel­che die Rea­li­sie­rung ihrer Pro­jek­te mög­lichst ein­fach ma­chen wür­den. PHP mach­te als Tip die Runde, bald war auf mehr als 10% aller Web­ser­ver PHP in­stal­liert.

Kri­tisch be­trach­tet ist also ein klei­nes, or­ga­nisch ge­wach­se­nes Pro­jekt in kur­zer Zeit im Hype "ex­plo­diert". Durch die "wei­che Mi­gra­ti­on" von Perl zur ei­gen­stän­di­gen Spra­che wur­den viele Perl-Alt­las­ten mit­ge­schleppt, über ein ei­ge­nes Sprach­kon­zept mach­te man sich zu dem Zeit­punkt wohl keine Ge­dan­ken; spä­ter war PHP dann be­reits so ver­brei­tet, daß man die Ab­wärts­kom­pa­ti­bi­li­tät mög­lichst weit wah­ren woll­te. Die Code­qua­li­tät von PHP sel­ber war in Bezug auf ihre Si­cher­heit und Ro­bust­heit auch sehr durch­wach­sen - Ste­fan Esser (altes Blog hier) tat sich be­son­ders als em­si­ger Feh­ler­fin­der in PHP her­vor (um ihn herum ent­stand auch das Har­de­ned PHP Pro­ject). Immer öfter kri­ti­sier­te Ste­fan Esser aber nicht nur ein­zel­ne Un­sau­ber­hei­ten, son­dern kon­zep­tu­el­le Pro­ble­me von PHP, wel­che leicht zu Si­cher­heits­lü­cken führ­ten. Beim Kern­team von PHP stieß er damit meist auf taube Ohren, so daß er Ende 2006 das Hand­tuch hin­warf und das PHP Se­cu­ri­ty Re­s­pon­se Team ver­ließ.

Das schnel­le und ein­fa­che Er­stel­len einer An­wen­dung stand bei PHP immer im Vor­der­grund (was gut in die oben ge­schil­der­te Zeit paßt); an­ders kann ich mir bei­spiels­wei­se Fea­tures wie re­gis­ter_­glo­bals nicht er­klä­ren. Si­cher­heit von Web­an­wen­dun­gen rück­te erst etwas spä­ter in den Fokus der Öf­fent­lich­keit; viele Ent­wi­cker mach­ten sich dies­be­züg­lich ent­we­der keine Ge­dan­ken, oder waren der The­ma­tik gänz­lich fremd, so daß ihnen die Pro­ble­me über­haupt nicht auf­fie­len.

Ich denke, dies er­klärt den ver­meint­li­chen Wi­der­spruch zwi­schen der Ver­brei­tung und der Si­cher­heit von PHP: PHP wurde als "Ein­stei­ger­spra­che für das Web" wei­ter­emp­foh­len, viele Pro­gram­mie­rer (teil­wei­se An­fän­ger, deren al­ler­ers­tes Pro­gramm mit PHP ent­stand) zim­mer­ten so ihre ers­ten Web­an­wen­dun­gen zu­sam­men - ohne Be­wu­ßt­sein für Web Se­cu­ri­ty, und in einer Spra­che, die das Öff­nen von Si­cher­heits­lü­cken be­son­ders ein­fach macht.
Mei­nem (sub­jek­ti­ven) Emp­fin­den nach ent­ste­hen mo­men­tan die meis­ten Si­cher­heits­lü­cken in PHP-Pro­gram­men we­ni­ger durch Feh­ler in PHP, son­dern durch Lo­gik­feh­ler in der Pro­gram­mie­rung wie dem un­ge­fil­ter­ten Ver­wen­den von Be­nut­zer­ein­ga­ben (De­tails in den Fo­li­en zu mei­nem Vor­trag über Web Se­cu­ri­ty). Grund hier­für dürf­te die oben skiz­zier­te "An­fän­ger-Emp­feh­lung" zu­sam­men mit dem feh­len­den Be­wu­ßt­sein für die Si­cher­heits­pro­ble­ma­tik sein.

Man kann - so denke ich - auch mit PHP si­che­re Web­an­wen­dun­gen schrei­ben; doch so­wohl die Spra­che als auch die Sprach­kon­fi­gu­ra­ti­on (also Ein­stel­lun­gen wie re­gis­ter_­glo­bals) ma­chen es lei­der be­son­ders ein­fach, sich bei der Ent­wick­lung ein Ku­ckucks­ei zu legen. Als Ein­stei­ger­spra­che für Pro­gram­mier­neu­lin­ge würde ich von PHP ab­ra­ten - al­ler­dings we­ni­ger wegen der Si­cher­heits­pro­ble­ma­tik, son­dern wegen dem un­schö­nen und un­über­sicht­li­chen Sprach­kon­zept. An­de­re Spra­chen wie bei­spiels­wei­se py­thon sind deut­lich struk­tu­rier­ter und "hüb­scher". Für neue Web­an­wen­dun­gen gibt es her­vor­ra­gen­de Frame­works wie Djan­go oder Ruby on Rails, wel­che die An­wen­dungs­ent­wick­lung deut­lich be­schleu­ni­gen, in ihren ei­ge­nen In­ne­rei­en aber be­reits ein be­son­de­res Au­gen­merk auf die Si­cher­heit ge­wor­fen haben.

Wenn es ver­nünf­ti­ge Al­ter­na­ti­ven zu PHP-An­wen­dun­gen in Spra­chen wie Ruby oder Py­thon gibt, würde ich diese be­vor­zu­gen. Lei­der sieht es da meis­tens recht dünn aus - aber zu­min­dest bei Web­shops könn­te sich da ja dem­nächst etwas än­dern (siehe obi­ges Stel­len­an­ge­bot) :-) Und falls je­mand eine ernst­haf­te, in Py­thon ge­schrie­be­ne Al­ter­na­ti­ve zu Dru­pal kennt: Ich bin ganz Ohr...