Dipl.-Inform. Carsten Eilers

Automatisierte Tests können Logikfehler im allgemeinen nicht erkennen, da sie schlicht und ergreifend nicht in der Lage sind, den Kontext der Webanwendung zu berücksichtigen. Also bleiben nur manuelle Tests zur Suche nach Logikfehlern übrig. Da es unendlich viele Möglichkeiten für Logikfehler gibt, gibt es keine allgemein gültigen Regeln, um sie zu finden. Daher gibt es im Folgenden auch nur ein paar allgemeine Hinweise. Wie bereits im zweiten Teil erwähnt, treten Logikfehler oft da auf, wo es "Brüche" in der Anwendung bzw. ihrer Entwicklung gibt. Trotzdem lohnt es sich, generell alle für einen Angriff interessanten Funktionen auf mögliche Logikfehler zu untersuchen. Einige allgemeine Tests können dabei zumindest Hinweise auf Logikfehler liefern:

Testen Sie alle Benutzerkategorien

Wenn die zu testende Webanwendung verschiedene Benutzerkategorien verwendet, müssen Sie alle Funktionen für alle Benutzerkategorien testen und jedes Mal auch prüfen, ob Sie eine Funktion durch die Manipulation passender Parameter evtl. im Kontext einer falschen Benutzerkategorie ausführen können. Werden zum Beispiel je nach Benutzer unterschiedliche Parameter übertragen, testen Sie, was passiert, wenn Sie diese Parameter für die jeweils anderen Benutzer übertragen (siehe das Beispiel 2).

Allgemeine Tests

Führen Sie Schlüsselfunktionen wie das Login, das Ändern des Passworts oder den Abschluss eines Einkaufs mehrmals aus und entfernen Sie jedes Mal einen anderen der übertragenen Parameter (egal ob GET-, POST- oder Cookie-Parameter). Und zwar komplett, d.h. löschen Sie nicht nur den Wert des Parameters, sondern auch seinen Namen.

Führen Sie die Funktion bis zum Ende aus, das ist besonders bei mehrstufigen Aktionen wichtig. Manchmal wird ein im ersten Schritt eingegebener Parameter erst sehr viel später verwendet.

Prüfen Sie das Ergebnis: Ist irgend etwas daran verdächtig? Oft ist schon das Fehlen einer Fehlermeldung verdächtig - wenn ein fehlender Parameter keinen Fehler auslöst, wieso wurde er dann übertragen? Was passiert bei einer Manipulation des betroffenen Parameterwerts?

Funktionen mit mehreren Schritten

Wenn eine Funktion aus mehreren Schritten besteht, prüfen Sie, ob sie einen davon überspringen können, indem sie einfach den URL des nächsten Schritts aufrufen. Prüfen Sie auch, was passiert, wenn Sie die Schritte in einer falschen Reihenfolge aufrufen oder einen Schritt mehrmals ausführen.

Überlegen Sie, wie die Funktion vermutlich implementiert wurde und welche Annahmen die Entwickler aufgrund des aktuellen Kontext vermutlich getroffen haben. Können Sie diese Annahmen unterlaufen?

Testen Sie die verschiedenen Schritte auch mit Parametern, die eigentlich in vorherigen Schritten übergeben werden. Evtl. können Sie Parameter nachträglich manipulieren, indem Sie sie in einem späteren Schritt erneut übertragen und dabei die im einem vorhergehenden Schritt vorhandene Prüfung überspringen.

Selbst wenn Sie bei diesen Tests keinen Logikfehler entdecken, liefern Ihnen vielleicht die erzeugten Fehlermeldungen interessante Informationen über die Funktion der Anwendung, die sie für die weiteren Tests nutzen können

Grenzen überspringen

Ist die Webanwendung in verschiedene Bereiche eingeteilt, die jeweils nur bestimmten Benutzerkategorien zugänglich sind, prüfen Sie, was bei unerwarteten Wechseln der Bereiche passiert. Evtl. wird auf Seiten "hinter" der jeweiligen Startseite der Bereiche nur die Gültigkeit der Session überprüft, aber nicht die Zugriffsberechtigung des Benutzers (frei nach dem Motto "Wen die Startseite durch lässt, können wir vertrauen" und unter der Annahme, das niemand Unterseiten direkt aufruft).

