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

PHP wird von manchen Personenkreise als "per se unsicher" verschrien; unglücklicherweise sind die meisten Webanwendungen in PHP geschrieben, so daß diejenigen, die PHP vermeiden wollen, eine sehr eingeschränkte Auswahl an Software haben. Immerhin gibt es unter diesen Leuten nicht nur Nörgler, sondern auch Bestrebungen, die Situation zu ändern: So gibt es als Reaktion darauf dieses Jobangebot, einen Webshop in Python zu entwickeln - vorzugsweise mit Django, Ruby mit Rails ist als Option aber auch nicht ausgeschlossen.

Das Argument von PHP-Freunden, das ich immer wieder höre, lautet, daß gerade die Menge an Webanwendungen doch ein Indiz dafür sei, daß die Meinung der Kritiker übertrieben sei; ein Blick auf die Entstehungsgeschichte von PHP erläutert, wieso das nicht ganz korrekt ist.

PHP war ursprünglich gar keine separate Sprache, sondern eine Sammlung von Perl-Funktionen, welche das Erstellen einer privaten, dynamischen Homepage erleichtern sollten. Daher auch das Akronym: PHP steht für nichts anderes als "Personal HomePage". Mit steigender Zahl an Funktionen (und der Problematik, daß manche davon in Perl einfach langsam waren) entschied sich der Entwickler, die Bibliothek in C neuzuschreiben; die wenigen Sprachfeatures, die man von Perl noch benutzte, implementierte man kurzerhand mit. Kurz nach der Veröffentlichung dieser Version (PHP/FI 2.0) bildete sich eine Gruppe von Entwicklern, die zusammen mit dem ursprünglichen Autor einen erneuten Rewrite der Sprache in Angriff nahmen, da ihrer Meinung nach die Mächtigkeit für eCommerce-Applikationen zu gering war. Dieser Rewrite wurde schließlich als PHP 3.0 veröffentlicht.
All das geschah im Zeitraum zwischen 1995 und 1998 - also gerade in dem Zeitraum, in dem die Dot-Com-Blase gerade begann, sich so richtig aufzublähen. "Das Internet"und eCommerce waren in aller Munde, Investoren waren bereit, astronomische Summen herzugeben, wenn nur das versprochene Produkt eher gestern als heute fertig wäre. In diese "Goldgräber-Stimmung" stiegen viele Entwickler (oder solche, die es noch werden wollten) ein - und suchten nach Tools, welche die Realisierung ihrer Projekte möglichst einfach machen würden. PHP machte als Tip die Runde, bald war auf mehr als 10% aller Webserver PHP installiert.

Kritisch betrachtet ist also ein kleines, organisch gewachsenes Projekt in kurzer Zeit im Hype "explodiert". Durch die "weiche Migration" von Perl zur eigenständigen Sprache wurden viele Perl-Altlasten mitgeschleppt, über ein eigenes Sprachkonzept machte man sich zu dem Zeitpunkt wohl keine Gedanken; später war PHP dann bereits so verbreitet, daß man die Abwärtskompatibilität möglichst weit wahren wollte. Die Codequalität von PHP selber war in Bezug auf ihre Sicherheit und Robustheit auch sehr durchwachsen - Stefan Esser (altes Blog hier) tat sich besonders als emsiger Fehlerfinder in PHP hervor (um ihn herum entstand auch das Hardened PHP Project). Immer öfter kritisierte Stefan Esser aber nicht nur einzelne Unsauberheiten, sondern konzeptuelle Probleme von PHP, welche leicht zu Sicherheitslücken führten. Beim Kernteam von PHP stieß er damit meist auf taube Ohren, so daß er Ende 2006 das Handtuch hinwarf und das PHP Security Response Team verließ.

Das schnelle und einfache Erstellen einer Anwendung stand bei PHP immer im Vordergrund (was gut in die oben geschilderte Zeit paßt); anders kann ich mir beispielsweise Features wie register_globals nicht erklären. Sicherheit von Webanwendungen rückte erst etwas später in den Fokus der Öffentlichkeit; viele Entwicker machten sich diesbezüglich entweder keine Gedanken, oder waren der Thematik gänzlich fremd, so daß ihnen die Probleme überhaupt nicht auffielen.

Ich denke, dies erklärt den vermeintlichen Widerspruch zwischen der Verbreitung und der Sicherheit von PHP: PHP wurde als "Einsteigersprache für das Web" weiterempfohlen, viele Programmierer (teilweise Anfänger, deren allererstes Programm mit PHP entstand) zimmerten so ihre ersten Webanwendungen zusammen - ohne Bewußtsein für Web Security, und in einer Sprache, die das Öffnen von Sicherheitslücken besonders einfach macht.
Meinem (subjektiven) Empfinden nach entstehen momentan die meisten Sicherheitslücken in PHP-Programmen weniger durch Fehler in PHP, sondern durch Logikfehler in der Programmierung wie dem ungefilterten Verwenden von Benutzereingaben (Details in den Folien zu meinem Vortrag über Web Security). Grund hierfür dürfte die oben skizzierte "Anfänger-Empfehlung" zusammen mit dem fehlenden Bewußtsein für die Sicherheitsproblematik sein.

Man kann - so denke ich - auch mit PHP sichere Webanwendungen schreiben; doch sowohl die Sprache als auch die Sprachkonfiguration (also Einstellungen wie register_globals) machen es leider besonders einfach, sich bei der Entwicklung ein Kuckucksei zu legen. Als Einsteigersprache für Programmierneulinge würde ich von PHP abraten - allerdings weniger wegen der Sicherheitsproblematik, sondern wegen dem unschönen und unübersichtlichen Sprachkonzept. Andere Sprachen wie beispielsweise python sind deutlich strukturierter und "hübscher". Für neue Webanwendungen gibt es hervorragende Frameworks wie Django oder Ruby on Rails, welche die Anwendungsentwicklung deutlich beschleunigen, in ihren eigenen Innereien aber bereits ein besonderes Augenmerk auf die Sicherheit geworfen haben.

Wenn es vernünftige Alternativen zu PHP-Anwendungen in Sprachen wie Ruby oder Python gibt, würde ich diese bevorzugen. Leider sieht es da meistens recht dünn aus - aber zumindest bei Webshops könnte sich da ja demnächst etwas ändern (siehe obiges Stellenangebot) :-) Und falls jemand eine ernsthafte, in Python geschriebene Alternative zu Drupal kennt: Ich bin ganz Ohr...