Eingabeüberpüfung? Wozu?!
Marc Ruef | 19.03.2007

Ich liebe Web Application Penetration Tests. Wieso? Ganz einfach: Sie sind ganz einfach. Eine Webapplikation als solche stellt in erster Linie eine über einen Webbrowser nutzbare Anwendung zur Verfügung. Die Schnittstelle wird dabei durch den Webserver, auf dem die Anwendung läuft, bereitgestellt. Durch die jeweiligen Formulare, wie sie in HTML typisch sind, wird die Interaktion mit der Applikation bewerkstelligt. Ob dies nun die Verwaltung eines Bankkontos oder das Berechnen von Versicherungsprämien ist: Das Prinzip ist stets das Gleiche.

Bei einer black box-orientierten Sicherheitsüberprüfung einer Webapplikation werden keine zusätzlichen Informationen zur Zielumgebung bereitgestellt. Konfigurationsdetails oder der Quelltext der Anwendung stehen einem nicht zur Verfügung, so dass man sich Schritt für Schritt an das Zielobjekt herantasten muss. Wie in den meisten Fällen bedeutet dies: Einfach mal ausprobieren.

Die Idee besteht darin, dass man der Webapplikation eine Eingabe aufzwingen kann, die sie nicht richtig verarbeiten kann. Ein kleinerer Fehler ist zum Beispiel, wenn man bei einer Zinsberechnung anstelle eines ganzzahligen Werts wie 10 einen Buchstaben wie A übergeben darf. Es ist zu erwarten, dass die Zielapplikation mit dieser Eingabe nicht allzuviel anfangen kann, von einer Berechnung absieht und stattdessen eine Fehlermeldung ausgibt. Soweit nichts problematisches.

Wirklich kritisch wird es aber dann, wenn mit einem solch absichtlich umgesetzten Fehlverhalten die Zielanwendung zu kompromittierenden Handlungen bewegt werden kann. Anstelle der Ausgabe einer Fehlermeldung könnte die Folge der zuvor genannten Eingabe sein, dass die Anwendung einfach abstürzt. Vielleicht hat sie effektiv intern versucht 10 % des Werts A auszurechnen, was schlichtweg nicht möglich war. Das Resultat war undefiniert und führte spätestens bei der Darstellung zu einem Programmabsturz. Damit wäre eine schöne, zwar nicht aus der Sicht des Kunden, Denial of Service-Schwachstelle identifiziert.

Die klassischen konstruktiven Angriffstechniken im Webumfeld sind Pufferüberlauf-Attacken, Directory Traversal, Cross Site Scripting und SQL-Injection. Jede dieser Attacken erfordert das Anstreben einer speziellen Eingabe. Im Falle eines Pufferüberlaufs ist die Übergabe einer überlangen Zeichenkette erforderlich und die Zeichenkette ../ bildet die Grundlage für klassische Directory Traversal-Attacken. Genauso erwartet Cross Site Scripting irgendwo das Unterbringen von HTML-Code und eine SQL-Injection das Einschleusen von SQL-Anweisungen.

Grundsätzlich ist es für einen Entwickler einer Webapplikation sehr einfach, diese typischen Attacken abzuwehren. Erwartet das Programm eine Eingabe, die maximal 5 Zeichen lang ist (z.B. Kontonummer), so sollten Eingaben länger als 5 Zeichen entweder abgeschnitten oder verworfen werden. Eine Pufferüberlauf-Attacke ist damit in den allermeisten Fällen verhindert. Genauso haben die Zeichenkette ../, die Sonderzeichen < (Kleiner-Als Zeichen) sowie ' (Hochkomma) in den meisten Eingaben nichts verloren. Damit sind schon mal 90 % der typischen Fehler frühzeitig abgefangen.

Doch irgendwie wollen sich nicht alle Entwickler von Webapplikationen das Leben so einfach machen. Stattdessen verzichtet man einfach auf eine solche Überprüfung und gibt seine Anwendung damit einer Heerschaar von Angreifern preis. So habe ich es jedenfalls letztens bei einem Penetration Test eines grossen Industriekonzerns gesehen. Es dauerte keine 30 Sekunden, bis ich die oben genannten Schwachstellen gefunden habe. Nach 2 Minuten musste ich abbrechen und dem Kunden eine Emergency-Meldung zukommen lassen. Die Konsequenzen für den Hersteller der Webapplikation, eine hierzulande sehr bekannte Firma, werden leider nicht die besten sein...