Unter bestimmten Voraussetzungen gibt es
eine Sicherheitslücke, wenn ein Web-Server Antworten im JSON-Format oder in Form von JavaScript
erzeugt, was gerade im AJAX-Umfeld sehr häufig der Fall ist.
Szenario: Es gibt eine Web-Anwendung,
die XMLHttpRequests (AJAX) benutzt, um vertrauliche Daten vom Server nachzuladen.
Die Rückgaben sind im JSON-Format oder JavaScript. Natürlich kann die Anwendung
erst nach einer Benutzeranmeldung mit Passwort genutzt werden.
Außerdem gibt es eine "böse"
Web-Seite auf einem anderen Server, deren Ersteller Daten ausspähen möchte.
Diese Seite enthält dazu ein <script>-Tag,
dessen src-Attribut eine URL enthält, die die geschützten Daten zurückgibt.
Anders als ein XMLHttpRequest, der nur auf URLs vom gleichen Ursprung angewendet
werden kann, erlaubt das <script>-Tag
das Einbinden von JavaScript von beliebigen Servern.
Vorher auf derselben Seite installiert
ein kleines JavaScript eine Erweiterung des Object- oder Array-Objekts,
die aufgerufen wird, wenn ein neues Objekt bzw. ein neues Array erzeugt
wird.
Dadurch wird beim Ausführen des oben
beschrieben <script>-Tags bei jedem
Objekt bzw. Array die installierte Erweiterung aufgerufen und kann auf
die vertraulichen Daten zugreifen und diese zum Beispiel mittels eines
weiteren AJAX-Aufrufs auf dem "bösen" Web-Server speichern.
Es gibt aber gleich eine ganze Reihe von Voraussetzungen:
- Es gibt eine Web-Anwendung, die vertrauliche Daten im JSON-Format oder als JavaScript zurück gibt.
- Die Rückgabe muss direkt ausführbares JavaScript sein. Das ist beim JSON-Format nur der Fall, wenn die Rückgabe ein JavaScript-Array ist.
- Der Aufruf muss als GET-Request möglich
sein, da
<script>-Tags immer GET-Requests erzeugen. - Der Benutzer muss die "böse" Web-Seite aufrufen.
- Er muss entweder noch eine offene Session auf dem geschützten Web-Server haben oder sich dort nach entsprechender Aufforderung anmelden. (Wir wissen, dass einige Benutzer das tun werden).
- Dem Angreifer muss die entsprechende URL bekannt sein. Es betrifft also entweder öffentliche Dienste (wie GMail), bei bestimmten Web-Servern immer vorhandene Anwendungen (names.nsf), bekannte, häufig installierte Anwendungen (CRM-Produkte) oder der Angreifer hat Insider-Kenntnisse.
Der mit Domino 7.0.2 eingeführte ParameterOutputFormat=JSON des ReadViewEntries-URL-Befehls
ist also nicht betroffen, da auf der obersten Ebene ein JavaScript-Objekt
(kein Array) zurückgegeben wird.
Bei selbsterzeugten JSON - etwa in Agenten
oder per HTML-Ansichten - muss man jedoch prüfen, ob eine Absicherung notwendig
ist.
Es gibt (mindestens) 2 Methoden, um
die eigene Anwendung zu schützen:
- Der Server erwartet in den Aufruf-Parametern eine Information, die er per Cookie an den Browser ausgeliefert hat. Dies kann z. B. eine zufällig erzeugte Zahl sein. Beim Erzeugen der Antwort prüft der Server dann zunächst, ob der Aufruf den Parameter enthält und dieser gleich der ausgesandten Information ist. Da der Browser den Zugriff auf Cookies auf JavaScript vom gleichen Ursprung beschränkt, kann die "böse" Web-Seite nicht auf das Cookie zugreifen.
- Man erzeugt JavaScript, das
nicht direkt ausgeführt werden kann. Zum Beispiel stellt man ein
while(true);voran. In der eigenen Anwendung kann man vor demeval()diese Anweisung entweder ausschneiden, oder man stellt//voran und macht so daraus ein Kommentar.
Update: Die folgenden Links funktionieren nicht mehr:
Für eine detaillierte Betrachtung lesen
Sie bitte die Analyse von Fortify Software.
Quelle: http://www.fortifysoftware.com/advisory.jsp
