Sicherheit und Web 2.0

Der ehemalige deutsche Bundesminister Norbert Blüm sagte einmal, Technik sei wie ein Messer, man könne damit morden oder Brot schneiden. Ähnlich verhält es sich mit der IT, denn auch hier kann jede Technik zum Guten wie zum Schlechten eingesetzt werden. Ein besonders gutes Beispiel hierfür ist JavaScript.


Ursprünglich wurde JavaScript im wesentlichen eingeführt, um dynamisches HTML und eine deutlich verbesserte Interaktion mit dem Benutzer zu ermöglichen. Allerdings gibt es einige Anweisungen, die ein Angreifer ausnutzen kann, um eigenen Code in eine fremde Webseite einzuschleusen. Diese Art des Angriffs, bei der Scriptcode einer Webseite einer anderen untergeschoben wird, wird Cross-Site-Scripting genannt und als XSS abgekürzt.
Während JavaScript in der Vergangenheit auf den meisten Webseiten – wenn überhaupt – nur sehr vereinzelt und gezielt für bestimmte Funktionen eingesetzt wurde, ist es in Webanwendungen allgegenwärtig, die auf Web 2.0 und damit auf AJAX als technologische Basis setzen.

XSS Reloaded

Eine der bisher einfachsten Möglichkeiten, einer Webseite fremden Inhalt unterzuschieben, sind Formularfelder. Sei es ein Suchformular oder eine Registrierung als neuer Benutzer – überall, wo der Benutzer Daten eingeben muss, die nachher auf die eine oder andere Weise wieder zur Anzeige kommen, lassen sich HTML-Tags eingeben. Filtert eine Webanwendung solchen HTML-Inhalt nicht aus der Eingabe heraus, wird er im Rahmen der eigentlichen Webseite angezeigt.



Eine besondere Gefahr ergibt sich dadurch, dass der untergeschobene Inhalt im Kontext der angegriffenen Seite ausgeführt wird. Vertraut der Benutzer dieser Seite, führt der Browser den Inhalt des Angreifers anstandslos aus. Allerdings lassen sich auf diese Art nicht nur HTML-Tags in eine fremde Seite einbinden, statt dessen kann auch JavaScript-Code eingeschleust werden.

Solche Eingaben durch die Suche nach den entsprechenden Script-Tags zu erkennen, ist reichlich aussichtslos. Es gibt schlichtweg zu viele Möglichkeiten, Java­Script in eine Seite einzubinden: Sei es als direktes Script-Tag, als Eventhandler eines beliebigen Tags, als URL des Hintergrundbildes eines Tags in einem Style­sheet – die Möglichkeiten sind endlos und nur durch die Phantasie des Angreifers beschränkt.



Neben der Möglichkeit, einer Webanwendung direkt fremden JavaScript-Code unterzuschieben, besteht des weiteren noch die Möglichkeit, ein externes Script nachzuladen, was ebenfalls durch zahlreiche Varianten umgesetzt werden kann.
Greift ein solches eingeschleustes Script beispielsweise auf document.cookie zu, erhält es Zugriff auf alle Cookies der angegriffenen Seite. Auf diese Art lassen sich nun zum Beispiel Cookies, die zur Authentifizierung eines Benutzers dienen, stehlen. Wird der entsprechende Code im Rahmen eines Benutzerprofils oder eines Gästebucheintrages permanent auf einer anzugreifenden Seite plaziert, erhält der Angreifer bei jedem Aufruf das Authentifizierungs-Cookie des aktuellen Benutzers (siehe Kasten «JavaScript einschleusen»), was als Session Hijacking bezeichnet wird.



AJAX hat dieses Problem noch verschärft, indem ein weiteres Einfalltor geschaffen wurde, durch das einer Seite fremder Code untergeschoben werden kann: In der Regel wird die JavaScript-Methode innerHTML verwendet, um Inhalt dynamisch nachzuladen und in die bestehende Seite einzubinden. Gelingt es einem Angreifer, den anzuzeigenden Inhalt zu manipulieren, wird der Schadcode von innerHTML bequem in die angegriffene Seite eingebaut.



Für all diese Fälle gilt also, dass nicht nur Eingaben des Benutzers als böse gelten, sondern jegliche Daten, die – in welcher Form auch immer – nachgeladen werden und zur Anzeige kommen. Um sich gegen solche Angriffe zu schützen, sollte ein besonderes Augenmerk auf gewisse Zeichen gerichtet werden, die häufig in Angriffen vorkommen. Dazu zählen die Spitzklammern < und >, das einfache und das doppelte Anführungszeichen ‘ und “ sowie das Kaufmanns-Und &. Werden diese Zeichen konsequent und korrekt durch ihre HTML-Äquivalente maskiert, hat man bereits einen ersten Schutz errichtet.




Cross-Site-Scripting als Angriffsmethode

Die JSON-Problematik

Zahlreiche Webanwendungen, die auf AJAX basieren, nutzen das JSON-Format (JavaScript Object Notation) zum Austausch von Daten zwischen Client und Server. Das Besondere an JSON, das eine Art Serialisierung eines JavaScript-Objekts darstellt, ist, dass JSON mit Hilfe der JavaScript-Methode eval direkt wieder deserialisiert und in ein JavaScript-Objekt übersetzt werden kann.


