Ajax Security - Sichere Web-2.0-Anwendungen

Was ist bei Ajax-Anwendungen anders als bei herkömmlichen? Wo sind die Schwachstellen? Neue Programmiertechniken und Web-2.0-Anwendungen schaffen ganz neue Angriffspunkte, die vielen Entwicklern noch gar nich bekannt sind. Carsten Eilers zeigt wo Gefahren lauern und welche Gegenmaßnahmen Sie ergreifen können. Finden Sie Fehler, bevor andere es tun!

1.3 Ajax und die Architektur (S. 19)

Die ersten Ajax-Webseiten waren normale Webseiten, die um ein paar neue Funktionen erweitert wurden. Das konnten z.B. Menüs sein, die automatisch aus- oder einfuhren, wenn der Benutzer den Mauszeiger darüber bewegte, oder Textbereiche, die sich auf- und zuklappen ließen. Dabei handelte es sich aber im Wesentlichen um optische Auffrischungen ohne neue Funktionen für den Benutzer. Nach und nach entwickelten sich die Ajax-Anwendungen weiter, bis sie beim heutigen Stand ankamen: Webseiten, die sich fast wie Desktopanwendungen verhalten.

In der Vergangenheit gab es für Clients nur zwei Kategorien: Thick Clients, bei denen der größte Teil der Arbeit auf dem Client erledigt wird, und Thin Clients, bei denen der größte Teil der Arbeit auf dem Server erledigt wird. Während sich bei einem Thick Client ein großer Teil der Anwendungslogik auf dem Client befindet und der Server z.B. nur eine Datenbank bereithält, befindet sich beim Thin Client die gesamte Anwendungslogik auf dem Server, während der Client nur für die Ein- und Ausgabe der Daten zuständig ist.

Ajax-Anwendungen sind ein Zwischending zwischen Thick Client und Thin Client: Wie bei einem Thick Client enthalten sie einen mehr oder weniger großen Teil der Anwendungslogik, und wie bei einem Thin Client sind sie nicht auf dem Client installiert, sondern laufen nur im Webbrowser. Ajax-Anwendungen bieten die umfangreiche und schnell reagierende Benutzeroberfläche der Thick Clients, und die Vorteile der leichten Installation und Wartbarkeit der Thin Clients. Man könnte sie also als das Beste aus beiden Welten bezeichnen.

Leider sind sie aus Sicherheitssicht das genaue Gegenteil, denn sie bringen die Schwachstellen beider Architekturen mit sich: Der größte Teil der Anwendungslogik befindet sich im Client und liegt außerdem noch als Quelltext vor.

Der Angreifer hat uneingeschränkten Zugriff darauf, und damit ist es ziemlich schwierig, irgendwelche Geheimnisse auf dem Client zu speichern. Der Angreifer kann alle Daten und auch die Programme nach Belieben studieren und manipulieren. Die zwischen Client und Server i.A. über HTTP ausgetauschten Nachrichten lassen sich leicht abfangen und analysieren.

1.4 Die Angriffsfläche

1.4.1 Größere Angriffsfläche? Jein!
Zuerst kurz etwas »Myth-busting«: Manchmal wird behauptet, durch Ajax bekämen Webanwendungen eine größere Angriffsfläche. Das stimmt so nicht: Die Angriffsfläche besteht aus den Punkten, an denen Datenein- und -ausgaben manipuliert werden können. Bei Webanwendungen also aus den Funktionen, auf die vom Client aus zugegriffen werden kann. Und die bleiben gleich, unabhängig davon, wie die Benutzeroberfläche auf dem Client aussieht und wie sie realisiert wurde.

Vom Client gelieferten Daten darf nicht vertraut werden – egal ob der Client statisches HTML, Ajax, Flash oder was auch immer verwendet. Wird eine bestehende Webanwendung um einen Ajax-Client erweitert, werden oft Teile der vorhandenen Funktionen in Form eines Webservices an den neuen Client angepasst: Die Ausgabe des Ergebnisses erfolgt nicht mehr direkt an den Benutzer, sondern an den Ajax-Client, der das Ergebnis dann aufbereitet und an den Benutzer ausgibt.

Dabei entstehen aber keine neuen Angriffspunkte, vorhandene werden lediglich umgewandelt. Erst wenn durch die neuen Möglichkeiten auf dem Ajax-fähigen Client zusätzliche Funktionen bereitgestellt werden, erhöht das die Anzahl der möglichen Angriffspunkte – aber das hat nichts mit Ajax zu tun.