Ajax und dessen Gefahren




Was ist Ajax?
Ajax ist eine Abkürzung und steht für „Asynchronous JavaScript and XML“. Das Besondere daran ist das kleine Wörtchen „asynchron“…

Das klassische (synchrone) Modell vom Internet-Surfen ist wie folgt: Man klickt einen Link oder sendet ein Formular ab. Der Server verarbeitet die http-Anfrage, sendet die Antwort und diese wird dem User angezeigt. Erst, wenn die Seite geladen ist, kann der Benutzer wieder interagieren, indem er wiederum einen Link klickt oder in dem Formular z.B. eine Suche detailierter beschreibt. Die Anfrage wird wiederum an den Server gesendet, von ihm verarbeitet und die Antwort wieder an den Client gesandt.

Man kann es mit folgendem Schaubild ganz gut erkennen:

Bild, URL: http://www.yubb.de/images/userbilder/1/ajax_1.jpg

Ajax hingegen schaltet eine Zwischenebene ein, nämlich die Ajaxengine, basierend auf JavaScript. Diese Engine nimmt die Anfragen vom Client an und leitet sie an den Server weiter. Während der die http-Anfrage bearbeitet und eine Antwort sendet, ist Ajax in der Lage, dem Client direkt eine Rückmeldung zu geben und so das Surfen nicht einzuschränken. Der Server sendet seine Antwort an die Engine und die ist, abhängig von der Serverantwort, in der Lage, diese Ausgabe in Abhängigkeit der Antwort zu modifizieren. Es findet folglich zwar eine Client-Server-Kommunikation statt, aber um eine Serverantwort zu erhalten, ist es nicht nötig, die Seite neu zu laden. Somit kann der User asynchron (und da ist das Zauberwort) zu den gestellten Anfragen weitersurfen, währenddessen die Anfrage im Hintergrund bearbeitet und dann ausgeliefert wird:

Bild, URL: http://www.yubb.de/images/userbilder/1/ajax_2.jpg

Nun, das mag nun ziemlich kompliziert klingen, nehmen wir uns ein Beispiel zur Hand. Und da fällt mir spontan Google ein.

Jeder von uns nutzt Google: Man gibt in die berühmte Suchbox einen Begriff ein und klickt auf „Suchen“. Es wird somit ein http-Request an den Server gesandt, der baut die Ergebnisseite zusammen, sendet sie an den Client und sie wird angezeigt. Das ist die synchrone Webkommunikation: Man muss warten, bis die Ergebnisseite ausgeliefert wurde, dann kann man weiter interagieren. GGf. hat man einen Tippfehler, dann merzt man den aus und klickt wieder „Suchen“. Das Prozedere geht von vorne los: Anfrage an Google-Server, Ergebnisseite zusammenbauen, an Client senden, anzeigen.

