(Ich hoffe, dass die Entwickler von Partyguide.ch mitlesen …)
Gestern habe ich mich daran gemacht, die Web-Site meines Arbeitgebers zu überarbeiten.
Tables are so 2003!
Zuerst nahm ich mich dem Layout an. Dieses hatte ich zu Beginn des Jahres 2003 entwickelt – einer Zeit, als Tabellenlayouts noch State-Of-The-Art waren (jedenfalls in meinem Kopf) und ich CSS gerade erst zu entdecken begann, um damit … Texte zu formatieren.
Dass man mit den Cascading Stylesheets noch viel mehr anstellen konnte, verschloss sich mir damals noch.
Viel hat sich in der Zwischenzeit getan und heute möchte ich die Funktionalität von CSS2 nicht mehr missen. Die Templates für Web-Sites lassen sich rascher und mit viel weniger Overhead erstellen und auch nachträglich ohne Eingriff in den Code abändern. Zudem sind sie behindertengerechter.
Leider, leider, hat sich der 500-Pfund-Gorilla aus Redmond bei der CSS-Implementation in den sichersten Browser der Welt (just kidding) nicht viel Mühe gegeben, weshalb man immer überprüfen muss, ob auch der MSIE auch wirklich alles korrekt anzeigt, wie es seine standardkonformeren Kollegen Firefox, Safari und Opera anstandslos tun.
Erst dank CSS habe ich gelernt, ganz normale HTML-Tags wie h1 und p zu lieben. Zu nothing-Zeiten benutzte ich beispielsweise nicht etwa h1, um Überschriften festzulegen, sondern etwas in der Form
<span class="contentTitleFirstLevel">Title</span>
Es gibt Leute, die Spass daran haben, das Rad immer wieder neu zu erfinden. Auch ich gehörte dazu. Abgebucht unter: Jugendsünde. Denn er wusste nicht, was er tat …
XSS vorbeugen
Neben der Verschlankung des Designs (die Grösse des Templates konnte in etwa halbiert werden!) liess ich natürlich auch eine Web 2.0-Komponente in das Design einfliessen: Eine interaktive Personensuche.
Aus den Fehlern von Partyguide schlau, legte ich besonderes Augenmerk auf XSS-Sicherheitslücken. Für Aussenstehende: XSS bedeutet das „Einschleusen“ von Code auf eine Web-Site. Je nach Art der Web-Site lassen sich so mehr oder weniger grosse Dummheiten anstellen. Bei Partyguide hatte man bei der Attacke beispielsweise Zugriff auf die Cookies des Benutzers, in denen das (glücklicherweise nach meiner Intervention) verschlüsselte Passwort abgelegt war.
Damit bei meiner Personensuche nicht ungewollt Code eingeschleust werden kann, der sich für eine XSS-Attacke missbrauchen liess, baute ich eine (hoffentlich recht zuverlässige) Sicherung ein:
1 ...
2 if(!isset($_GET['string'])) {
3 $str_output .= '<p>Fehler: Formular nur teilweise übermittelt.</p>';
4 die($str_output);
5 }
6
7 $str_lookup_string = $_GET["string"];
8 $str_lookup_string = preg_replace("/[^a-zA-ZäöüÄÖÜ]/",NULL,$str_lookup_string);
9
10 if(strlen($str_lookup_string) < 3) {
11 $str_output .= '<p>Hinweis: Mind. 3 Zeichen eingeben.</p>';
12 die($str_output);
13 }
14 ...
15 $str_atom = $str_field . " LIKE '%" . mysql_escape_string($str_search_string) . "%'";
16 ...
Hier kurz einige erläuternde Erklärungen:
- Zeile 2: Wurde die GET-Variable gar nicht erst übermittelt, ist etwas faul – Abbruch (Zeile 4). Ich beharre zudem auch darauf, dass eine GET-Variable hereinkommt und nicht POST oder sonstwas (Verwendung des GET-Arrays, nicht des REQUEST-Arrays)
- Zeile 8: Da es sich um eine Personensuche handelt, haben Sonderzeichen nichts in der Anfrage verloren. Ich filtere diese mit PCRE aus. Und zwar so, dass ich festlege, was erlaubt ist und der Rest gelöscht wird – und nicht umgekehrt, dass ich festlege, was nicht erlaubt ist, und blöderweise doch noch etwas wichtiges vergesse, das durch den Check dann hindurchkommt. Wichtig ist hier insbesondere, dass die Markierer von HTML-Tags, > (grösser als) und < (kleiner als) weggefegt werden.
- Zeile 10: Was beim Web-Shop von Digitec nervt, erscheint hier sinnvoll: Niemand wird wohl mit nur einem bestimmten Buchstaben (z.B. ‚e‘) nach Personen suchen. Deshalb verbieten wir zu kurze Suchanfragen lieber auch gleich (bei Digitec wiederum wäre es manchmal sinnvoll, wenn ich auch nur nach zwei Zeichen suchen könnte, weil technische Geräte nun mal oft so benannt sind).
- Zeile 15: Obwohl der Such-String mittlerweile „clean“ sein sollte, gehe ich auf Nummer sicher, wenn ich ihn der Datenbank übergebe – und lasse mysql_escape_string drüberlaufen.
