Moin!

»» Warum gibt es keine Analyse in der Form, die du gerade präsentiert hast?
»» So bleibt die Neutralität gewährleistet und man kan anhand objektiver Kriterien entscheiden.

Hm, "neutral"...

Jetzt gibt es sie. Die beiden verlinkten Seiten gibt's aber schon etwas länger, und dort gibt es auch nochmal ganz ansehnliche Linksammlungen.

Ja, aber sie sind auch schon uralt und beziehen sich auf die Situation vor fünf Jahren.

Seitdem hat sich bei PHP eine Menge getan. Und bei Perl?

Ich gebe zu, dass ich zwei Standard-Aussagen von mir zu PHP schlicht und ergreifend vergessen habe, die ich meinen Kunden und Chefs immer wieder an den Kopf werfe:

1. "Pubertierende Hauptschüler Programmieren"
2. "Es gibt zwei Arten, PHP zu betreiben: Unsicher und abgeschaltet."

Zwei Polemiken, die nicht gerechtfertigt sind.

Nummer 1 ist ein Doppel-Vorurteil, das ich in aller Regel etwas länger begründe. Kurz gesagt ist die Code-Qualität bei PHP oft unter aller Sau, weil PHP es so leicht macht, auf den ersten Blick brauchbare Ergebnisse zu produzieren.

Bei Perl genauso. Die Qualität des Codes hängt direkt proportional von den Fähigkeiten des Programmierers ab, aber gar nicht von den Eigenschaften der Programmiersprache.

Bei genauerer Betrachtung stellt man dann aber fest, das sehr viel fehlt: Sicherheitsprüfungen, edge cases, locking, escaping, usw. PHP ist ein hervorragendes Rapid Prototyping Tool für Web-Anwendungen, eben weil man schnell eine Demo zusammenhacken kann. Aber für den Produktiveinsatz ist eine solche Demo in aller Regel ungeeignet, und PHP steht dem Entwickler dann sehr im Weg, wenn er aus der Demo eine Produktivversion bauen soll.

Du wirst zugeben, dass diese Behauptung schlicht unbewiesene Polemik ist. Nimm einen Programmierer, der Perl schlecht kann, und lass ihn irgendeine Demo zusammenhacken, da wird auch Code rauskommen, den man eigentlich direkt in die Tonne tritt, wenn's danach weitergehen und produktiv werden soll.

Nummer 2 ist eine grobe Vereinfachung. Natürlich kann man PHP sicher betreiben, aber der notwendige Aufwand und das notwendige Wissen überschreitet die Fähigkeiten des typischen PHP-Coders bei weitem.

Schlechte Coder schreiben schlechten Code. Wo ist da der Bezug zur Programmiersprache?

PHP selbst macht es einem sicherheitsbewußten Entwickler oder Administrator nicht leichter. Ich möchte nicht dafür garantieren müssen, dass ein PHP-Server so sicher konfiguriert ist, dass niemand eindringen kann. Für meine Perl-basierten Anwendungen lege ich die Hand ins Feuer.

Auf den SELFHTML-Servern läuft PHP und Perl für unterschiedliche Anwendungen. Ich habe bislang noch keinen Eindringlingszwischenfall feststellen müssen.

Spätestens die routinemäßigen Angriffe auf gar nicht vorhandene PHP-Anwendungen (typischerweise phpMyAdmin und phpBB) in den Server-Logs bestätigen meine Einstellung zu PHP immer wieder.

Und die routinemäßigen Angriffe auf IIS-Schwachstellen etc. existieren ebenfalls, sind nach meiner Wahrnehmung deutlich häufiger, und beweisen trotzdem nicht, dass der aktuelle IIS ein unsicherer Webserver ist.

Natürlich bedeutet der Einsatz von Perl nicht automatisch Sicherheit. Die Behauptung, dass allein die Wahl der Programmiersprache eine Anwendung automatisch 100% sicher macht, überlasse ich lieber den Java-Propagandisten.

PHP tritt mittlerweile erfolgreich an, Java an vielen Stellen des Servereinsatzes für Webapplikationen Konkurrenz zu machen.

