Code from Hell
Marc Ruef | 06.10.2008

Irgendwie mag ich Monk, obschon ich bisher nur zwei Folgen partiell gesehen habe. Das Problem ist nicht, dass ich die Serie nicht gut finde. Viel mehr habe ich momentan schon genug zu tun mit den Serien, die ich bisher gucke. Eine meiner liebsten Szenen war, als Monk einen chinesische Verbrecher, dem er noch nichts nachweisen konnte, aufsuchte. Der Chinese machte gerade Klimmzüge und zählte während des etwas verworrenen Verhörs unablässig seine Erfolge: 97, 98, ... Als das Gespräch beendet schien und sich Monk verabschieden wollte, hörte der gute Mann bei 99 auf. Monk ab seiner Obsession sichtlich unruhig nötigte den gut gebauten Herrn, doch die 100 voll zu machen. Das Gespräch ging per Zufall weiter und da war er nun: Der 101ste Klimmzug! Monk kriegte fast einen Herzinfarkt.

Leute mit Zwangsstörungen sind diesbezüglich nicht zu beneiden. Ich kenne genug Leute, die in der Hinsicht tagtäglich zu kämpfen haben. Auch ich muss eingestehen, dass gewisse Dinge in mir eine unendliche Spannung generieren. Früher konnte ich es nicht leiden, wenn ich auf dem Gehweg die Kante einer Steinplatte berühren musste. Also wich ich ihnen aus. Das war eher ein Spiel und wenn ich denn mal in Eile war, war es mir doch eher egal. Zum Glück.

Bei einer der vielen Quelltext-Analysen, die ich in letzter Zeit durchgeführt habe, durfte ich mich mit ASP-Code herumschlagen. Ja, ich mag ASP auch nicht, aber in diesem Fall konnte ich schliesslich nicht auswählen. So machte ich mich dann daran, mir die Banking-Applikation etwas genauer anzuschauen. Ich gehe dabei immer in gleicher systematischer Weise vor: Zuerst einmal die Ausgabefunktion suchen, dann die Eingaben (User-Input) identifizieren und dann den Pfad dazwischen analysieren (z.B. String-Manipulationen, Datenbankzugriffe, etc.).

In meinem Leben habe ich schon die eine oder andere Anwendung geschrieben. Ich bin zwar kein professioneller Entwickler, doch meine ich Programmcode verstehen und optimieren zu können. Ebenso bin ich mir den jeweiligen Code-Konventionen, wie sie bei grösseren Projekten und Firmen eingesetzt werden (z.B. Apache Software Foundation (http://portals.apache.org/development/code-standards.html) oder dem Linux Kernel) sehr wohl bewusst. Das einheitliche Nutzen von Variablennamen, Auslagerung von Konstanten in bestimmte Bereiche und das Einhalten von Whitespace-Abständen erachte ich als sehr wichtig. Auch wenn der Endanwender nichts davon mitbekommt, haben solche Dinge massgeblichen Einfluss auf die Qualität der Lösung.

Die besagte Quelltext-Analyse sollte den Monk in mir wecken. Da wurde auf eine zentralisierte Ausgabefunktion verzichtet. Gerade bei Webanwendungen, die im Regelfall in höchstem Masse Interaktion mit nicht-vertrauenswürdigen Benutzern aufweisen, ist das eine Todsünde. Denn so müsste man nun die Eingabeüberprüfung an den jeweiligen Eingabepunkten durchführen. Hat die Anwendung mehrere hundert Textfelder, dürfte der Code in sinnloser Weise anwachsen. Ist der Entwickler halbwegs intelligent, schreibt er sich wenigstens eine einheitliche Funktion, die er öffentlich zugänglich macht. Ist der Entwickler hingegen weniger intelligent, wird er mit Replace-Zugriffen die einzelnen Parameter separat abarbeiten. Letzteres war hier der Fall (der Aufwand der Prüfung steigt dabei für mich exponentiell an!).

Als ich die Codebasis so durchforstete wollte ich fortwährend die Variablennamen anpassen, die kaputten while-Schleifen optimieren und unnötige bool'sche Verknüpfungen in if-Entscheidungen aufheben. Es zuckte in meinen Fingern, den Code so zu optimieren, dass er sowohl lesbar als auch halbwegs effizient ausführbar wurde. Doch leider werde ich nicht dafür bezahlt. So musste ich halt damit Vorlieb nehmen, eine architektonisch und entwicklungstechnisch wirklich schlimme Anwendung durchwühlen zu müssen.

In solchen Fällen habe ich es mir zur Gewohnheit gemacht, im Abschlussbericht auch auf derlei Mängel hinzuweisen. Auf den ersten Blick scheint es kein "Security Issue" zu sein, wenn man zum Beispiel komplexere if-Strukturen anstelle von case-Blöcken verwendet. Doch längerfristig wird unter Umständen die Wartung des Codes in derartiger Weise erschwert, dass das ungewollte Einführen von Schwachstellen (http://www.computec.ch/projekte/tractatus/?s=tractatus&m=liste&h=3.3.2.1.4.6&l=6) statistisch nicht mehr von der Hand zu weisen ist. Manche Entwickler fühlen sich sonst schon angegriffen, wenn man sie zu einer Source Code Analyse drängt. Und hat man dann auch noch den allgemeinen Programmierstil zu bemängeln, dann schafft man sich damit keine Freunde. Doch leider ist es nicht meine Aufgabe, mir Freunde zu schaffen. Meine manchmal etwas undankbare Arbeit ist es, Schwachstellen aufzudecken und diese zusammen mit dem Kunden anzugehen, um die Sicherheit einer Lösung bestmöglich verbessern zu können.