Im Gegensatz dazu arbeitet Google Suggest (http://www.google.com/webhp?complete=1&hl=en) mit Ajax: Mit jedem eingetippten Buchstaben wird eine Anfrage an den Google-Server gestellt und zu diesem String Vorschläge inkl. Menge der Suchergebnisse in einer kleinen Box anzeigt.

Nachteile von Ajax
Im Ajax-Code steht nicht, was zu tun ist („Gebe mir Suchergebnisse“), sondern wie es zu tun ist („Frage Google-Server nach Suchbegriffen, die mit „Hall“ anfangen“). Ajax ist ein JavaScript-Code. JavaScript wird auf dem Client ausgeführt und muss deswegen mit an den Client gesandt werden. Damit ist eine Sicherheitslücke ziemlich offensichtlich: Die Anweisungen zu Kommunikation mit dem Server werden mit an den Client gesandt und er kann in aller Ruhe sich den Quellcode anschauen und eventuelle Sicherheitslücken ausfindig machen. Häufig werden die an Ajax übergebenen Requests nicht ausreichend auf Validität geprüft, sodass auch schädlicher Code in die Ajax-Ebene eingeschleust werden kann. Ein weiterer, großer Nachteil ist, dass die http-Header von einem Ajax-Request sich nicht unterscheiden von einem durch einen Browser gesendeten http-Request.

Ajax kann durchaus für das versteckte Cross-Site-Scripting genutzt werden. Cross-Site-Scripting ist eine Methode von Angreifern, in einen für den User sicheren Bereich (z.B. Bankseite) durch JavaScript-Fehler eigenen Code einzuschleusen und Daten auslesen. Wer genaueres wissen möchte, kann sich drei Minuten Zeit nehmen und hier (http://www.heise.de/security/artikel/38658) XSS nachlesen.

Welche Auswirkungen kann das haben?
Wie gerade eben schon genannt, ist Ajax nur ein ganz normaler http-Request, von dem der User im Idealfall nichts mitbekommt. „Nur“? Nun, ein http-Request enthält neben der Anfrage an den Server, welche Seite angefordert werden soll, meist noch Daten von Sessions und Cookies. Diese werden mit übertragen. Somit ist es einem potentiellen Angreifer möglich, LogIn-Daten aus den Cookies auszulesen oder gar eine Browsersession zu übernehmen. Man stelle sich vor: Man ruft die Seite seiner eigenen Bank auf und gerät auf welchem Umständen auch immer auf eine XSS-präparierte Seite. Dem Angreifer ist es nun möglich, die Sessiondaten vom Onlinebanking auszulesen und mit diesen Daten Anfragen an den Server schicken. Anbetracht der Tatsache, dass der Server nicht zwischen Ajax-http-Requests und Browser-http-Requests unterscheiden kann, führt der Server die Anfrage aus. Je nach dem, wie das Script manipuliert wurde, sind die alle Grenzen aufgehoben. Alles, was der User klicken, bestätigen, absenden kann, kann Ajax im Hintergrund machen.

Unabhängig davon kann man Ajax-Keylogger laufen lassen, die Passwörter ausspionieren, oder sogar Ports scannen, um eine Attacke vorzubereiten.

Beispiel myspace.com
Hört sich ziemlich gefährlich an, was? Fast wie ein Virus, hm? Ja, und es gab auch schon Webviren:

Ziemlich bekannt wurde der Fall myspace.com: Man rief als Eingeloggter ein präpariertes Profil eines Users auf und infizierte sich bzw. sein Profil selber mit dem „Virus“. Auf einmal gehörte der User „Samy“ zu den eigenen Freunden und im eigenen Profil stand „Samy is my hero“. Zusätzlich wurde das eigene Profil infiziert, sodass sich der Virus nach dem Schneeballsystem verbreitete.

Dieser Virus war eine ziemlich ausgeklügelte Sache, gehen wir der Sache mal auf den Grund:

Dass der Ajax-Code erst eingeschleust werden konnte, war eine Sicherheitslücke bei myspace.com, die dafür sorgte, dass JavaScripte ungeprüft ins Profil eingepflegt werden konnten. Nun rief ein User das präparierte Profil auf und im Hintergrund, ohne dass der User es merkte, ging eine beachtliche Reihe von Anfragen los. Der Ajax-Code las die Logindaten und die Sessiondaten aus dem aktuellen http-Header des Users aus und sendete eine Anfrage an den Server, das Profil ändern zu dürfen. Da der Server keinen Unterschied zur Browser-Anfrage feststellen konnte und gültige Login- bzw. Sessiondaten erhielt, ließ er die Anfrage zu. Interessanterweise wird der User, wenn er normal sein Profil ändert, zusätzlich gefragt ala „Willst du dein Profil wirklich aktualisieren“ und die Antwort wurde durch einen md5-Hash validiert. Diesen Hash vermochte Ajax auszulesen und sendete Anfragen zum Freunde hinzufügen, zum Hinzufügen des Textes „Samy is my hero“ und zum Einschleusen des Ajax-Codes auf der Profilseite.

Bedenkt man nun noch, dass das sogar über mehrere Server möglich war (Profile liegen auf profiles.myspace.com, die Anfragen mussten aber an www.myspace.com gesendet werden), ist es abzusehen, welche Gefahr von Ajax ausgehen kann, wenn man eine schwach gesicherte Seite mit ausgeklügeltem Code infiltriert.

Aber was kann man tun?
Als User kann man wenig gegen solche Angriffe tun, da sind die Webcoder gefragt. Die einzige Möglichkeit besteht darin, JavaScript auszuschalten und ggf. für sichere Seiten freizuschalten. Aber es sind auch Fälle von Volksbank und Postbank bekannt, in denen deren Seiten mit XSS modifiziert wurden.

Aber was kann der Webcoder tun?

- Eine interessante Lösung hat Wikipedia gefunden, wo man unglaublich viele Einstellungsmöglichkeiten zum Designen hat, aber nur durch den speziellen Wikicode. So sorgt |Zelle1|Zelle2|Zelle3| für eine einzeilige, dreispaltige Tabelle. Davon abweichender Code wird nicht interpretiert und damit auch nicht ausgeführt.

- Zusätzlich sollte man sich fragen, ob es wirklich nötig ist, für die gewünschte Webanwendung Ajax zu nutzen. Möchte man Ajax nutzen, so sollte man die Ajax-Schicht möglichst schmal halten und auswertende Scripte auslagern. Somit wird gewährleistet, dass möglichst wenig Code an den Client übertragen wird und das, was übertragen wird, leitet die Anfrage nur an ein auswertendes Script weiter. Zusätzlich sollte man gerade bei Ajax penibelst auf Standards achten und sie einhalten. Die Standards sind ziemlich sicher und je mehr man Hacks und Workarounds einbaut, desto mehr Angriffsfläche bietet man einem potentiellen Angreifer.

- Zusätzlich empfiehlt es sich, jede Eingabe bzw. jeden Wert, der an die Ajax-Schicht gesendet wird, genau zu validieren: Eine Postleitzahl besteht aus Nummern und nicht aus Buchstaben; zusätzlich hat eine Postleitzahl fünf Ziffern. Somit weist man alles ab, was keine Zahlen enthält oder kürzer bzw. länger als fünf Ziffern ist.

Wenn man sich als Webcoder an diese Regeln hält, haben die Besucher der Seite durchaus Spaß an Ajax und dessen bequemen Vorzüge.

Ich hoffe, diese lange und doch nicht allumfassende Info hat euch etwas Klarheit in den Begriff „Ajax“ und dessen Vor- sowie Nachteile gebracht.

In diesem Sinne: Keep on coding.Geschrieben von Phil Marx am 18.02.2007 (43995x gelesen)
Diese News stammt von der Seite http://www.yubb.de
Sie ist unter http://www.yubb.de/artikel538.html direkt aufrufbar.

Jegliche Reproduktion dieser Seite oder ihrer Inhalte ist strengstens untersagt.