Wer keine Ahnung hat, kann mit Perl mindestens genauso viel Schaden anrichten wie mit PHP. *hust* Matt Wright *räusper*

Eben. Das ist genau der Punkt: Schlechter Programmierer == schlechter Code. Programmiersprachenunabhängig.

Der Punkt ist schlicht und ergreifend, dass Perl mir Werkzeuge gibt, Standard-Fehler zu vermeiden: warnings, strict, Taint Mode, und einen großen Satz gut geprüfter Standard-Libraries. Es versucht allerdings nicht, Standard-Fehler ungefragt durch Automatiken zu reparieren (Magic Quotes).

Der Standard-Auslieferungszustand für magic_quotes ist "aus", das Feature ist in Version 5.3.0 deprecated und wird in 6.0 rausgeworfen werden, weil die PHP-Entwickler erkannt haben, dass diese Automagie problematisch ist. Darauf weiter herumzureiten ist also nicht hilfreich.

Sowas wie "Warnings" und "Strict" kriegt PHP eigentlich auch ganz gut hin, um zur Entwicklungszeit ungünstige Konstrukte anzumeckern. Die Standard-Librarys sind bei PHP entweder direkt einkompilierte Module, oder etwas aus der PEAR-Bibliothek.

Und der taint mode - naja, fühlt sich auch eher wie ungute Automagie an - bei PHP war sowas ja böse... :)

Abgesehen davon gibt es auch für PHP Erweiterungen, die die Sicherheit im laufenden Betrieb erhöhen - ich weise da nur mal auf Suhosin hin, sehr empfehlenswert.

Die Tatsache, dass Perl nicht bei jedem Hosting-Paket verfügbar ist, und nicht komplett ohne Nachdenken aktiviert werden kann, sortiert schonmal die komplett Ahnungslosen aus. Kleine Gemeinheiten einiger Hoster (Perl ist in /opt/local/perl5/bin/perl statt in /usr/bin/perl) verstärken das noch. Effekt: "Mit PHP ist das alles viel leichter und einfacher". Das sorgt dafür, dass es weniger Ahnungslose auf der Perl-Seite gibt und mehr auf der PHP-Seite. Oft setzen die Hoster alte bis antike Perl-Versionen ein, so dass nicht jedes irgendwo zusammenkopierte Perl-Script sofort läuft. Das schiebt noch mehr Leute zu PHP. Shell-Zugriff gibt es oft gar nicht, an das Error-Log kommt man nur sehr umständlich oder gar nicht heran, und wenigstens 1&1 macht mit Perl *SEHR* merkwürdige Sachen über mod_rewrite und einen selbstgestrickten Wrapper. Das sind noch mehr Hürden, die noch mehr Laien zu PHP treibt und von Perl fernhält.

Und das sind alles Dinge, die man auch als Perl-Entwickler nicht haben will, weil es ein echt blöder Extra-Aufwand ist, den man lieber mit sinnvolleren Dingen zubringen würde.

Klar, die leichtere Zugänglichkeit von PHP für den Einsteiger ist der Grund, warum man heute viel leichter PHP-Entwickler finden kann, und mit etwas Suchen auch ausreichend qualifizierte Kräfte. Bei Perl ist das schon deutlich schwieriger - was auch ein Grund dafür sein kann, warum Perl keine Sprache ist, die für Webapplikationen riesige Verbreitung gefunden hat.

Der für Perl-Entwickler sehr positive Effekt ist, dass sich die meisten Black Hats auf die leichten Ziele einschießen. Warum sich an Perl die Zähne ausbeißen, wenn man von Laien draufkopierte und nicht ansatzweise abgesicherte phpMyAdmin- und phpBB-Installationen in Massen übernehmen kann? Das gleiche Spiel wie bei Windows vs. MacOS/Linux und IE vs. FF/Opera.

Du meinst, es ist gut, wenn Sicherheitslücken zwar eingebaut, aber nicht ausgenutzt werden, weil sich eh' niemand dafür interessiert, weil die Sprache als obsolet betrachtet wird? :)

- Sven Rautenberg