Ob Online-Einkauf, Online-Banking oder nur eine einfache Suche im Internet, interaktive Webseiten mit Formularen und Eingabefeldern sind ein zentrales Element des Internets. Die Bedienung durch plattformunabhängige Browser macht Web-Anwendungen für alle Geschäftsfelder interessant. Doch in erstaunlich vielen Webanwendungen finden sich gravierende Sicherheitslücken. Diese wiegen umso schwerer, da darüber interne Firmendaten von jedem Ort der Welt aus auszuspähen sind.
Schuld ist oft ein straffer Zeitplan, der wenig Zeit für die Fehlersuche in einem neuen Release einer Applikation lässt. Aber auch gut informierten und erfahrenen Programmierern ohne Zeitdruck können Fehler unterlaufen, die eventuell ernste Folgen nach sich ziehen - im schlimmsten Fall lassen sich Befehle auf den zugrundeliegenden Systemen ausführen oder vertrauliche Daten aus der Datenbank auslesen.
Grundsätzlich gilt: Je früher solche Sicherheitslücken in der Entwicklungsphase erkannt werden, desto leichter sind sie zu beheben. Um diese Schwachstellen rechtzeitig auszumerzen, empfehlen sich zwei Herangehensweisen. Zum einen handelt es sich dabei um die statische (Quellcode-)Analyse, die auf Basis des produzierten Codes versucht, den Datenfluss zu erkennen und Fehler in Logik und Datenverarbeitung aufzudecken. Zum anderen gibt es die dynamische Überprüfung an einer lauffähigen Applikation, mit der sich dieser Beitrag schwerpunktmäßig befasst.
Die dynamische Überprüfung, das klassische "Web-Audit", umfasst aufwändige manuelle Aufgaben, lässt sich aber auch ein Stück weit automatisieren: Unterstützung leisten hier Web-Applikations-Scanner, mit deren Hilfe viele Schwachstellen in einer Anwendung effizient aufgespürt werden können. Anders als klassische Netzscanner wie beispielsweise "Nessus" oder "Retina", die auf Betriebssystem- und Dienstebene nach Schwachstellen suchen, setzen diese Spezial-Tools auf einer höheren Ebene an und interagieren - ähnlich wie ein Browser - nur über den HTTP(S)-Kanal mit der Anwendung.
Wie Scanner arbeiten
In der Regel arbeitet ein Web-Applikations-Scanner in zwei aufeinander aufbauenden Schritten: Zunächst werden die Struktur und sämtliche Seiten innerhalb einer Anwendung erfasst. Für das so genannte Crawlen muss der Scanner in der Lage sein, Links zu weiteren Seiten zu folgen, auch wenn sie dynamisch, beispielsweise in Form eines Javascript-Menüs, erzeugt werden. Außerdem hat das Tool zu erkennen, wann es in einen Zyklus läuft, sprich: die gleiche Seite wieder und wieder besucht. Für schwierige Fälle bieten die meisten Produkte einen manuellen Crawl-Modus an: Der Auditor kann mit einem Browser selbst durch die Applikation klicken und so definieren, welche Seiten und Bereiche vom Scanner überprüft werden sollen.
Im zweiten Schritt des Scan-Vorgangs erfolgt die eigentliche Schwachstellensuche. Jede Seite, die der Scanner während des Crawl-Vorgangs erfasst hat, wird einzeln und wiederholt untersucht. Dazu werden alle Formularfelder und Parameter innerhalb dieser Seite mit bestimmten Angriffsmustern vorbelegt und anschließend an die Web-Applikation geschickt, um deren Reaktion auf die Angriffsmuster auszuwerten. An der Antwort lässt sich beispielsweise anhand des HTTP-Statuscodes (etwa: "200 OK" oder "500 Internal Server Error") oder durch Fehlermeldungen im HTML-Body erkennen, ob die Applikation auf den Angriff "hereingefallen" ist.
Mit guten Produkten können nicht nur Web-Applikationen, sondern auch Web-Services auf Schwachstellen überprüft werden. Das Vorgehen ist ähnlich, allerdings entfällt der erste Schritt des Crawlings, da sich die zur Verfügung stehenden Funktionen aus der Web-Service-Definition, der WSDL-Datei, entnehmen lassen. Die Schwachstellen hingegen können bei Web-Services die gleichen Auswirkungen haben wie bei Web-Applikationen.
Manuelle Aufgaben
Neben einem automatisierten Scan überprüfen spezialisierte Dienstleister die komplette Web-Applikation manuell. Notwendig ist diese aufwändige Inspektion, weil es Schwachstellen gibt, die von einem Scanner nicht gefunden oder auch nicht korrekt interpretiert werden. In der Regel werden sämtliche Parameter auf jeder Seite einzeln betrachtet und, ähnlich wie beim Scanner, verschiedene Angriffsmuster ausprobiert. Dieser Schritt erfordert das größte Know-how im gesamten Web-Audit.
Grundsätzlich brauchte es Erfahrung und Hintergrundwissen, um ein Audit sinnvoll und mit bestmöglichem Ergebnis betreiben zu können. Hilfe versprechen hierzulande viele Firmen, die eine Prüfung von Web-Applikationen anbieten. Methoden, Werkzeuge und Erfahrung sollten im Einzelfall jedoch hinterfragt werden, denn nur wenige Sicherheitsunternehmen sind tatsächlich darauf spezialisiert und bringen das erforderliche Know-how mit.
Doch auch ohne tief greifende Kenntnisse und in Eigenregie können Unternehmen mit einem Web-Applikations-Scanner mitunter gute Ergebnisse erzielen. Einige Produkte wie etwa der Acunetix Web Vulnerability Scanner lassen sich einfach bedienen und liefern für kleines Geld bessere Resultate als ein falsches Gefühl von Sicherheit beim billigsten externen Anbieter.
Empfehlenswerte Web-Applikation-Scanner
Wer den Kauf eines Web-Applikations-Scanners in Erwägung zieht, sollte die Produkte im Vorfeld allerdings sorgfältig evaluieren, da alle im Umgang mit bestimmten Techniken oder Session-Mechanismen Stärken und Schwächen aufweisen.
Die beiden bekanntesten Tools auf dem Markt sind "HP WebInspect" (vormals SPI Dynamics) und "IBM Appscan" (früher Watchfire). Beide bieten neben vielen Konfigurationsmöglichkeiten und Angriffsmustern praktische Hilfsmittel zur manuellen Nachüberprüfung aufgespürter Schwachstellen. Ein ebenfalls mächtiges Produkt ist "Cenzic Hailstorm", das aufgrund seiner Komplexität allerdings ein gewisses Maß an technischem Know-how erfordert.
Obwohl noch nicht lange am Markt, erzielen der "Acunetix Web Vulnerability Scanner" und "NT Objectives NTO Spider" gute Ergebnisse und lassen sich auch von Einsteigern relativ einfach bedienen.
Weitere Vorteile von Scannern
Unabhängig von der Wahl eines konkreten Produkts gibt es eine Reihe von Prüfungen, bei denen ein automatisierter Scanner hilfreich sein kann. Auch wenn er die manuelle Überprüfung durch einen erfahrenen Auditor nicht ganz ersetzen kann, lassen sich damit einige Arten von Schwachstellen effizient aufdecken.
Beispielsweise kann ein Scanner in kürzester Zeit prüfen, ob in einer Applikation bestimmte URLs vorhanden sind. Durch einfaches Anhängen und Ausprobieren von URLS wie "/admin", "/administrator", "/phpmyadmin" oder "/webmin" lässt sich schnell kontrollieren, ob neben der Anwendung eventuell noch weitere interessante Seiten auf dem Web-Server existieren ("Forceful Browsing"). Auch variieren die gängigen Produkte die Datei-Endungen von aufgerufenen Seiten, um - mit ein bisschen Glück - Backup-Dateien einer Seite aufzuspüren.
Wird nämlich statt der Seite "login.jsp" einfach "login.bak" angefragt und existiert diese Datei auf dem Web-Server, wird sie wegen der unterschiedlichen Datei-Endung nicht vom Web-Server interpretiert beziehungsweise ausgeführt. Der Web-Server gibt stattdessen den Quellcode der ".bak"-Datei als Text aus. Darin finden sich möglicherweise interessante Details über den Login-Vorgang.
Über die Prüfung auf Applikationsebene hinaus wird in der Regel auch auf bestimmte Schwachstellen in der Konfiguration des Web-Servers getestet. So werden beispielsweise Verzeichnisse auf mögliche Schreibrechte geprüft. Diese Aufgabe kann auch ein Scanner erfüllen oder dabei unterstützen. Durch einen Upload mit der HTTP-Methode "PUT" prüft das Tool für jedes einzelne Verzeichnis, ob der Web-Server eine auf diese Weise hochgeladene Datei annimmt.
Qualitätsmerkmale und Hürden
Die Qualität eines Scanners lässt sich jedoch nicht nur daran festmachen, wie viele und welche Prüfungen er bietet, sondern vor allem daran, wie gut er komplexe und dynamische Seiten crawlen und mit Login-Mechanismen umgehen kann.
Web-Applikationen sind heute weit komplexer als noch vor fünf oder zehn Jahren. Waren damals eher statische HTML-Seiten mit einer fest vorgegebenen Abfolge von Request und Response die Regel, sind heute mit Ajax, Flash und Silverlight hochdynamische Applikationen verfügbar, bei denen ein Scanner mit dem Erfassen und Ordnen der Website-Struktur häufig überfordert ist. So basiert Ajax darauf, dass jederzeit im Hintergrund Anfragen an eine Web-Seite gestellt werden können - sogar ohne jegliche Benutzerinteraktion. Auch wenn sich viele aktuelle Scanner darauf eingestellt haben und mehr oder weniger in der Lage sind, Ajax-Requests und Links zu parsen - das Erkennen und Verfolgen derselben ist bei automatisierten Tools nach wie vor ein wunder Punkt.
Zu den größten Herausforderungen für Web-Applikations-Scanner zählen das Session-Handling und der Umgang mit dem Login-Mechanismus einer Applikation. Das Tool muss selbständig erkennen können, ob es bei der Applikation angemeldet ist oder sich anmelden muss.
Tücken bei der Anmeldung
Am weitesten verbreitet ist die HTML-Form-basierende Anmeldung mit einem Benutzernamen und Passwort. Damit sich der Scanner selbständig bei der Applikation anmelden kann, wird in der Regel ein so genanntes Login-Makro aufgenommen: Der Auditor nimmt manuell im Browser eine Anmeldung an der Applikation vor, während der Scanner diesen Vorgang und sämtliche Eingabewerte des Auditors, also auch Benutzername und Passwort, im Hintergrund mitschneidet.
Dieses Login-Makro wird vom Scanner jedes Mal ausgeführt, wenn er eine Abmeldung beziehungsweise die Ungültigkeit seiner Session erkennt. Hier liegen die Tücken im Detail, da die Erkennung des Logouts von Applikation zu Applikation sehr unterschiedlich ausfallen kann. Am einfachsten sind Meldungen wie "Sie wurden abgemeldet" oder "Ihre Session ist abgelaufen" als Logout-Signatur zu verwenden. In schwierigeren Fällen kann es erforderlich sein, weitere Parameter wie HTTP-Statuscode, URL, Header-Variablen oder Cookie-Status hinzuzunehmen, um einen Logout zu erkennen.
Die meisten Applikationen halten den Session-Status in Cookies, die vom Anwender beziehungsweise Scanner bei jeder Anfrage mitgeschickt werden. Seltener trifft man noch Session-IDs in der URL, also als GET-Parameter, an. Beide Fälle stellen für den Scanner üblicherweise kein Problem dar. Schwieriger wird es, wenn - wie häufig etwa bei SAP-basierenden Anwendungen - die Session-ID in den URL-Pfad selbst als eine Art "virtuelles Verzeichnis" eingebettet ist. Hier müssen die meisten Scanner passen und gehen bei jeder neuen Session-ID davon aus, dass ein neues Verzeichnis vorliegt.
Solche Grenzfälle zeigen, dass sich nicht jede Applikation mit jedem Scanner erfolgreich überprüfen lässt und grundsätzliche manuelle Tests und entsprechendes Know-how hilfreich sind.
Die Grenzen der Scanner
Einige Schwachstellen sind ausschließlich durch eine manuelle Überprüfung aufzuspüren. So können Scanner beispielsweise keine Logikfehler erkennen, da sie nicht fähig sind, die Bedeutung von Parametern und URLs zu interpretieren: Ein Scanner weiß nicht, dass normale Benutzer Administrationsseiten nicht aufrufen dürfen. Daher wird er keine Schwachstelle feststellen, wenn er - im Kontext eines normalen Benutzers - unberechtigt Zugriff auf administrative Bereiche erhält.
Ein weiteres simples Beispiel wäre eine Überweisung, bei der die Zielkontonummer als URL-Parameter übermittelt wird. Ein Scanner kann nicht wissen, dass die Applikation eigentlich verhindern sollte, dass dieser Parameter etwa von "zielkonto=12345" in "zielkonto=67890" geändert wird.
Neben Logikfehlern stehen Scanner auch Plausibilitätsprüfungen einer Applikation hilflos gegenüber. Wenn eine Anwendung an einer bestimmten Stelle erst die Eingabe einer gültigen Kundennummer oder die Einhaltung einer vorgegebenen Abfolge von Eingabemasken erfordert, damit der nächste Schritt erfolgen kann ("Wizards"), gibt es derzeit keine Möglichkeit zur automatisierten Überprüfung.
Fazit
Unterm Strich tragen automatisierte Tools trotz ihrer Grenzen wesentlich dazu bei, die Effizienz von Sicherheitsüberprüfungen zu erhöhen und ohne viel Aufwand im Rahmen der 80/20-Regel einen großen Teil der Risiken zu identifizieren. Unter diesem Aspekt können Unternehmen Scanner auch in Eigenregie als hilfreiches Werkzeug nutzen. Automatisierte Scanner empfehlen sich auch, wenn eine Vielzahl von Applikationen in möglichst kurzer Zeit auf die gröbsten Schnitzer hin untersucht werden soll.
Direkt vor dem Rollout einer Applikation, nach größeren Änderungen und vor allem bei geschäftskritischen Anwendungen sollte ein professionelles Audit mit einer manuellen Komponente jedoch nicht fehlen. Denn selbst gute Scanner haben ihre Grenzen und können mit der Erfahrung und dem Detailwissen eines Auditors nicht mithalten. (ala)