Ajax-Risiken lassen sich eindämmen

Allerdings ändert sich der Angriffsvektor. Ajax-basierte Anwendungen senden die Daten in Form so genannter Sub-Requests, die mittels Javascript-Code auf dem Client erstellt werden.

Da sich aus Sicherheitssicht Ajax-Applikationen serverseitig nicht wesentlich von klassischen Webapplikationen unterscheiden, sind hier die gleichen Sicherheitsmechanismen zu implementieren. Diese bestehen insbesondere in einer strengen Filterung der Benutzereingaben sowie einer konsequenten Authentifizierung beim Zugriff auf die Serverressourcen. Denn gerade bei der massiven Verwendung von Sub-Requests mittels der Ajax-Engine besteht die Gefahr, dass für die zur Verarbeitung der Sub-Requests benötigten serverseitigen Skripte nicht die gleichen Sicherheitsmechanismen (Authentifizierung, Autorisierung und Input-Filterung) angewendet werden wie für jene Serverskripte, welche die klassischen Requests bearbeiten.

Sub-Requests können im Übrigen nur im gleichen Sicherheitskontext (Protokoll, Subdomain, Zielport) gesendet werden wie der Rest der Webanwendung. Daher muss bereits in der Designphase einer Applikation entschieden werden, ob sensitive Daten per Ajax-Sub-Request übertragen werden sollen. Ist dies der Fall, sollte die komplette Applikation nur über Secure Socket Layer (SSL) erreichbar sein.

Während sich also die serverseitigen Risiken im Vergleich zu normalen Webapplikationen kaum ändern, erreichen clientseitige Angriffe eine neue Dimension. Aufgrund der eigenständigen, im Hintergrund ablaufenden Aktivitäten der Ajax-Engine können sich clientseitige Angriffe wie beispielsweise XSS dauerhaft im Browser einklinken. Damit stellen sie ein deutlich höheres Risiko dar als bei klassischen Applikationen.

XSS-Angriffe vor Ajax hatten grundsätzlich eine sehr kurze Lebensdauer in der Applikation. Klickte ein Benutzer auf einen von einem Angreifer modifizierten Link, so wurde der darin eingebettete Script-Code einmalig ausgeführt. Wollte man dem Scriptcode jedoch eine längere Lebenszeit im Browser ermöglichen, musste man mit allerhand Tricks arbeiten - was wiederum sowohl das Risiko der Angriffserkennung durch den Benutzer als auch die Komplexität des Angriffs und somit dessen Fehleranfälligkeit erhöhte.