Dirk's Weblog

Fehler in Programmen sind oftmals unerwartete Reaktionen im Programmfluss. Es können zwei Arten von Fehlern auftreten. Fehler die man verarbeiten (handled) und welche die man nicht verarbeiten kann (unhandled). Solche Schwierigkeiten nennt man im Fachjargon auch Ausnahmen (engl. Exceptions). Das Exceptions-Modell ist in vielen gängigen Programmiersprachen wie etwa C++, PHP (seit Version 5) oder Delphi vorzufinden.

Wie funktionieren Exceptions?
Stellen Sie sich die Hierachie eines Großunternehmens vor. Von unten nach oben gibt es normale Mitarbeiter, Abteilungsleiter, Filialleiter und dann den Vorstand. Angenommen ein Mitarbeiter bekommt durch einen Zufall per Post die Quartalszahlen für das Unternehmen. Der Mitarbeiter kann damit nicht wirklich was anfangen und gibt es weiter an den Abteilungsleiter. Der widerum gibt es an seinen Vorgesetzten. Solange bis die Nachricht den Vorstand erreicht. Dieser setzt sodann entsprechende Hebel in Bewegung. So ähnlich läuft das auch mit Exceptions, nur dass die Hierarchie des Unternehmens die Aufrufliste (engl. Callstack) des Programms darstellt. Ganz oben steht der Prozess bzw. der Einstiegspunkt des Programms und ganz unten die Funktion oder Methode welche die Exception ausgelöst hat.
Wie bei dem Beispiel mit dem Unternehmen wird auch hier die Exception an die aufrufende Methode in der Hierarchie weitergereicht. Kann diese Methode die Exception nicht verarbeiten, wird diese an dessen aufrufende Methode gereicht. Das geht solange, bis der Einstiegspunkt erreicht ist. Ist bis dahin die Exception nicht verarbeitet, wird dem Betriebssystem eine unbehandelte Ausnahme gemeldet was eine Prozessterminierung zur Folge hat.

Was sind Asserts?
Asserts sind Programmabschnitte in denen bestimmte Vorraussetzungen geschaffen sein müssen, damit der weitere Programmfluss die gewünschten Ergebnisse liefert. Schlägt eine Assertion fehl, wird der “Entwickler” darüber informiert. Warum der Entwickler? Asserts sind ein Debugging Konzept und nicht für den Release Modus bestimmt. Eine Assertion ist viel mehr ein Hinweis als ein Fehler.

Was ist mit Secret gemeint?
Mit Secret (zu Deutsch: Geheimnis) meine ich das verschweigen von Fehlern. Wenn eine Methode/Funktion nicht funktioniert, kann sie zum Beispiel den Wert false zurückliefern um anzuzeigen, dass etwas schief gelaufen ist. Es könnten aber auch Fehlercodes in Form von Ganzzahlen zurückgegeben werden. Nehmen wir als Beispiel die “CreateWindowEx”-Funktion der WindowsAPI. Im Fehlerfall gibt diese NULL zurück, und der Fehler kann über die Funktion GetLastError() abgerufen werden. Die Fehlerbehanldung wird somit komplett an den Aufrufenden übergeben. Werden die Rückgabewerte nicht verarbeitet, so passiert nichts und das Programm fährt fort. Der Fehler wird somit verschwiegen und es treten merkwürdige Ergebnisse auf (z. B. wie in diesem Fall: Ein Fenster wird nicht angezeigt).
Beispiele für Secrets: Frühere PHP Versionen, C/C++ und Windows API

Anwendungsbereiche
Als Faustregel sollte man Exceptions nur verwenden wenn man Methoden ausserhalb des Programms z. B. einer externen Bibliothek aufruft.
Es geht hierbei nicht um “fremden” Quellcode. Es ist viel mehr eine Art Verantwortungsbereich. In einem Industrieunternehmen teilt der Abteilungsleiter dem anderen auch nicht mit, dass sich Herr Christian W. aus Abschnitt B, Halle 1 gestern Vormittag den Fuß verstaucht hat weil ihm eine Kiste auf den Fuß gefallen ist (ausser vielleicht am Mittagstisch). Regulär ist es aber für die Produktion unerheblich. Interessant wird dagegen wenn der genannte Herr nicht mehr arbeiten kann und die Produktion dadurch zum erliegen kommt. Und genau hier fliegt die Exception. Ein Modul hat die Verantwortung richtig zu funktioneren. Kann es das nicht, sollte dies über eine Exception dem Aufrufer mitgeteilt werden. Alle internen “Problemchen” des Moduls, welche die Funktionalität nicht beeinträchtigen interessieren den Aufrufer nicht. Folglich sollten diese “Problemchen” über Asserts behandelt werden.

Secrets, (k)eine Alternative
Eine “Alternative” zu dem oben genannten Anwendungsbereich sind die Secrets. Ich empfehle diese aber nur zu verwenden, sofern die angewendete Programmiersprache kein Exception-Modell unterstützt. Eine aufgerufene Methode aus einer fremden Bibliothek könnte beispielsweise einen Boolean zurückliefern; true wenn alles gut lief; false wenn ein Fehler auftrat. Bis auf den Performancegewinn ergeben sich mit diesem Verfahren nur Nachteile:

