Ajax-Risiken lassen sich eindämmen

Ajax-Risiken lassen sich eindämmen

Mit Ajax ist es wesentlich einfacher möglich, Scriptcode so in den Browser einzubetten, dass dieser so lange im Hintergrund läuft, bis der Browser beendet wird. Damit sind beispielsweise Angriffe denkbar, die mittels einer XSS-Attacke alle beim Surfen des Benutzers anfallenden Daten im Hintergrund zum Angreifer sendet. Eine Methode, die einen solchen Angriff ermöglicht, ist das Prototype-Hijacking.
Beim Prototype-Hijacking nutzt der -Angreifer die Möglichkeit, Scriptcode zu injizieren, um bestehende Objekte zu modifizieren oder zu überschreiben. Da Javascript bei seinem objektorientierten Ansatz keine Klassen sondern Prototypen verwendet, um Objekte zu generieren, spricht man nicht von Objekt-Hijacking, sondern von Prototype-Hijacking.
Angriffe dieser Art können nur unterbunden werden, wenn seitens der Webapplikation eine strenge Filterung nach Scriptcode erfolgt. Hierbei sind natürlich auch die gängigen Encodingverfahren zu berücksichtigen, welche Angreifer gerne zum Umgehen serverseitiger Eingabefilter verwenden.

Gefährliche Frameworks und Libraries

Da die Entwicklung von Ajax-Applikationen sehr komplex werden kann, hat sich die Verwendung von Ajax-Frameworks und -Libraries durchgesetzt. Sie sollen dem Programmierer die Verwendung von Ajax erleichtern. Der Funktionsumfang dieser Frameworks reicht vom blossen Generieren des für Ajax benötigten Client-Side-Javascript-Codes bis hin zu einem Session-Management für die Ajax-Sub-Requests. Viele dieser Frameworks wurden jedoch nicht mit dem Fokus auf eine sichere Programmierung entwickelt. Daher wurden in jüngster Vergangenheit in bekannten Frameworks etliche Sicherheitsprobleme, wie beispielsweise Cross-Site-Request-Forgery (CSRF), JSON-Injections (JavaScript Object Notation), JSON-Callback-Attacks und JavaScript-Injections, entdeckt.
Damit Ajax-Anwendungen nicht automatisch die Schwachstellen der verwendeten Frameworks «erben», ist darauf zu achten, dass stets aktuelle Versionen verwendet werden, für die keine Sicherheitslücken bekannt sind. Des Weiteren empfiehlt es sich, nicht benötigte JavaScript-Code-Funktionen, die im Framework erstellt oder in einer Library enthalten sind, zu entfernen. Einem Angreifer werden so möglichst wenig Built-in-Funktionalitäten angeboten, die ihm helfen, seine Angriffe erfolgreich durchzuführen.



Das könnte Sie auch interessieren