"Ajax Security" scheint zurzeit das Betätigungsfeld jener zu sein, die beim Anschieben des Ajax-Zuges eher hinten standen - und nun, da er rollt, warnend den Finger heben: War denn nicht JavaScript im Browser immer schon gefährlich? Und da es in Ajax-basierten Seiten recht umfangreich genutzt wird, muss sich doch die Gefährlichkeit erhöht haben. Oder?

Bitte verstehen Sie mich nicht falsch: Security ist eine furchtbar ernstes Thema. Aber es gibt so viele Web-Beiträge, die Emotionen streuen, statt Wissen zu vermitteln, Beispieltitel: "Ajax Security Could Pose Serious Risk". Immer wieder aufgeführt: der "Yamanner Virus", quasi der Referenzwurm im Ajax-Umfeld. - Beruhigend, dass es auch viele gute technische Beiträge zum Thema gibt. Und auch beruhigend, dass die Inhalte dieser Beiträge durchgehend ähnlich sind. Will sagen: Die zu beachtenden Punkte sind recht eingekreist.

Die Grundaussage ist zunächst: Es gibt keine neuen technologischen Risiken bei der Verwendung von JavaScript im Ajax-Sinne. Die Aspekte, die in den folgenden Betrachtungen angesprochen werden, sind bekannt und existent, seitdem es JavaScript im Browser gibt.

JavaScript im Browser läuft in einer Umgebung, die dem "Sandbox"-Prinzip folgt. JavaScript läuft in einer Web-Seite, kann mit deren Elementen umgehen und kann zu dem Server kommunizieren, von dem aus es geladen wurde – mehr nicht. Von einer Seite aus kann man zwar auf Elemente anderer Seiten (z.B. in einem Nachbar-Frame) zugreifen, aber nur wenn diese vom gleichen Server geladen wurde. Einen Zugriff auf lokale Ressourcen (z.B. Dateisystem) gibt es nicht.

Nun kommt's aber: JavaScript ist zum einen eine Sprache, die als Text direkt im Browser abläuft - also keine Compile/Make-Aktivitäten erfordert. Zum anderen erlaubt es JavaScript, über Veränderung von Seitenelementen wiederum neues JavaScript in eine Seite einzufügen. In eine Seite kann z.B. ein neues optisches Element (Button) eingefügt werden, das selbst wiederum JavaScript enthält (Event-Behandlung). - Aus beiden Aspekten resultiert nun eine Gefahr, die als "JavaScript Injection" oder als "XSS - Cross Site Scripting" bezeichnet wird: Man ist in der Lage, fremdes JavaScript in eine Seite einzuflößen.

Konkretes Beispiel: In einer Seite kann der Benutzer einen Namen erfassen, der dann in einer Folgeseite in einer HTML-Liste ausgegeben wird. Wäre doch lustig, mal auszuprobieren, was passiert, wenn man statt eines langweiligen Namens, "Müller", ein kleines Progrämmchen eingibt: "Mül<script>alert("Hallo!")</script>ler". Wenn nun auf der Folgeseite eine Alert-Box mit dem Inhalt "Hallo!" hochkommt, dann haben Sie"s geschafft! Ihre erste "Injection" läuft. - Der Fantasie, nun etwas komplexere Programme einzufügen, sind nun keine Grenzen gesetzt. Und diese Programme könnten entweder auf Daten der Seite zugreifen oder auch zum Server zurückkommunizieren.

Neben der Injection sei ein zweiter Security-Aspekt betont – der wiederum nichts mit Ajax per se zu tun hat, sondern für alle Rich-Client-Implementierungen gilt, die über ein offenes Protokoll (HTTP) mit dem Server kommunizieren: Man könnte einen "Fake-Client" entwickeln, der den Client simuliert. "Hoffnung" dabei: Eingabeprüfungen, die im Rich Client gemacht werden, werden im Server nicht noch einmal vollzogen.

Beispiel: Bei einer Abbuchung von einem Konto über eine Ajax-Seite wird durch JavaScript-Logik sichergestellt, dass Sie nur Ihre eigene Kontonummer eingeben können. Im "Fake-Client", der das HTTP-Protokoll des Buchungsvorgangs abspielt, versuchen Sie es nun mal mit der Kontonummer Ihres Nachbarns. Vielleicht schluckt's der Server ja.

Konsequenz: Auch wenn der Client durch Verwendung von Ajax noch so schlaue Eingaberestriktionen macht - die im Server liegende Verarbeitungslogik darf nie und nimmer darauf setzen, dass der Client richtige Daten sendet. Alle Logik muss unbedingt im Server noch mal abgearbeitet werden. Auch hier muss Ihre Architektur entsprechend ausgestaltet werden.

Quintessenz: Ja, richtig, es gibt "Security-Concerns" im Ajax-Umfeld. Und da es diese gibt, müssen Sie unbedingt ernst genommen werden. Insofern relativiere ich meine kleinen Seitenhiebe am Anfang dieses Textes gegen die Mahner und hoffe, dass das Mahnen zumindest die Ajax-Entwicklerschar sensibilisiert!

Björn Müller leitet bei der Software AG den Bereich "XMLi User Interfaces", der u.a. eine AJAX-basierte Frontend-Lösung für interaktive Unternehmensanwendungen verantwortet. Mit seiner Firma Casabac (heute Teil der Software AG) war Björn Müller einer der frühen AJAX-Pioniere in Deutschland.