Web-Applikationen – Die wunderbare Welt von Web 2.0 und ihre Anwendungen entwickeln sich weiter – und mit ihr alle Vulnerabilities und Fehler. Web-Application-Scanner versprechen, diese mächtigen Fehler zu finden. Das mussten sie in den Real-World Labs aber erstmal beweisen.

Wer nach dem Begriff Web 2.0 googelt, dem wird vor Suchtreffern schwindelig. Reich, bunt, einfach schön werden diese »Rich Internet Anwendungen« (RIA) sein, sagt das Web dazu. Wer sich von Berufs wegen mit Informationssicherheit auseinandersetzt, dem wird bei RIA auch schwindelig, aus anderen Beweggründen. Denn die neue Form der Anwendung splittet die Intelligenz zwischen Server und Client auf und folgt so einem fundamental anderen Konzept. Das Modell darf durchaus als riskant angesehen werden.

Jeder, der sich den bescheidenen Stand der Browser-Sicherheit vor Augen führt, wird dem sofort zustimmen. Außerdem könnte dieses Entwicklungsmodell, das nur ein Subset von RIA betrifft, dank seiner Eigendynamik und seiner charakteristischen Eigenschaften es künftig generell extrem schwierig gestalten, Vulnerabilities im Code zu beseitigen.

Die Produkte der Kategorie »Web Application Scanner« wollen hier helfen, aber ihre Implementierung ist hürdenreich. Denn der Weg zu RIA und Ajax-Sicherheit ist keineswegs eindeutig. Die Real-World Labs haben vier verschiedene Ansätze herausgearbeitet, die dieses Ziel dennoch zu erreichen versuchen.

Kritik an geteilter Macht

Warum sind RIA so unsicher? Eine einfache, abstrakte Erklärung: Bei einer konventionellen Anwendung ist die gesamte Intelligenz auf dem Webserver geballt. Der Browser agiert mehr oder weniger als dumpf stumpfes Display der Inhalte. Natürlich bringen Active-X, Java-Applets und andere Techniken wie Flash mehr Funktion in das einfache Webfenster, aber weit weniger, als RIA vom Prinzip her tun will.

Letzteres Anwendungskonzept hebt den Browser tatsächlich auf eine höhere Stufe. Er darf mächtige, interaktive Anwendungen hosten, die ihrerseits Queries direkt an den Server schicken und so weitere Daten laden. Heute stehen Anwendungen auf Basis von Ajax zwar noch auf einer Stufe mit Flash von Adobe und Apollo, Suns Java, Mircrosofts »Windows Presentation Foundation« und Active-X. Aber Ajax gewinnt immer mehr an Fahrt.

Die Abkürzung steht übrigens für »Asynchronous Javascript and XML« und ist zu einem der wichtigsten Zauberwörter bei Web 2.0 geworden. Immer mehr Entwickler greifen diesen Begriff auf und verpassen ihren Tools ein »Ajax«-Label, auch wenn ihre Werkzeuge heute hauptsächlich noch asynchrone Javascripts verwenden.

Hierbei wird die erste Seite vom Server per Javascript-Aufruf geladen, der dann asynchron Anfragen zurück an den Server schickt. So lädt der Browser lediglich nur den Teil der Daten und der Webseite, die er für eine bestimmte Aktion justieren, aktualisieren oder modifizieren muss.

Typischerweise tauschen Ajax-Anwendungen diese Pakete zwischen Server und Client mit »XMLHttpRequest API«-Calls aus, wobei sie die Informationen im XML-Format transferieren. Die Verarbeitung dieser Messages erzeugt Komplexität und einen leichten Overhead. Daher haben die Programmierer Wege gesucht, die Sache zu vereinfachen. Ihre Tools verwenden zwar die gleichen XMLHttpRequest-API-Calls, weichen aber auf Varianten wie Javascript-Objekt-Notation (JSON) aus. JSON seinerseits nutzt Javascript-Objekte anstelle von XML als Transportmedium. Auf diese Weise kann der Client Daten, die der Server ihm in einer Antwort geschickt hat, ausführen und so ein Ergebnis seiner Aktionen errechnen, ohne XML parsen zu müssen.

