Privacy- und Sicherheitsaspekte

Dissertation "Privacy- und Sicherheitsaspekte in ubiquitären Umgebungen" als Buch und als PDF
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...


webshop in python:
webshop in python: http://www.satchmoproject.com/
drupal-alternative:
- wenn's ne reine blog-engine sein soll: unter http://pypi.python.org/pypi?%3Aaction=index nach "blog" suchen (google hilft auch)
- wenn's ein vollwertiges CMS sein soll:
o plone.org <- sehr mächtig, hab damit schon etliche high-traffic sites realisiert
o unter http://pypi.python.org/pypi?%3Aaction=index nach CMS suchen, falls es was einfacheres sein soll :)
gruß,
igor
Re: webshop in python
Den Tip mit Satchmo habe ich inzwischen mehrfach bekommen - in der Tat, das Ding sieht richtig witzig aus. Falls ich mal einen Webshop brauche... ;-)
Blogmaker sieht so aus, als ob es ganz nett werden könnte, allerdings scheint das Modul dem Django Trunk hinterherzuhängen. Mir gruselt davor, auf ein Stück Software umzuziehen, bei dem dann plötzlich jeglicher Support fehlt.
Meine Gehversuche mit Plone sind zwar inzwischen drei Jahre (oder so) her - aber bei Plone 2 hatte ich das Gefühl, mir Pest und Cholera ins Haus zu holen. Abgesehen davon, daß es nicht möglich war, mit über einer Woche Arbeit ein primitives "hello world" zu realisieren: Die Mails auf der deutschen Plone-Liste waren wenig ermutigend... es schien als ob im Wochenabstand jemand mit dem Problem käme, daß seine ZODB (Zope Object Database) plötzlich korrupt sei - und die einzige Antwort, die man bekam, war die Frage nach einem externen Backup. Die Aussicht, daß sich die darunterliegende Datenbank ab und zu selbst zerstört, fand ich ausreichend gruselig, daß ich an dieser Baustelle nicht weitergearbeitet habe.
Zope/Plone und die Lasten des Alltags
Zope und Plone sind nicht gerade dafür bekannt, dass es einen leichten Einstieg gibt. Das kann ich aus meiner Erfahrung bestätigen. Ich habe auch einige Zeit gebraucht, mein Einstieg war aber zum Glück über "Plone, das Produkt" mit nur wenigen Anpassungen.
Seit einiger Zeit tut sich einiges bei Plone, auch wenn der Einstieg in ein "kleine" Framework immer leichter sein wird als in eine Umgebung wie Plone.
So gibt es inzwischen ein Dokumentationsteam, dass gute Fortschritte macht. Das Ziel für Plone 4 ist, vom Umfang und der Anzahl der verwendeten Techniken zu schrumpfen. Bereiche, in denen verschiedenen Komponenten zum Ziel führen, sollen vereinheitlicht werden.
Auf der Zopeseite wird daran gearbeitet, einen kompakten "Zope Framework" Kern bereitzustellen, der sich leichter erschließt. Außerdem gibt es mit Grok ein Projekt, dass auf Zope aufbaut und es mit Konzepten wie "DRY" (Don't repeat yourself) und "Convention over Configuration" verbindet, die Django, RoR, Grails, etc. so beliebt machen. Das Zope3 Leitbild ist ja, dass alles konfiguriert werden kann und muss, was zu einem guten Teil zu Deinen Anfangsproblemen beigetragen haben dürfte. Die Masse an Techniken die man bei Grok kennen muss, um loszulegen, ist ähnlich klein wie bei anderen "beliebten" Frameworks. Hinten dran gibt's aber die ganze Leistungsbreite von Zope, auf die man zurückgreifen kann, wenn man sie braucht. Die Grok Dokumentation ist auch einsteigerfreundlich und es gibt einige kleine Beispielapplikationen.
Mit der ZODB hatte ich bisher (seit 2004) keine Probleme. Ich hatte damals auch nicht Deinen Eindruck, sonst hätte ich wie Du die Finger davon gelassen. Ich halte die ZODB für sehr robust. Emphirische Daten kenne ich nicht, aber ich halte den Eindruck einer unzuverlässigen Datenbank für falsch. (Mir hat es in den letzten Jahren zwei MySql Datenbanken zerbröselt und ich halte MySql deshalb nicht für unzuverlässiger. Shit happens. Backups sind die beste Versicherung ;-). Mit einem Wiederherstellen der Datenbanken wollte ich mich gar nicht erst rumschlagen.)
Ich empfehlen auch, die ZODB bei Pythonprojekten in Betracht zu ziehen, bei denen eine Objektdatenbank besser geeignet ist als eine relationale Datenbank.
Fortschritt - hoffentlich :-)
Hi Carsten,
danke für Deinen ausführlichen Kommentar; wie gesagt, meine Erfahrungen und Gehversuche liegen eine ganze Weile zurück - und es ist doch schwer zu hoffen, daß ein solches Projekt Fortschritte macht (und sich dabei um so grundlegende Probleme kümmert)! Und: Natürlich liest man auf Mailinglisten immer nur die Problemfälle - über die Anzahl derer, bei denen alles tadellos funktioniert, erfährt man nichts.
Sollte mal wieder ein Projekt in dieser Richtung anstehen, kommt natürlich alles neu auf den Tisch - eine Evaluation mit veralteten Daten und Erfahrungen bringt nicht viel ;-) Grok kenne ich nicht, ich bin gespannt, wie es sich dann (beispielsweise im Vergleich zu Django) platziert...