Die Suche nach Schwachstellen in AJAX-Clients wird im Folgenden an einem Beispiel beschrieben: Eine Nachrichtenseite kombiniert Informationen aus verschiedenen RSS-Feeds.

Schwachstellensuche allgemein

Die Webanwendung läuft auf dem Server beispiel.example und besteht aus zwei Teilen: Anwendungsressourcen wie HTML-Seiten, Skripts usw. und einem Proxy, um über XMLHttpRequests auf andere Domains zugreifen zu können. Damit ergeben sich für die Suche nach Client-Schwachstellen vier Schritte:

1. Ermitteln der verwendeten Technologien und Bibliotheken
   Die Anwendung ist aus verschiedenen Bibliotheken, z.B. für AJAX und Flash, aufgebaut, die evtl. selbst Schwachstellen enthalten. Diese müssen erkannt werden.
2. Ermitteln der eingebundenen Daten und Skripte
   Die Anwendung kann in einen vertrauenswürdigen (beispiel.example) und einen nicht vertrauenswürdigen (alle anderen Server) Teil aufgeteilt werden. Nicht vertrauenswürdige Daten und Skripte müssen geprüft werden, bevor sie in den Browser geladen werden.
3. Ermitteln der DOM-Zugriffe ("DOM Access Points")
   Überall, wo das DOM durch geladenen JavaScript-Code geändert werden kann, besteht die Gefahr von bösartigen Manipulationen. Diese Punkte müssen erkannt werden, damit sie später überprüft werden können.
4. Ermitteln von Ausführungslogik und Datenfluss
   Nachdem die eingebundenen Daten und Skripte sowie die DOM-Zugriffe bekannt sind, muss festgestellt werden, wo sie während des Programmablaufs verwendet werden und wie sie interagieren.

Schwachstellensuche am Beispiel

Als Beispiel soll eine Nachrichtenseite, die Informationen aus verschiedenen RSS-Feeds zusammenstellt, dienen:

1. Ermitteln der verwendeten Technologien und Bibliotheken
   Der verwendete JavaScript-Code kann aus der geladenen HTML-Seite extrahiert werden. Im Allgemeinen wird die Seite auf einem AJAX-Toolkit aufbauen, dessen für die Anwendung relevanten Komponenten sich in der HTML-Seite wiederfinden. In diesem Fall werden es im Wesentlichen die Funktionen für die Verarbeitung von XMLHttpRequests und RSS-Feeds sein.
2. Ermitteln der eingebundenen Daten und Skripte
   Hier ist dies die Stelle, an der die RSS-Feeds angefordert werden: Der Benutzer gibt einen RSS-Feed feed an, der dann von einer Funktion wie GetRSSFeed(feed) über den Proxy angefordert wird.
3. Ermitteln der DOM-Zugriffe
   Nachdem der gesamte verwendete JavaScript-Code erfasst wurde, kann darin nach DOM-Zugriffen gesucht werden, vor allem nach Aufrufen von document.getElementById().innerHTML und document.write(). Hier werden darüber die Informationen aus den RSS-Feeds in das DOM integriert.
4. Ermitteln von Ausführungslogik und Datenfluss
   Aus den bisher gesammelten Informationen kann nun der logische Ablauf des Programms ermittelt werden. Das sieht dann ungefähr wie im Bild aus. Eine Gefahr stellt über RSS-Feeds eingeschleuster Scriptcode dar, der deshalb vom Proxy ausgefiltert bzw. unbrauchbar gemacht wird. Ob eingefügte Links eine Gefahr sein können, wurde bisher nicht geprüft. Dies wäre also als Nächstes zu tun.

Abb.: Ausführungslogik und Datenfluss

Schon der Test einer so einfachen Anwendung kann ziemlich aufwändig werden. Wie man sich leicht vorstellen kann, verschärft sich das Problem, wenn mehrere Quellen zu einem Mashup verbunden werden. Was passiert, wenn eine solche Newsseite im Rahmen eines Mashups in eine andere Seite integriert wird? RSS-Feeds dürfen keinen JavaScript-Code enthalten, also kann er rigoros ausgefiltert werden. Würde aber der JavaScript-Code aus der Newsseite ausgefiltert, würde sie nicht mehr funktionieren. Entweder, man vertraut dem Anbieter der Newsseite, bindet sie unverändert ein und fängt sich dadurch im Ernstfall dessen Schwachstellen ein, oder man muss bei der Filterung des JavaScript-Codes mehr Aufwand betreiben.

Alle Ressourcen finden

Um alle von einer AJAX-Anwendung genutzten Ressourcen zu finden, müssen im Client alle vorhandenen Links und Funktionen rekursiv aufgerufen werden: Werden z.B. beim Aufruf einer Funktion nach einem XMLHttpRequest weitere Funktionen zur Verfügung gestellt, müssen auch diese aufgerufen werden, usw. usf.. Werden Webservices genutzt, erleichtert das die Arbeit: Webservices stellen i.A. eine Beschreibung aller verfügbaren Methoden und deren Parameter und Rückgabewerte in einer WSDL-Datei (Web Services Description Language) zur Verfügung, die über ein UDDI-Verzeichnis (Universal Description, Discovery and Integration) abgefragt werden kann. Wenn man weiß, welchen Webservice eine Anwendung nutzt, kann man darüber alle verfügbaren Methoden etc. ermitteln.

Außerdem wird im AJAX-Client natürlich wie im normalen Client nach Eingabebeschränkungen, versteckten Werten usw. gesucht.

Nachdem alle Ressourcen und Parameter ermittelt wurden, geht es bei der Schwachstellensuche in AJAX-Anwendungen genauso weiter wie bei der Untersuchung normaler Webanwendungen: Die gesammelten Informationen werden auf Hinweise auf mögliche Schwachstellen untersucht. Das ist auch das Thema der nächsten Folge.

Carsten Eilers

About Security – Übersicht zum aktuellen Thema "Schwachstellensuche – I. Informationen sammeln"

• About Security #144: Schwachstellensuche: Allgemeine Infos sammeln
• About Security #145: Schwachstellensuche: Daten auswerten
• About Security #146: Schwachstellensuche: Infos im Client sammeln
• About Security #147: Schwachstellensuche: AJAX-Clients
• About Security #148: Schwachstellensuche: AJAX-Clients (2)