Andere Anwendungen liefern dagagen Raw-HTML als Resultat, die Javascript dann in ein Document-Object-Model (DOM) einfügen kann. Hinter DOM verbirgt sich das Programmiermodell des Browsers. Damit sind Javascripts in der Lage, mit HTML und XML zu interagieren und eine Web-Seite entsprechend zu modifizieren, ohne das mächtige XML oder JSON verwenden zu müssen.

Obwohl viele Programmierer diese Ausweichverfahren beim Transportmechanismus verwenden, packen sie ihre Tools gerne in die große moderne, hippe Ajax-Kiste. Es ist an der Zeit, dass der Markt Begriffe hervorbringt, die diese in wichtigen Bereichen wie dem Transport grundverschiedener Applikationen auch namentlich voneinander trennen. Bis dahin müssen alle von Ajax-Werkzeugen sprechen.

Es könnte durchaus geschehen, dass auch andere Sprachen auf dem Gebiet der RIA eine größere Rolle einnehmen. Vor allem Flash und Java besitzen genügend Potenzial. Bisher werden diese Sprachen von Web-Application-Scannern aber ignoriert. Wer seine Anwendungen auf Basis von Java schreibt und deren Sicherheit testen will, sollte daher auf die Produkte der Kategorie »Source Code Scanner« ausweichen.

Die Pfade zählen

Wenn Browser Daten per Query direkt beim Server anfragen dürfen, hat das Konsequenzen für die Sicherheit im Netz, und zwar nicht wenige. Leider gibt es im Bereich der RIA zahlreiche Gelegenheiten, die Sache falsch anzugehen, an falscher Stelle den Hebel anzusetzen.

Wer beispielsweise Schutzmechanismen nur auf dem Client implementiert, wird sein Ziel verfehlen, da er den Server außen vor lässt. Dabei ist durchaus nachvollziehbar, Letzteren erst einmal zu ignorieren, Denn Ajax-Anwendungen sind unglücklicherweise in mindestens zwei Sprachen geschrieben: Javascript für den Client, und irgendeine andere auf dem Webserver. Hier winkt viel Dynamik, die nur schwer zu kontrollieren ist.

Last, but not least, bringt diese Art der Anwendung völlig neue Vulnerabilities hervor. Derzeit kann noch kein Experte abschätzen, wie ausschweifend sich diese missbrauchen lassen. Eins darf aber als garantiert gelten. Aus Sicherheitssicht ist das Modell dieser Tools, die Intelligenz und Macht auf Server und schwachbrüstigen Browser-Client aufzuteilen, keineswegs vorteilhaft.

Harter Weg zum Ergebnis

Wer wissen will, ob seine Applikationen sicher sind, kommt an Penetrationstests kaum vorbei.

Konventionelle Vulnerability-Assessment-Scanner (VA) sind schon länger auf dem Markt, und auch Web-Application-Scanner haben sich in ihrer Nische behaupten können. Neu dagegen ist, wie Letztere versuchen, auf Ajax basierende Werkzeuge zu untersuchen.

Der größte Unterschied zu bisherigen VA-Konzepten: Der Administrator wird viel mehr Vorarbeit investieren müssen, damit sein Ajax-Security-Werkzeug vernünftige Ergebnisse aus Web-2.0-Welt liefert. Bevor der Verwalter den Scanner überhaupt auf die Vulnerabilities loslassen kann, muss er ihm alle Funktionen der Applikation beibringen. Denn erst wenn das Tool jeden Winkel der Websoftware kennt und auch noch versteht, kann es die interne Struktur, offensichtliche und weniger eindeutige Abhängigkeiten und das Abfrageverhalten nachvollziehen. Dies klingt kompliziert, ist bei konventionellen Anwendungen relativ leicht und schnell getan.

