Web-Applikationen – Web 2.0 sei Dank, die Menge von Tools auf Basis von Ajax wächst rasant. Wie jede Anwendung, so leiden auch diese unter Vulnerabilities. Web-Application-Scanner haben sich auf die Fahne geschrieben, diese Fehler zu finden.

Bei der Anwendungssicherheit kann nichts eine mehrstufige Abwehrstruktur und -strategie gleichwertig ersetzen. Web-Application-Scanner sind nur ein Element in einem ausgewogenen Konzept, in dem Anwender und Entwickler geschult und Tests sowie Audits durchgeführt werden. Programme auf Basis von Ajax setzen aber jede Strategie, mag sie auch noch so durchdacht sein, unter Druck.

Denn sie teilen die Intelligenz auf den Server und den Client auf und geben dem per se unsicheren Browser zu viel Verantwortung.

Daher sollte ein Unternehmen, wenn es Application-Scanner kaufen möchte, auf jeden Fall von Lösungen Abstand nehmen, die die Sprachen und Modelle aus der Web 2.0 eben noch nicht beherrschen. Denn dank der Popularität wird der Anteil dieser Sprachen explosionsartig anwachsen.

Die Real-Word Labs haben daher in ihrem Test zwei Web-Application-Scanner untersucht. Beide behaupten von sich, Ajax in den Griff zu bekommen. Der »WebInspect« von SPI Dynamics sowie der »Hailstorm« von Cenzic mussten beweisen, wie gut sie darin sind, Tools auf Basis der Web-2.0-Sprachen zu verstehen und darin bekannte Vulnerabilities aufzuspüren.

Rich-Internet-Anwendungen (RIAs) auf Basis von Ajax sind in der Regel in zwei Sprachen programmiert. Doppelte Komplexität bedeutet doppelte Gefahr. In einer Webumfrage unter 5000 Entwicklern Ende 2006 gaben immerhin 46 Prozent an, sie werden Ajax in ihren Projekten innerhalb der kommenden 12 Monate einsetzen. Nur magere 27 Prozent wollten auf Flash setzen. Wer im Unternehmen für IT-Sicherheit Verantwortung trägt, sollte daher einen Plan entwickeln, diese Anwendungswelt in den Griff zu bekommen.

Webinspect von SPI Dymanics

Der Scanner »WebInspect 7.0« von SPI Dynamics musste beweisen, wie gut er darin ist, die Fehler in den drei für diesen Test aufgesetzten Webanwendungen zu finden. Leider hat er bei der Analyse der darin eingebetteten Javaskripts nicht gut abgeschnitten. Die automatisch ablaufende Analyseroutine des Scanners hatte Schwierigkeiten, alle Funktionen der Anwendungen zu identifizieren. Aber auch, als die Tester das Werkzeug per Hand durch alle Menüpunkte und Künste dirigierten, hatte es Schwierigkeiten, die Javaskript-Links richtig zu handhaben. Dies ist kaum zu tolerieren. Denn wie soll ein Werkzeug alle Vulnerabilities finden, wenn es nicht einmal alle Funktionen erkennt, die ein Programm beherrscht?

Das Produkt hat durchaus auch Stärken, aber seine Schwächen wiegen schwer. Für den Test ist ein wichtiges Kriterium, wie viele False-Positives und -Negatives es erzeugt. Also, wie oft meldet der Scanner Vulnerabilities, die keine sind, und wie oft sieht es alles rosig, obwohl sich im Code gefährliche Fehler verstecken? Hier harte Kriterien einzuführen ist beim jetzigen Stand der Produktreife verfrüht. Außerdem existieren unzählige Methoden, Fehlerraten zu zählen.

Hier einige Beispiele: Gilt jeder einzelne falsche Eintrag im Scan-Ergebnis als Fehler, oder werden die vom dem gleichen Code ausgelösten False-Positives in einer Klasse zusammengefasst und als ein Eintrag gewertet? Außerdem könnte ein Produkt mehr Fehler erkennen als der Vorgänger, weil die Vulnerabilities erst im Lauf des Tests öffentlich bekannt wurden. Außerdem sagen Zahlen an sich wenig über die Qualität des Produkts aus. Sie legen nicht offen, wie sich der Scanner tunen lässt, damit er den Fehler beim nächsten Mal nicht wiederholt. Zahlen sagen auch nichts darüber aus, wie gut sich die Berichte des Scanners anpassen lassen oder wie schnell der Hersteller sein Produkt überarbeitete.

Nichtsdestotrotz hat Webinspect unter False-Positives gelitten. Schlimmer noch, das Tool hat signifikante False-Negatives generiert und eine XSS-Schwäche (Cross-site Scripting) in einer der Anwendungen übersehen. Die Ursache für Letzteres war ein Fehler im Programm, den der Hersteller in der jüngsten Version bereits beseitigt hat. Leider ließ sich dieser Bug nicht durch ein kleines Update reparieren.

Der Scanner hat SQL-Injections erkannt, wo keine waren. Außerdem hat er den Apache-Server auf der Linux-Maschine als einen Apache auf Windows-ME verkannt. Ironischerweise zeigten die False-Positives bei Windows-ME einige Stärken des Produkts: Es war recht leicht, die Ursache für die Warnmeldung zu finden. Der Alert hat relevanten HTML-Code, der den Alarm auslöste, hervorgehoben. Die Anwendung hat ihren Inhalt mit einem »XML