Integerüberläufe

Arbeitet die Webanwendung mit Integerwerten, prüfen Sie, was beim Verarbeiten negativer und besonders großer Werte passiert. Evtl. lässt sich die Anwendungslogik durch Integerüberläufe manipulieren.

Escape schlägt Escape

Wenn Sie nach Command- oder SQL-Injection-Schwachstellen suchen, testen Sie nicht nur mit den entsprechenden Metazeichen, sondern auch mit escaped Metazeichen (siehe Beispiel 6).

Nutzen Sie Fehlermeldungen

Manchmal helfen Fehlermeldungen beim Finden von Logikfehlern. Erstellen Sie eine Liste aller Fehler, die eine Fehler- oder Debugmeldung mit benutzerspezifischen Informationen erzeugen. Testen Sie die entsprechenden Funktionen danach mit zwei Benutzern parallel und prüfen Sie für jeden Fehler, ob er Auswirkungen auf den anderen, eigentlich nicht betroffenen Benutzer hat.

Race-Conditions

Race-Conditions sucht man am besten im Quelltext. Im Rahmen eines Black-Box-Tests sind sie nur extrem schwer zu entdecken. Wenn Sie ihr Glück trotzdem versuchen wollen oder müssen, sollten Sie sich auf wichtige Schlüsselfunktionen wie zum Beispiel das Login, das Ändern des Passworts oder den Abschluss eines Einkaufs konzentrieren. Suchen sie für jede zu testende Funktion einzelne Requests, die jeweils eine einzelne Aktion auslösen. Gibt es keine, erschwert das die Suche, denn sie müssen nun mehrere Requests beim Test berücksichtigen. Zusätzlich müssen sie für jede Aktion die einfachste Möglichkeit ermitteln, um den Erfolg der Aktion zu prüfen.

Beim Test der Login-Funktion könnte die Aktion zum Beispiel das Abschicken der Zugangsdaten sein, als Prüfung kann der erfolgreiche Zugriff auf das Profil des verwendeten Benutzers dienen.

Haben sie die zu testenden Requests ermittelt, brauchen Sie mehrere Rechner in verschiedenen Netzen, von denen aus sie diese Requests an die Webanwendung schicken können. Jetzt muss die Aktion mehrmals nacheinander für verschiedene Benutzer ausgeführt und dabei das Ergebnis protokolliert werden - stimmt es immer mit dem erwarteten Ergebnis überein? Dieser Schritt lässt sich gut automatisieren, da nur Requests abgeschickt und die jeweiligen Ergebnisse mit dem erwarteten Ergebnis verglichen werden müssen.

Die sich ergebende Anfragenflut könnte zu Problemen in der Infrastruktur führen, immerhin machen Sie ja quasi einen Lasttest oder führen einen DDoS-Angriff durch. Nicht jedes unerwartete Ergebnis ist daher Folge eines Logikfehlers. Sehr oft werden sie auf False Positives stoßen, weil zum Beispiel eine Datenbankabfrage nicht schnell genug beantwortet wurde und die Anwendung daher eine Fehlermeldung aus gibt.

Soviel zur Suche nach Logikfehlern. Als Fazit bleibt festzustellen: Logikfehler finden ist schwierig, daher ist es besser, sie von Anfang an zu vermeiden. Wie, erfahren Sie in der nächsten Folge.

Carsten Eilers

Übersicht über alle Artikel zum Thema

Neue Angriffe auf Webanwendungen über Clickjacking und Cookies

Websecurity - XSS-Angriffe über XML

Websecurity - Angriffe über Logikfehler

Websecurity - Angriffe über Logikfehler, Teil 2

Websecurity - Logikfehler in der Authentifizierung

Websecurity - Logikfehler in der Authentifizierung und auf der Flucht

Websecurity - Logikfehler finden

Websecurity - Logikfehler vermeiden