Bei Ajax-Tools dagegen liegt der Fall völlig anders. Um sie zu verstehen, muss der Scanner analysieren, wie viel Macht die eingebetteten Javascripts ausüben könnten. Welche immanenten Fähigkeiten besitzen die Skripts, welche Formate benutzen sie, und welche Daten tauschen sie aus? Daher muss der Scanner auch wissen, wie er die Antworten von Serverseite parsen muss. Dazu muss er natürlich dessen Sprache sprechen.

Als ob dies nicht schon schwer genug wäre, müssen Web-Application-Scanner neben den Ajax-spezifischen Vulnerabilities auch die Schwächen konventioneller Webanwendungen kennen. Denn diese älteren, durchaus besser verstandenen Fehler sind heute keineswegs verschwunden, nur weil Web 2.0 erfunden wurde. Beweise gibt es viele, so vom auf Websecurity spezialisierten Dienstleister Acunetix. Er führt kostenlose Scans von Internetseiten durch und gab an, dass er im vergangenen Jahr bei 3200 Pages rund 210 000 Vulnerabilities gefunden habe. Die Daten müssen richtig interpretiert werden. Hier haben also Administratoren einen kostenlosen Scan beauftragt, um ihrer Webseite auf den Zahn zu fühlen. Engagierte Verantwortliche also, denen der Status ihrer Webpräsenz am Herzen liegt. Es ist daher wahrscheinlich, dass die weltweite Dunkelziffer noch viel höher liegt.

Bei den gefunden Schwächen wurde eins deutlich: Der Browser rückt immer mehr ins Zentrum des Geschehens. Viele der Angriffe waren nur deshalb möglich, weil die Entwickler schlicht unterschätzten, welche funktionale Macht die Browser heute bereits besitzen.

Wer sich einen Eindruck von dem Stand der Browser-Sicherheit verschaffen will, sollte die Foren sla.ckers.org und ha.ckers.org besuchen. Dort wird er Diskussionen finden, die die jüngsten Vulnerabilities und Exploits ausschlachten und in Demonstrationen ihre Arbeitsweisen offenlegen.

Den richtigen Pfad wählen

RIAs müssen gesichert werden. Dazu sollte ein Unternehmen mehrere Ansätze verfolgen, denn mit Scanner kaufen und installieren ist es nicht getan. Es ist empfehlenswert, intern jemanden dezidiert für das Web-Applikation-Scanning abzustellen und diese Anwendungen mit einem der kommerziellen Tools untersuchen. Dieses Werkzeug sollte nicht von der IT-Sicherheitsabteilung, sondern in der Entwicklungsabteilung benutzt werden. Außerdem lohnt es sich, in diesem Zusammenhang einige Best-Practive-Vorgaben umzusetzen:

• die Entwickler schulen,
• während der Designphase und der weiteren Entwicklung Sicherheitstests ansetzen,
• die Implementierung genau analysieren,
• Prozesse für alle Sicherheitsverstöße aufsetzen und sie beseitigen, auch wenn dies im Ernstfall viel Zeit erfordert,
• Standard-Code-Module, die rigoros und penibel gepflegt werden, sollten vernünftig wiederverwendet werden.

Web-Application-Scanner decken natürlich nur einen Teil der Aufgaben ab, um Anwendungen sicherer zu machen. Die in dem Test untersuchten Werkzeuge binden beispielsweise Workflow-Tracking-Systeme, Schulungsprogramme und andere Ressourcen an.

Einige Unternehmen unterliegen Compliance-Anforderungen wie dem PCI-DSS (Payment-Card-Industries- Data-Security-Standard). Diese zwingen sie, alljene Programme zu untersuchen, die mit Kreditkartendaten hantieren. Ihnen werden diese Scanner sicher helfen, die rechtlichen Rahmenbedingungen einzuhalten und zu dokumentieren, dass sie die nötigen Schritte zu mehr Sicherheit eingeleitet haben.