Developers Shame Day 2010

Verfasst am 03.11.2010 15:14:45, Arvid Bergelmir

Am 26. Oktober hat Cem Derin, auch bekannt als PH PHacker, in seinem Blog eine neue Idee in die Welt gesetzt - den Developers Shame Day. Dieser spezielle Tag soll nun jedes Jahr am 3. November stattfinden. Sicherlich stellt sich nun der ein oder andere die Frage, was das sein soll? Cem beschreibt diesen Tag wie folgt:

Ich stelle mir vor, dass an diesem Tag alle Entwickler, die ein Blog oder eine Seite betreiben, ein kleines Stück Code präsentieren, dass aus heutiger (oder vielleicht auch damaliger) Sicht total hirnverbrannt ist. Ein Stück Code, dass uns selbst die Schamröte ins Gesicht steigen lässt.

Eine interessante Idee, der ich natürlich auch etwas beitragen möchte. Ich habe mir vor ein paar Tagen schonmal die Frage gestellt, wo ich alten Code von mir finden kann. Alten Code, der wirklich schrecklich ist. Cem hatte in seinem Artikel erwähnt, dass er auf alten Backup-CDs gesucht hatte. Leider habe ich weder alte Backup-CDs, noch alte Festplatten. Also schon, aber nicht so alt, dass man darauf irgendwelchen wirklich alten und hässlichen Code finden könnte. Hört sich nun irgendwie so an, als würde ich behaupten, dass dort kein hässlicher Code zu finden sei. Klar würde ich da was finden, aber ich suche richtig alten Code!

Da kam mir meine erste .de-Domain in den Sinn, die ich je hatte. Die Seite selbst liefert nurnoch eine weiße Seite (wahrscheinlich ein E_FATAL, da die PHP-Version vor einigen Jahren auf 5.x geändert wurde), aber auf dem Webspace müsste sich doch was finden lassen. Leider fiel mir da auf, dass ich die Zugangsdaten auf einer alten Festplatte hatte, die ich natürlich entsorgt habe. Also musste mir der Support weiterhelfen. Nach einigem hin und her bekam ich neue Zugangsdaten und schon konnte es losgehen, den alten Webspace nach altem Code zu durchsuchen. Leider lies sich da auch nichts spektakuläres finden, was "Shame Code" von Nils Langner nahe kommen könnte, aber ich habe etwas gefunden, was ich keinem empfehlen kann zu machen.

Code eines Gästebuchs

Dabei handelt es sich um einen Teil eines meiner ersten Gästebücher. Nebenbei erwähnt, war ein Gästebuch der Grund, warum ich damals mit PHP angefangen habe. Die kostenlosen Gästebücher hatten mir alle viel zu viel Werbung.

Mit diesem Teil des Codes wurde ein Gästebucheintrag, in HTML Format, in eine Textdatei geschrieben. Da gibt es nun mehrere Fehler, von denen ich früher nichts wusste. Es funktionierte.

Register Globals Was man an diesem Code nicht direkt sehen kann ist, dass ich damals kein $HTTP_POST_VARS oder $_POST verwendet habe, sondern einfach nur $name oder $email. Das Stichwort dabei lautet register_globals was zum Glück schon lange in PHP deaktiviert ist und in kommenden PHP-Versionen rausgeschmissen wird. Damit war es möglich ohne $_POST und $HTTP_POST_VARS auf GET/POST/COOKIE zuzugreifen. Die Variable $name in diesem Skript entspricht also grob gesehen einem heutigen $_REQUEST['name'].

Filterung Was ebenfalls nicht direkt ersichtlich ist, da ich nur einen Ausschnitt des Codes gepasted habe, ist, dass überhaupt nicht gefilter wird. Man hätte also leicht irgendwelchen Schadcode übermitteln können. Früher war das nicht schlimm, da es kaum einen gab, der sowas versucht hat. Heutzutage weiß jeder x-te Internetnutzer wie man Anfragen manipuliert (z.B. mit dem Firefox Plugin UrlParams), SQL-Injections durchführt oder Sessions klaut. Es gibt ganze Gruppen oder Firmen, die sich genau auf diese Probleme spezialisiert haben. Daher sollte die Filterung (z.B. mit den filter-Funktionen von PHP) heute einer der ersten Punkte sein, wenn man eine neue Anwendug entwickelt.