• Jede aufrufende Methode im Callstack muss jeden Rückgabewert der von ihr aufgerufenen Methode verarbeiten können bzw. an die obere Methode weiterleiten. Bei Exceptions funktioniert das automatisch, in dem die Ausnahme an die obere Methode weitergereicht wird.
• Fängt eine Methode den Rückgabewert nicht ab bzw. verarbeitet diesen, wird der Fehler verschluckt. Das fehlerhafte Verhalten wirkt sich aber dennoch auf die Anwendung aus. Durch diese Problematik können die merkwürdigsten Verhaltensweisen des Programms auftreten ohne das eine genaue Struktur des Fehlers ensteht. Das erschwert die Problemsuche erheblich.
• Exception Handling wird von den meisten Entwicklungsumgebungen unterstützt und vereinfacht das Debugging erheblich.

Fazit
Prinzipiell ist es wichtig, wie mit allen Werkzeugen zweckmässig und Verantwortungsvoll umzugehen. Exceptions sind mächtig doch auch mit Vorsicht zu genießen. Ein gesunder Mix aus Assertions, welche im eigenen Scope verwendet werden, und Exceptions welche Scopeübergreifend arbeiten sollte wohl das Beste aus den Befehlen rausholen. Secrets sollte man aufgrund der fehlenden Code-Transparenz komplett meiden.

Wenn ich im Internet surfe sehe ich oft Seiten, die große Sicherheitslücken in der Kommunikation zwischen Server und Client aufweisen.

Der normale Kommunikationsweg zwischen Webserver und Client erfolgt über HTTP-Variablen. Das heißt, der Wert einer Variable über den die Folgeseite verfügen soll, wird über die URL (GET) oder im Header (POST) mitgeschickt. Hier ein Beispiel für den Aufruf einer Webseite mit einer GET-Variable: news.php?id=4. Die Variable “id” hat den Wert 4. Ich habe den Namen id nicht ohne Grund gewählt. Datenkbanken identifizieren Datensätze häufig über eine numerisch generierte Zahl, welche fortlaufend und damit eindeutig ist.
Nehmen wir an, die Seite news.php verfügt nicht über eine ausreichende Sicherung der GET-Variablen und man würde den Wert der ID von Hand auf 2 oder 3 ändern, würde die Webseite die Inhalte der Artikel mit der ID 2 oder 3 darstellen. Denken Sie jetzt mal an ein Forum oder eine Community, bei der dieser kleine Trick dazu führen kann, das Dritte an Informationen von Benutzern kommen welche ihnen sonst unzugänglich geblieben wären.

Modifizierbare GET- und POST-Variablen einer HTTP-Anfrage können ebenfalls für eine SQL Injection genutzt werden. Hacker ändern in diesem Fall den Wert nicht direkt, sondern gehen in dem Fall davon aus, dass dieser ein Teil eines SQL Befehls darstellt. Die URL würde wie folgt aussehen: “site.php?id=3; DROP DATABASE mydatabase”. Boom! Und die Daten sind weg.

Hier einige Tipps, wie man derartigen Problemen aus dem Weg geht:

1. Neuere Datenbanksysteme unterstützten sogenannte GUIDs (global unique identifiers). Es sind 128 Bit Schlüssel und wesentlich seltener als die numerischen IDs. “Seltener” heißt, wenn 2 oder mehr Systeme eine ID zur selben Zeit erzeugen, liegt nur sehr eine geringe Chance vor, dass unter den erzeugten IDs eine Doppelte existiert. Der Vorteil hierbei liegt darin, das eine generierte ID nicht inkrementell fortlaufend ist, sondern sich aus anderen Faktoren zusammensetzt (MAC-Adressen, Datum etc.). Der Nachteil ist, dass der GUID wesentlich mehr Speicherplatz in Anspruch nimmt.
2. Der Datenbank Benutzer welcher, von der Webseite verwendet wird, sollte nur über eingeschränkte Berechtigungen verfügen. Werden von der Webseite z. B. nur Informationen und Inhalte ausgegeben, so benötigt der Datenbankbenutzer nur Leseberechtigungen.
3. Validieren sie HTTP Variablen, bevor sie diese benutzen. Das prüfen von Strings oder ints bläht die Codegröße auf, daher ist eine Prüfsumme besser geeignet. Ein großteil der Serverseitigen Programmiersprachen unterstüzt Prüfsummenfunktionen wie z. B. MD5. Dies funktioniert wie folgt: Als erstes wird ein Schlüsselwort erstellt z. B. “MM3banana13″. Nun verknüpft man alle Variablen welche über diese Sicherung verfügen sollen zu einem String und fügt das Schlüsselwort am Anfang oder am Ende an. Die Reihenfolge ist wichtig, da die Zielseite den String auf die selbe Weise zusammensetzen wird. Mit diesem String wird ein MD5 Hash erzeugt der ebenfalls als HTTP-Variable übergeben wird. Die Empfängerseite setzt, wie schon eben beschrieben, den String auf dieselbe Weise zusammen und erzeugt einen MD5 Hash. Sie überprüft den erzeugten Hash und den empfangenen Hash. Wenn die Daten geändert wird unterscheiden sich die Prüfsummen. Man kann dieses Verfahren noch sicherer machen in dem man das Schlüsselwort in bestimmten Zeitabschnitten automatisiert ändert.
4. Benutzen sie SSL-Verbindungen für sensible Daten. Dies macht die Kommunikation zwischen Server und Client wesentlich sicherer und für Dritte unzugänglich.

Sicherheit ist kein Hexenwerk. Mit ein paar Handgriffen kann man seine Webseite sicherer machen. Der Grundgedanke für Softwaresicherheit sollte lauten:

Man sollte immer Daten erwarten, welche man nicht erwartet.