BenBE's humble thoughts Thoughts the world doesn't need yet …

Jeder ist sie gewohnt: Die mehr oder weniger regelmäßigen Abstürze von Programmen, die halt mal hin und wieder passieren. Und auch in Großprojekten findet man immer wieder einmal recht interessante Missgeschicke, die verheerende Auswirkungen nach sich ziehen. So z.B. wenn beim Auffüllen zu kurzer Kontonummern in der Arbeitsagentur die Nullen auf der rechten Seite der Kontonummer eingefügt werden, oder bei der NASA die Messbereiche für die Beschleunigungssensoren überschätzt werden und daher die in großen Teilen von den Ariane-4 übernommene Firmware der Steuercomputer wegen einem Hardware-Überlauf entscheidet, die Rakete zu sprengen. Derlei Geschichten mögen vielleicht auf den ersten Blick witzig erscheinen, sind aber im Endeffekt dennoch zu einem gewissen Teil durch fachfremdes Personal, zu kurze Entwicklungszyklen oder überhastete Entscheidungen erklärbar.

Ich möchte hiermit bei weitem nicht sagen, dass jeder Nicht-Informatiker automatisch schlechten Code erzeugt, dennoch sollte jeder der Software implementiert – und sei es für sich privat oder die „Weitergabe im Kleinen Kreis“ -, fragen, welche Priorität die Fehlerfreiheit seiner Software einnimmt. Wahrscheinlich einen viel zu geringen. Zumindest, wenn ich mich in meinem Umfeld umschaue, in dem zahlreiche Programmierer – sowohl studierte wie auch fachfremde – ihr Unwesen treiben: Ein Programm soll tun, was ich von ihm will, ist da nur allzu häufig eine der ersten Antworten, die man da zu hören bekommt.

Und ehrlich gesagt: Ich könnte mich jedes Mal über derlei Verhalten aufregen, da es im Grunde genommen einfach nur Fahrlässig ist. Klar komm ich mit einem Auto von A nach B wenn ein Motor drinnen ist, ich ein Lenkrad hab und ggf. auch noch ein Tank vorhanden ist. Wenn ich aber vergesse, eine Bremse einzubauen, oder ein Bremspedal vorzusehen, fehlt vielleicht nichts Wichtiges, aber ich gefährde unnötig andere – und auch mich selbst -, wenn ich mit einem solchen Gefährt die Straßen benutzen würde.

Aber genau das ist es, was man in der Informatik immer wieder antrifft. Quereinsteiger, die auf Grund von 3 in Flash oder VB gehackten Zeilen Kot meinen, den Computer im Griff zu haben (Ähnlichkeiten zu real existenten Fällen sind rein zufällig). Nicht, dass diese Leute nicht programmieren können, aber oftmals kommt zu dieser Überschätzung auch noch Naivität hinzu. Die Naivität, dass man es mit seinem eigenen Wissen hinbekommt, was rein oberflächlich betrachtet auch stimmt, unter der Haube aber halt zu Autos ohne Bremsen führt.

Und genau hier liegt ein kritischer Punkt, der in der Informatik zu gewaltigen Problemen führt und den viele im Gegensatz zu anderen nicht mal als kritisch erkennen. Obwohl jedoch niemand an anderer Stelle auf die Idee käme, beim Architekten ins Büro zu gehen und sich sein Haus selber zusmmenzuklicken. Genau dies ist es aber, was tagtäglich zu Hauf in der Informatik geschieht: Laien aus anderen Fachbereichen, die sich in an Sie „angepassten“ Entwicklungsumgebungen als Programmierer fühlen und dabei oftmals nicht mal die Grundlagen der Programmierung kennen, sondern annehmen, durch Zusammenklicken von Schaltungen oder Abläufen einen Informatiker ersetzen zu können.

Aber nehmen wir mal ein konkretes Beispiel (und ich hoffe, die betroffene Person nimmt mir dies hier nicht allzu übel ;-)): Bernd ist Medientechniker. Bernd schreibt gern Bücher, gestaltet Filme, arbeitet Multimedial an zahlreichen Projekten, dabei u.a. auch mit Flash und hat zudem auch bereits in andere Programmiersprachen reingeschnuppert. Soweit sicherlich nichts ungewöhnliches. Bernd entscheidet sich nun, für seine Arbeit ein Programm Foo zu schreiben, was ihm bei seiner Arbeit mit Drehbüchern helfen soll. Sobald dieses Programm soweit fertig ist, soll es zudem „im kleinen Kreise“ weitergegeben werden. Auch hieran ist an sich nichts auszusetzen. Was jedoch ein erster Grund zur Besorgnis ist, ist die Tatsache, dass sich Bernd trotz berechtigter Hinweise zur Sicherheit dieses Programms für die Programmiersprache VB entscheidet, und zwar nicht aus sachlichen Gründen, sondern weil ihm die, für dieses Projekt durchaus günstigeren Alternativen C# und Java nicht zu seinem Kenntnisstand gehören.