Datenformat Was mich früher schon immer wieder gestört hat, wo ich aber keine Lösung drauf wusste war, dass die Einträge als HTML in die Datei geschrieben wurden. Da ich gerne und oft etwas am Aussehen meiner Homepage gemacht habe, musste sich natürlich auch das Gästebuch diesen Änderungen fügen. Also musste ich die Datei, in die Einträge gespeichert wurden, anpassen und das HTML an die neuen Anforderungen anpassen. Meist habe dadurch das Format der Datei kaputt gemacht und das Gästebuch lief danach nicht mehr, wodurch ich die Datei leeren musste. Um dieses Problem zu lösen, sollte man die Daten immer getrennt voneiander speichern. Ich meine nun nicht, in separaten Dateien, sondern in Spalten und Zeilen. Spätere Entwicklungen des Gästebuchs waren so angepasst, dass die Daten kommasepariert (CSV) in eine Datei geschrieben wurden. Somit gab es schonmal eine Trennung zwischen den Daten (Model) und der Ausgabe (View). Aber auch diese Art der Speicherung war nicht optimal, da ich bei Anpassungen oft die Umbrüche kaputt gemacht habe, was uns zum nächsten Punkt bringt.

Datenbank Die Daten sind in einer relationalen Datenbank besser aufgehoben. Heute würden sogar einige sagen, dass sie in dokumentbasierten Datenbanken (z.B. CouchDB) noch besser aufgehoben seien, aber das soll erstmal nicht das Thema sein. Bei Datenbanken übernimmt das System selbst die Speicherung und das Auslesen. Man übergibt die Daten an die Datenbank (INSERT), die Datenbank speichert die Daten und man kann sie auch ganz leicht wieder auslesen (SELECT), ändern (UPDATE) oder löschen (DELETE) ohne, dass man das Format kaputt macht. Ein weiterer Vorteil ist, dass man auch Einträge irgendwo in der Mitte löschen kann. Bei dem Gästebuch aus dem Codeschnipsel oben, ist es schwer herauszufinden, wo ein Eintrag anfängt und wo er aufhört, somit war es schwer einen Eintrag zu löschen. Ansich war es sogar schwer den ersten und/oder den letzten Eintrag zu löschen. Eine spätere Version des Gästebuchs nutze dann SQLite, was mein Webhosting-Anbieter glücklicherweise unterstützte. Man braucht keine Datenbanksystem um die Daten zu speichern und man konnte ganz einfach per SQL auf die Daten zugreifen und sie manipulieren.

Murphys Gesetz Woran ich bei diesem Code nicht geachte habe ist, dass das Schreiben auch einmal fehlschlagen kann. In einer perfekten Welt würde das zwar nicht passieren, aber leider leben wir in keiner perfekten Welt und wir haben Murphys Gesetze. Das erste Gesetz besagt: "Wenn etwas schiefgehen kann, dann geht es schief". Also sollte man immer auf alle Fehler reagieren und sie vernünftig handhaben. Entweder kann man dem Benutzer eine Fehlermeldung anzeigen oder man löst einen Ausnahmefehler aus, der dann z.B. geloggt wird, damit man ihn nachvollziehen und korrigieren kann.

Validität Der unkritischte Fehler in diesem Codeschnipsel ist das HTML. Es ist nicht gültig, es wird HTML, mal CSS zum stylen verwendet und die Werte der Attribute sind nicht in Anführungszeichen eingeschlossen. Es ist weniger ein Fehler, es ist eher unschön. Trotzdem sollte man heute, z.B. mit Hilfe des W3C Markup Validators, darauf achten, dass sein HTML und CSS Code valide ist.

Ich muss sagen, es war hart diesen Artikel zu schreiben. Oftmals wollte ich schreiben, dass ich Sicherheitsprobleme o.ä. ignoriert habe, da es eh keinen gibt, der diese ausnutzen könnte. In Wirklichkeit wusste ich früher von solchen Problemen erst garnicht. Das Gästebuch funktionierte, es gab keinen Spam, kein XSS und auch keinen der irgendwelche Sicherheitslücken versucht hat zu finden. Das hat sich zum Glück geändert. Zum einen weiß ich nun, wie und wo Sicherheitslücken auftreten und zum anderen gibt es nun Leute die Sicherheitslücken aufspüren und sie melden, denn nur so werden unsere Anwendungen sicherer.