Dreiecksbeziehungen

Der Großteil aller Angriffe auf E-Business-Anwendungen hat entweder den Webserver oder das nachgelagerte Backendsystem zum Ziel, typischerweise das Datenbank- oder das SAP-System. Bei solchen Angriffen handelt es sich um das Verunstalten von Webseiten („Website Defacement“) oder das Ausführen destruktiver SQL-Befehle durch das Datenbanksystem infolge bösartiger Benutzereingaben in ein Formularfeld der Webanwendung.

Anders bei Cross Site Scripting - abgekürzt: XSS; CSS war schon für Cascading Stylesheets vergeben. Das Opfer des Angreifers ist in diesem Fall nicht der Webserver oder das Backendsystem, sondern der ahnungslose Anwender, dessen Browser Scriptcode ausführt, den ihm ein Angreifer „unterjubelt“. Die Schwachstelle, die solche Angriffe erst möglich macht, liegt in der Webanwendung, auf die der Anwender zugreift und über die der Angreifer den Scriptcode zum Opfer transportiert. Aus dem Transport von Scriptcode über eine Website hinweg („across a site“) zum Opfer leitet sich übrigens die Bezeichnung Cross Site Scripting ab. XSS-Angriffe zielen fast immer darauf ab, Session-Cookies oder Anmeldeinformationen von anderen Benutzern der Webanwendung zu stehlen, um damit an benutzerbezogene Daten wie Kreditkarteninformationen zu gelangen. Dementsprechend sind und waren Anwendungen wie Online-Shops, Mitarbeiterportale oder Internet-Banking beliebte Ziele für XSS-Angriffe. Dass sogar Produkte von Sicherheitsanbietern anfällig für Cross Site Scripting sind, zeigen die in den vergangenen Monaten veröffentlichten Schwachstellen bei Symantec und Cyberguard.

Anhand eines einfachen webbasierten Gästebuchs lässt sich das Prinzip des Cross Site Scripting anschaulich verdeutlichen. Der Angreifer verfasst einen neuen Gästebucheintrag und gibt neben dem eigentlichen Text den Scriptcode in die Eingabemaske ein. Als Scriptsprache verwendet er das von allen gängigen Browsern unterstützte JavaScript; prinzipiell kann der Code aber in allen Scriptsprachen, die der Opfer-Browser unterstützt, geschrieben sein. Ruft das Opfer nun den Eintrag des Angreifers auf, interpretiert der Browser den Scriptcode nicht als Text, sondern führt ihn aus. Lautet der Gästebucheintrag beispielsweise „Das ist XSS <script>alert(„XSS“)</script>“ zeigt der Opfer-Browser „Das ist XSS“ als Text an und führt anschließend den JavaScript-Befehl aus. In diesem Fall erschiene ein harmloses Popup-Fenster mit dem Inhalt „XSS“. Abbildung 1 veranschaulicht die Dreiecksbeziehung zwischen Angreifer, Opfer und Webanwendung.

Schlampereien des Programmierers

Eine XSS-Schwachstelle ist immer vorhanden, wenn zwei Bedingungen erfüllt sind. Erstens vergisst der Programmierer der Webanwendung, aus dem übermittelten Parameter (im vorliegenden Fall dem Gästebucheintrag) verdächtige Scriptbefehle unschädlich zu machen und zweitens gibt die Anwendung den Parameter auf einer anderen Webseite wieder aus. Letzteres ist bei einem solchen Programm naturgemäß der Fall - es ist ja gerade der Sinn und Zweck eines Gästebuchs, dass zuvor verfasste Einträge einsehbar sind. Neben Anwendungsbereichen wie Gästebücher oder Foren, bei denen Benutzereingaben permanent gespeichert werden, gibt es zahlreiche weitere Bereiche bei Webanwendungen, die Kandidaten für XSS-Schwachstellen sind. Hierzu gehören Suchmaschinen, die den Suchbegriff auf der Ergebnisseite wieder ausgeben („Ihre Suche nach XYZ ergab: ...“), Bestätigungsseiten nach dem Ausfüllen eines Formulars („Vielen Dank für Ihre Bestellung, Frau XYZ“) oder Fehlerseiten nach dem Aufruf einer ungültigen URL, die die betreffende URL nochmals ausgeben („Error: URL XYZ not found“).

Sind diese Bedingungen erfüllt, muss der Angreifer sein Opfer nur noch dazu bewegen, sich den Scriptcode vom Webserver herunterzuladen. Bei einem Gästebuch ist dies relativ einfach: Der Eintrag des Angreifers befindet sich in der Datenbank des Gästebuchs und wird jedes Mal abgerufen, wenn ein Anwender auf den Titel klickt, um sich den Eintrag anzusehen.

Erheblich schwieriger wird es schon, falls sich die XSS-Schwachstelle etwa in der Suchmaschine eines Online-Shops befindet, in der der Anwender nach Produkten sucht. Hier kann der Angreifer im Gegensatz zum Gästebuch den Scriptcode, den er als Suchbegriff eingibt, nicht zum Opfer transportieren. Im Gegenteil: Sein eigener Browser führte den Scriptcode aus, sobald er die Suchergebnisse anzeigt. Damit der Scriptcode auf Opferseite zur Ausführung kommt, müsste die Suchmaschine analog dem Gästebuchprinzip aus Abbildung 1 den Suchbegriff des Angreifers zwischenspeichern und ihn anschließend anderen Benutzern, den Opfern, anzeigen. Da derartige Suchmaschinen nicht existieren, muss sich der Angreifer eines Tricks bedienen: Er muss das Opfer dazu bringen, dass es den Suchbegriff mit dem bösen JavaScript-Code eigenhändig an die Suchmaschine übergibt. Nur in diesem Fall werden bei der Ausgabe der Suchergebnisse die im Suchbegriff enthaltenen Scriptbefehle wieder zur Opferseite transportiert und anschließend ausgeführt.

Die große Frage ist nun, wie der Angreifer seine Opfer, in diesem Fall die Besucher des Online-Shops, dazu überreden kann, in der Suchmaske bösartige Scriptbefehle einzugeben. Die Antwort ist verblüffend einfach und in Abbildung 2 illustriert: Es ist gar nicht erforderlich, dass das Opfer den Suchbegriff selbst eintippt. Stattdessen schickt der Angreifer seinen Opfern per E-Mail oder Instant Messaging einen Link auf die Suchanwendung, der den Suchbegriff schon enthält. Klickt das Opfer auf den Link, startet die Suche nach dem eingegeben Begriff. Jetzt ist es für das Opfer schon zu spät, denn bei der Anzeige der Suchergebnisse kommt der im Suchbegriff enthaltene Scriptcode zur Ausführung.

Den vollständigen Text finden Sie in der aktuellen Printausgabe -- außerdem eine Marktübersicht zu Content Security (hb)