Lässt man jedoch auch diesen Punkt außer Acht und nimmt für einen Moment den Einspruch von Bernd als Gerechtfertigt an, dass die vorgebrachten Sicherheitsrisiken – darauf komm ich gleich noch zu sprechen – unbegründet wären, bliebe noch ein zweiter Punkt: Der Verzicht, fertige Bibliotheken zum Verarbeiten externer Datenformate wie XML heranzuziehen. Wie jetzt? Ist XML nicht einfach? Das kann doch jeder implementieren? Eben nicht!

Wer sich einmal gängige XML-Parser-Bibliotheken wie SAX bei Java angeschaut hat, dürfte festgestellt haben, dass deren Aufgabe bei weitem nicht trivial ist; insbesondere dann nicht (oder sollte man besonders dann nicht sagen), wenn man es mit potentiell untrustworthy Content aus Datendateien des Benutzers zu tun hat. Nicht, dass ich Bernd nicht zutraue, einen funktionierenden Parser für XML zu schreiben; ich traue Bernd nicht zu, dass zu können, woran auch zahlreiche Experten scheitern: Dies fehlerfrei bei einem derart komplexen System zu beherrschen.

Und nun mag der eine oder andere vielleicht denken „wer nutzt den vollständigen XML-Standard?“: Keiner. Wer aber XML als Datenformat verwendet, muss damit rechnen, dass er eben alle möglichen Funktionen sieht, die dieser Standard beschreibt. Programmierung nach dem Credo „das wird nicht vorkommen“ ist so, als ob man auf den Bahngleisen zum nächsten Bahnhof läuft, weil die Bahn schon nicht kommen wird. Es ist kurzsichtig und allein auf das „Fertigwerden“ des Projektes gerichtet, lässt aber vollkommen außen vor, dass eine Software auch eine Qualität besitzen muss, also nicht auf den Testcases des Programmierers funktionieren muss, sondern unter Realbedingungen bestehen muss.

Führt man diesen Punkt auf, beklagt sich Bernd, dass es ihm doch nichts bringe, sein eigenes Programm zu hacken. Auch hier ist eine erschreckende Kurzsichtigkeit zu verspüren. Im GeSHi patche ich Sicherheitslücken wenn ich sie finde, nicht erst, wenn sie mir von extern auch noch mal gemeldet werden, sondern sobald ich sie selber sehe. Und dabei warte ich auch nicht auf den Zufall, sondern schaue bei Code-Reviews immer wieder über meinen Source. Im Grunde hacke ich also mein eigenes System, streng genommen sorge ich aber nur dafür, die Rahmenbedingungen für sicheres Arbeiten mit dem Programm zu verbessern. Nutzen habe ich direkt von dieser freiwilligen Suche nach Fehlern eher nicht, da dies überwiegend harte Arbeit bedeutet, was auch durch das zu verlierende Ansehen nur ungenügend gedeckt wird.

Der Grund ist vielmehr völlig trivial: Fehler, die ich nicht finde, werden früher oder später durch andere gefunden. Dabei ist es i.A. egal, wer sie findet, denn wahrscheinlich werden diese Fehler gegen die Software eingesetzt werden. Oder kurz: Mit jedem Sicherheitsfehler in meinem Programm kann ich nur an Vertrauen meiner Anwender verlieren, egal wie ich es drehe. Von daher sollte ich versuchen, es von Anfang an richtig zu machen.

Und etwas richtig machen, heißt nunmal auch, etwas vollständig umzusetzen, selbst wenn für die eigene Anwendung 99% eines Standards nie benötigt werden. Nehmen wir dazu einmal den RFC822 als Beispiel (Internet Message Format, u.a. bei Mail und HTTP verwendet). Dieses RFC definiert ein einfaches Name-Wert-Schema um Meta-Daten an eine Nachricht anzuhängen. Bei einer Email z.B. Absender, Empfänger, Datum und Betreff. Wer jetzt losgeht, und hier denkt, er kenne mit der Definition „Wort gefolgt von Doppelpunkt gefolgt von Wert, der am Zeilenende endet“ genug, um einen Parser zu schreiben, wird bereits an den meisten HTTP-Anfragen moderner Browser kläglich scheitern. Diese sind zwar auch RFC822 (wenn auch in überarbeiteten Formen), nutzen aber nicht nur die einfache Form, sondern eine ganze Menge mehr an gültigen Konstrukten, wie der Line-Continuation oder Parameter-Encodings nach diversen anderen RFCs. Ein schönes Beispiel für einen gültigen Request lieferte hierbei Fefe auf dem 26C3, als er einen gültigen RFC822-Header mit mehrzeiligem ASCII-Art zeigte, an dem zahlreiche „Homebrew“-Parser sicherlich gescheitert wären. Wie reell dieses Problem für den konkreten Fall ist, steht jedoch noch einmal auf einem anderen Blatt.