Ein Angreifer kann JavaScript und XSS nutzen, um Daten, die im JSON-Format übertragen werden, zu stehlen. Dazu muss er die folgenden Schritte unternehmen:

- Der Angreifer muss den Konstruktor von Object() überschreiben und den Setter des letzten Feldes so modifizieren, dass eine Exploit-Methode aufgerufen wird. Dies setzt voraus, dass der Angreifer weiss, welches das letzte Feld des zu stehlenden Objektes ist, was bei öffentlich verfügbaren Diensten wie etwa E-Mail-Diensten meist leicht herauszufinden ist.



- Die Exploit-Methode iteriert über alle Felder des Objektes, auf dem sie aufgerufen wurde, und erzeugt aus diesen einen String. Dieser String wird anschliessend per XMLHttpRequest an den Server des Angreifers übertragen. Die Exploit-Methode muss an den Setter des letzten Feldes gehängt werden, um zu verhindern, dass unvollständig initialisierte Objekte versendet werden.



- Sofern der Angreifer nicht die Möglichkeit hat, direkt die Seite zu manipulieren, auf der das JSON-Objekt abgefragt wird, muss dieses vom Server abgefragt werden. Dadurch, dass die Seite nachher im Kontext eines bestimmten Benutzers läuft, werden dann die richtigen Daten abgerufen.



- Schliesslich muss der Angreifer sich noch darum kümmern, den überschriebenen Konstruktor und die Exploit-Methode in die anzugreifende Seite einzuschleusen, wozu er sich beispielsweise die bereits bekannten XSS-Angriffe zunutzemachen kann.
Diese vier Schritte erweitern die anzugreifende Anwendung derart, dass bei jeder Instanzierung eines JSON-Objekts die Exploit-Methode aufgerufen wird, die das Objekt erneut serialisiert und an den Angreifer versendet.
Da zahlreiche Webanwendungen, die sich dem Web 2.0 verschrieben haben, als Mashups fungieren – also als Seiten, deren Inhalt aus zahlreichen verschiedenen Seiten dynamisch zusammengestellt werden kann –, wird es für den Angreifer noch einfacher, den Schadcode unterzuschieben. Vereinfacht gesagt kann eine Seite entweder sicher oder als Mashup gestaltet sein – beides gleichzeitig ist nicht möglich.


Um sich vor solchen Angriffen zu schützen, gibt es drei Varianten:



- Zum einen sollte jede Anfrage an den Server mit einem schwer zu erratenden Wert wie beispielsweise der Session-ID versehen werden, um Anfragen als legitim zu authentifizieren. Bei dieser Variante muss natürlich sichergestellt werden, dass die Session-ID nicht mit Hilfe anderer Tricks wie beispielsweise den beschriebenen XSS-Verfahren vom Angreifer ausgelesen werden kann.



- Zum zweiten wird das JSON-Objekt von dem Script des Angreifers in der Regel per GET abgerufen. Wird die Webanwendung von vornherein so gestaltet, dass alle JSON-Anfragen nur per POST durchgeführt und GET-Anfragen ignoriert werden, errichtet dies eine weitere Hürde, die der Angreifer überwinden muss.



- Zum dritten kann der Server jedem JSON-Objekt, das an den Client zurückgeschickt wird, zusätzlichen JavaScript-Code voranstellen, der von jedem legitimen Aufruf ausgefiltert wird. Versucht Schadcode, auf das Objekt zuzugreifen, wird vor der Instanzierung des Objekts zunächst der zusätzliche Code ausgeführt, der beispielsweise eine Endlosschleife erzeugen könnte, so dass das gestohlene Objekt nutzlos wird.



Daten abzweigen per JSON

Fazit

So nützlich AJAX ist, um komfortable und benutzerfreundliche Webanwendungen zu erstellen, so gefährlich ist es auf der anderen Seite auch. Neben neuen Sicherheitslücken wie der JSON-Problematik werden auch altbekannte Probleme wie Cross-Site-Scripting zu neuem Leben erweckt.


Auch hier gilt also wieder der Grundsatz, dass Komfort und Sicherheit einander zunächst widersprechen. Um eine Webanwendung komfortabel und sicher zu machen, ist unter Umständen ein enormer Aufwand nötig, was die Frage nach dem Nutzen von AJAX aufwirft. Fraglos gibt es Anwendungen, die ohne AJAX nicht oder nur schlecht denkbar wären. Andererseits ist es zurzeit häufig auch bloss «in», AJAX zu benutzen, nur um eine AJAX-basierte Webanwendung zu haben.
In diesen Fällen, in denen AJAX mehr als Effekt denn als wirkliche Funktion eingesetzt wird, empfiehlt es sich, den Einsatz nochmals gründlich zu überdenken und der Sicherheit zuliebe gegebenenfalls auf einige Elemente zu verzich-
ten – auch wenn die Webanwendung dann vielleicht nicht ganz so schick aussieht.

JavaScript einschleusen