Wichtig ist hierbei jedoch, dass keine Anwendung fehlerfrei ist und es daher die verdammte Pflicht eines Programmierers ist, sich um Sicherheitslücken und Bugs in von ihm ausgelieferter Software zu kümmern. Womit wir wieder am obigen Punkt bzgl. VB wären: Für VB muss man eine Runtime ausliefern. Diese dürfte auf aktuellen Systemen zwar vorhanden sein, ist sie dies aber nicht, muss diese mit übertragen werden. Und hier gibt es nicht weniger Programmierer (und das betrifft nicht nur VB), die solche externen Bibliotheken zwar mitliefern, diese aber nicht weiter Pflegen und daher beim Anwender versauern lassen. Wird also in einer solchen Runtime-Bibliothek ein Fehler entdeckt, so bleibt dieser in der Regel für viele Anwendungen ungefixt, selbst wenn der Original-Maintainer bereits einen Bugfix herausgegeben hat. Dieses Problem reduziert sich zwar mit dem Einsatz von Paket-Verwaltungssoftware wie DPKG/APT, Emerge und Konsorten unter Linux erheblich, da es viele Programmierer ermutigt, die externen Pakete zu referenzieren, statt die nötigen Libraries selbst mitzuliefern, funktioniert aber nur korrekt, wenn sich alle Beteiligten daran halten und auch jede Software vernünftig über dieses System verwaltet werden kann. Wenn aber jeder Autor die immer gleiche Funktionalität dennoch immer wieder implementiert, hilft auch solch eine Paketverwaltung nur bedingt.

Womit wir den Punkt Code-Dopplung hätten, der als eines der schlimmsten Laster in der Informatik angesehen werden kann. Und damit meine ich nicht die tausenden Rezepte-Datenbanken oder anderen Einsteiger-Aufgaben, die jeder einmal implementiert haben dürfte, sondern den oft zu beobachtenden Drang vieler, bestehende Bibliotheken noch einmal selbst schreiben zu müssen, statt sich bei diesen Bibliotheken mit den Autoren in Verbindung zu setzen, um den vorhandenen Source zu verbessern. Dies ist nicht nur kontraproduktiv, sondern verschwendet auch unnötig Arbeitszeit, die man besser in die Implementierung neuer Algorithmen investieren sollte.

Informatik ist eine Wissenschaft und als solche sollten keine Laien als Prädiger an der Spitze sitzen, oder Leute, die dem aktuellen Stand um Jahre hinterher hinken. Vielmehr sollte man die Informatik als das begreifen, was sie ist: Eine Wissenschaft, die Algorithmen für die effiziente Umsetzung von Algorithmen entwickelt. Und damit ist es nunmal tödlich, wenn man sich ständig mit den bereits gefestigten Grundlagen beschäftigt, statt aktuelle Erkenntnisse umzusetzen und Neues zu entdecken.

Und zu diesen Erkenntnissen gehört nunmal auch, dass man sich anschaut, wie man Fehler in seinen Programmen vermeidet. Denn was wir heute als Fehler in unseren Programmen sehen, ist nichts anderes als das Ergebnis der Unfähigkeit derjenigen, sich an den Stand der Technik in Bezug auf die Fehlervermeidung anzupassen. Was früher Pufferüberläufe waren, sind heute SQL-Injection, XSS und CSRF: Ein Symptom dessen, dass man Leute an Dinge heran lässt, von denen Sie nichts verstehen – und die dann zusätzlih oftmals lernresistent sind, weil sie meinen, dies sei normal und müsse so sein.

Wenn man immer nur einen Hammer zur Verfügung hat, sieht irgendwann alles aus, wie ein Nagel, den es gilt, in die nächstbeste Wand zu schlagen. Das Aussehen ist dabei erstmal egal; kracht dieses Provisorium aber einmal zusammen, ist das Geschrei groß.