Einen Benutzer per JavaScript mit derart vielen Fenstern zu bombardieren, ist geradezu trivial, allerdings auch ziemlich ungefährlich.
Seit Mitte des Jahres der Internet Explorer 5.5 erschienen ist, hat allein der Bulgare Georgi Guninski [10] fünf schwerwiegende Fehler gefunden - drei davon waren JavaScript-Bugs, die einem Angreifer jeweils Zugang zu lokalen Dateien verschaffen konnten, sofern diesem der genaue Pfad dorthin bekannt ist. Auch bei Netscapes Communicator gab es Sicherheitsprobleme [11].
Interaktion mit den Benutzern - und sei es nur die Reaktion auf Mausbewegungen - ist für viele Autoren von Web-Dokumenten von Bedeutung, da sie dadurch die vorgestellten Informationen attraktiver präsentieren können. Sie befürchten, dass Besucher statisch präsentierte Informationen häufig als nicht ausreichend erachten. Interaktion mit dem Benutzer bedeutet jedoch auch das Ausführen von Code, der vom Web-Server des entfernten Systems auf das System des Benutzers geladen wird. Die Browser starten solche aktiven Inhalte oft automatisch, ohne den Benutzer über ihr Ablaufen zu informieren.
Seit über einem Jahr warnt das Bundesamt für Sicherheit in der Informationstechnik (BSI) vor dem Einsatz aktiver Inhalte und insbesondere auch vor JavaScript [12]. Besonders problematisch ist, dass viele WWW-Server heute ohne JavaScript nur noch eingeschränkt lesbar und oft nicht mehr navigierbar sind. Sicherheitsbewusste Internetnutzer werden so konsequent von Angeboten ausgesperrt - viele resignieren irgendwann. Dabei ist JavaScript auf der großen Mehrzahl der WWW-Server nicht notwendig und wird oft ausschließlich für optische Spielereien genutzt. Und gilt es nicht unnötige Risiken zu vermeiden? Diese WWW-Server könnten mit dem gleichen Funktionsumfang und Informationsangebot ohne JavaScript auskommen, nötigen aber ihre Besucher, aktive Inhalte zu benutzen. Das BSI empfiehlt deswegen den Betreibern von WWW-Servern dringend, vollständig auf JavaScript zu verzichten oder zumindest für sicherheitsbewusste Kunden Alternativangebote bereitzustellen, die ohne aktive Inhalte darstellbar sind.
Auch wenn hier hauptsächlich von aktiven Inhalten in Web-Browsern die Rede ist, gelten die nachfolgenden Punkte doch für alle Programme, die HTML-Dateien und darin eingebettete aktive Inhalte verarbeiten. Dieses sind insbesondere Mail- und News-Reader. Dort kommt erschwerend hinzu, dass die E-Mails oder News-Artikel zugestellt werden, ohne dass die Benutzer sie explizit anfordern. E-Mail ermöglicht sogar gezielte Attacken auf einen bestimmten Empfänger.
Die verbreitetsten Formen aktiver Inhalte sind Java und JavaScript. Java ist eine objektorientierte Programmiersprache, deren Objectcode plattformunabhängig ist. Die aktiven Inhalte bestehen hier aus Objectcode, der über die Attributwerte des einleitenden HTML-Steuercodes (Tag) lokalisiert, vom Browser heruntergeladen und danach ausgeführt wird.
JavaScript dagegen ist eine Skriptsprache, die meist direkt in HTML-Dokumenten eingebettet ist. Zwar lässt sich der Skriptcode auch, wie bei Java, aus externen Dokumenten laden; zur nahtlosen Einbindung werden jedoch meistens Codefragmente als Attribute in HTML-Tags eingefügt.
Es gibt auch Server-Side JavaScript, das ähnliche Aufgaben wie beispielsweise ASP (Active Server Pages) oder PHP (Hypertext Preprocessor) übernimmt. Da diese Skripte jedoch auf der Server-Seite ablaufen, erhält der Browser der Anwender keinen ausführbaren Code übermittelt. Die Problematik der lokalen Ausführung der aktiven Inhalte entfällt daher.
Die am meisten benutzten Implementierungen von JavaScript sind zurzeit wohl die von Microsofts Internet Explorer (MS IE) und diejenige des Netscape Communicators. Auch andere Browser, wie beispielsweise Opera unterstützen JavaScript. Bei diesen Implementierungen sind bislang aber - vermutlich wegen ihrer geringen Verbreitung - noch keine Sicherheitslücken öffentlich aufgedeckt worden.
JavaScript wurde ursprünglich von Netscape für den Netscape (NS) Communicator entwickelt und erstmalig im NS Communicator 2 eingesetzt; zurzeit aktuell ist Version 1.3 [1]. Der Internet Explorer besitzt eine Microsoft-spezifische Implementierung, genannt JScript; aktuell ist hier die Version 5.5. JScript ist Teil der Windows ActiveX-Scripting Architektur, welche auch VBScript (und andere) als zusätzliche Skriptsprachen unterstützt [2].
Ein internationaler Standard für JavaScript wurde als ECMA-262 verabschiedet und als ISO/IEC 16262 in die ISO-Standardisierungen übernommen. Der Standard beschreibt jedoch nur die Grammatik der Sprache [3, 4], und ist daher unvollständig bezüglich der Browsereinbindung. Er beschreibt keine Methoden zur Einbettung von JavaScript in HTML-Dokumente und lässt den Zugriff auf Objekte und Daten der verschiedenen Browser außer Acht. Allerdings hat das W3C-Konsortium mittlerweile einen Standard für das Document Object Modell (DOM) erstellt [5], welches eine vereinheitlichte Sicht auf die Elemente eines HTML-Dokumentes darstellt.
Sowohl Netscape als auch Microsoft unterstützen den Standard des W3C, allerdings führen beide auch wieder neue Erweiterungen ein, sodass nur dann ein plattformunabhängiges Ausführen von JavaScript möglich ist, wenn die Programmierer sich auf die Standardobjekte beschränken. Weiterhin ist die Event-Verarbeitung im NS Communicator und im MS IE unterschiedlich implementiert.
Während die Einbettung anderer aktiver Inhalte spezielle Tags erfordert, sind JavaScript-Codesequenzen nicht notwendigerweise an Tags gebunden, die ausschließlich oder vorwiegend als Träger aktiver Inhalte dienen. Die folgende Aufzählung zeigt einige Arten der Einbettung von JavaScript in HTML:
Will man aktive Inhalte aus HTML-Dokumenten herausfiltern, so bereiten die mit besonderen Tags gekennzeichneten Codesegmente kaum Schwierigkeiten. Es genügt, den ganzen Text einschließlich der klammernden Tags aus dem Datenstrom zu entfernen. Betroffene Tags sind beispielsweise <APPLET>, <EMBED>, <SCRIPT> oder <STYLE>.
Die nicht speziell gekennzeichneten aktiven Inhalte und vielfältigen Möglichkeiten, JavaScript in HTML einzubinden, sorgen indes für erhebliche Probleme. Letztlich muss ein Filter alle Attribute von Tags darauf hin untersuchen, ob sie JavaScript-Code enthalten oder auf eine externe Scriptdatei verweisen. Auch alle URLs müssen auf JavaScript geprüft werden.
Um alle möglichen JavaScript-Codefragmente zu lokalisieren, sollte eine Sicherheitssoftware zudem den HTML-Code zunächst in eine Normalform bringen: Erst durch das tatsächliche Auflösen aller HTML-Entities lässt sich beispielsweise eine JavaScript-Pseudo-URL der Form "jAvascript:" erkennen (das Entity "A" steht für "a").
Eine vollständige Filterung, die zudem noch performant ist, scheint daher fast unmöglich zu sein. Zudem müsste man ja neben Web-Zugriffen auch die Datenströme für News und E-Mails filtern, die zudem nicht der HTML-Syntax unterworfen sind.
In der Regel ist JavaScript nicht die einzige Möglichkeit für aktive Inhalte auf einem Computer. Durch die Interaktion mit anderen Komponenten ergeben sich neue Risiken. Die Implementierung von JavaScript im Communicator erlaubt Skripten beispielsweise den Zugriff auf Teile der Java-Virtual-Machine (VM). Der Zugriff erfolgt aus JavaScript über die vordefinierten Objekte "java", "netscape" und "sun", welche die Wurzeln der Java-Objekthierarchie darstellen. Umgekehrt ist auch Java-Applets der Aufruf von JavaScript-Code möglich, falls in dem Tag, welches das Java-Applet lädt, das Attribut "MAYSCRIPT" auftritt. Netscape implementiert diese Interaktion zwischen aktiven Komponenten über die "LiveConnect"-Schnittstelle. JavaScript hat außerdem auch Zugriff auf andere aktive Komponenten, etwa Plug-ins, sofern diese die Schnittstellen zu LiveConnect implementieren.
Im MS IE besitzen Skripte Zugriff auf die ActiveX-Komponenten. Diese können wiederum mittels der ActiveX-Scripting Architektur JavaScript (oder andere Skripte) ausführen. In der Vergangenheit gab es häufiger Sicherheitslücken durch "gefährliche" ActiveX-Komponenten, die Microsoft irrtümlich als "safe for scripting" markiert hatte. Über diesen Umweg erlangt JavaScript dann beispielsweise die Möglichkeit zum Festplattenzugriff.
JavaScript besitzt weitgehenden Zugriff auf interne Daten der Web-Browser. Es ist allerdings zu beachten, dass die im Browser aktivierten Sicherheitsmaßnahmen den Zugriff auf diese Ressourcen einschränken (sollten). Ressourcen im JavaScript-Zugriff sind:
Andere Ressourcen sind indirekt mittels anderer aktiver Komponenten (Java oder ActiveX) erreichbar. Zu diesen Ressourcen gehören:
Viele dieser Ressourcen enthalten sensitive Informationen und sollten nicht-vertrauenswürdigen Skripten unzugänglich sein. Alle Browser implementieren daher Zugriffskontrollmechanismen.
Der Netscape Communicator benutzt das Sicherheitsmodell von Java. Java und JavaScript laufen in einer "Sandbox", aus der heraus Zugriffe auf sensitive Informationen nicht erlaubt sind. Java besitzt eine Klasse "SecurityManager", die die Sandbox implementiert und den Zugriff auf Ressourcen kontrolliert. Aufbauend darauf existiert die erweiterte Klasse "Capabilitiy Classes". Signierte JavaScripts von entfernten Webservern können durch Aufruf der Java-Methode "netscape.security.PrivilegeManager.enablePrivilege(...)" eine Anfrage zur Freischaltung bestimmter Ressourcen stellen. Der Browser präsentiert daraufhin dem Benutzer eine Dialogbox, in der dieser die erwünschten Berechtigungen vergeben oder verwehren kann. Zudem lässt sich die Ausführung aktiver Inhalte gänzlich oder für Teilbereiche wie E-Mail und News abschalten.
Der Internet Explorer benutzt einen anderen Zugriffsschutz. Er teilt das gesamte Internet in verschiedene Sicherheitszonen ein. Für aktive Inhalte aus jeder Zone kann der Anwender Zugriffe auf Ressourcen und Aufrufe von ActiveX-Controls aktivieren, deaktivieren oder nur auf Nachfrage zulassen. Bei einer interaktiven Abfrage kann der Benutzer allerdings nicht erkennen, welche Zugriffe erfolgen sollen. Er erhält beispielsweise nur die Meldung, dass ein Skript ein ActiveX-Control aufrufen möchte, jedoch keine Information darüber, um welches ActiveX-Control es sich handelt oder welche Auswirkungen der Zugirff hätte. Diese Berechtigungen gelten für alle Arten ausführbarer Inhalte der Windows Scripting Architecture, so auch für VBScript. Ein Zusammenhang zur Sandbox von Java besteht nicht.
Bei der Umsetzung einer Sicherheitspolitik in einem LAN helfen die Benutzereinstellungen im Übrigen wenig, da sie sich nicht ohne weiteres zentral administrieren lassen. Normalerweise kann sie jeder Benutzer nach Belieben ändern. Eine Filterung aktiver Inhalte an zentraler Stelle, zum Beispiel im Firewall-System, könnte helfen. Allerdings ist eine solche Filterung wie bereits beschrieben vermutlich nicht in hinreichender Qualität durchführbar.
Die "puren" Sprachelemente von JavaScript sind so gewählt, dass sie keinen Zugriff auf sensitive Informationen besitzen. JavaScript kommt jedoch nicht ohne Laufzeitüberprüfungen aus. So muss die Browsersoftware beispielsweise die Zugriffsrechte eines Skriptes auf Inhalte eines anderen Browserfensters oder Frames zur Laufzeit prüfen. Das hat in der Vergangenheit des öfteren Angriffsmöglichkeiten eröffnet, bedingt durch Fehler in der Implementierung.
Weitere Angriffsflächen liefert die Möglichkeit zum Aufruf von mächtigeren Ausführungsumgebungen, wie Java oder ActiveX. Auch hier besteht die Möglichkeit, dass die Überprüfung des Zugriffsschutzes lückenhaft implementiert oder falsch eingestellt wurde und somit konkrete Angriffe (Exploits) möglich sind. Insbesondere ActiveX-Controls besitzen potenziell Zugriff auf (fast) alle Ressourcen des lokalen Rechners, sodass auch aus JScript eine weitgehende Beeinflussung des lokalen Systems möglich erscheint.
Die wohl einfachste Form eines Angriffs ist der Ressourcenverbrauch (Rechenzeit, Speicherplatz usw.). JavaScript stellt keine Möglichkeiten zur Verfügung, solche Denial-of-Service-Angriffe (DoS) einzuschränken. Eine leicht angreifbare Ressource sind Fenster des Windowmanagers, mit vergleichsweise harmlosen, aber für den Benutzer nervigen Konsequenzen. Es ist äußerst einfach, massenweise neue Fenster zu öffnen und dadurch das System zeitweise zu blockieren. Diese Angriffe kann man sehr häufig nur durch das Schließen des Browsers aus der Betriebssystemsteuerung heraus beenden.
Einen Benutzer per JavaScript mit derart vielen Fenstern zu
bombardieren, ist geradezu trivial, allerdings auch ziemlich
ungefährlich.
Ein Exploit, der das Zonenmodell des IE aushebeln kann, ist das Cross-Site-Scripting. Der Angriff beginnt damit, dass man eine Web-Seite von einem nicht-vertrauenswürdigen Server anfordert, von dem keine aktiven Inhalte akzeptiert werden müssen. In dieser Seite sind Links auf weithin als vertrauenswürdig angesehene Server (im folgenden Beispiel "example.com") eingebaut. Diese Links enthalten Skriptfragmente, etwa:
<A HREF="http://example.com/comment.cgi?mycomment=
<SCRIPT>alert("document.domain="+document.domain)</SCRIPT>
;"> Click here</A>
Folgt der Benutzer einem solchen Link, so wird die URL mit den Codefragmenten an den Server example.com übertragen. Ziel des Angriffs ist es, dass der vertrauenswürdige Server die Codefragmente wiederholt und an den Anwender zurückschickt. Das kann entweder durch Gästebuch-Einträge, Kommentarseiten oder ähnliches erfolgen, die keinen JavaScript-Code filtern, oder in Form einer Fehlermeldung - etwa als Antwort auf einen falschen cgi-Parameter oder die Anforderung einer nicht vorhandenen Seite (vgl. Screenshot). Manche Serversoftware baut die angeforderte fehlerhafte URL derart in die Rückmeldung ein, dass die Codefragmente aktiv bleiben. Wie auch immer: Hat der Anwender dem angesprochenen zweiten Server über das Zonenmodell die Ausführung von JavaScript gestattet, so interpretiert der Browser nun das - von der fremden Website in den Link oder das Gästebuch eingeschleuste - Codefragment, da es ja nun in einer Webseite von einem vertrauenswürdigen Server steht.
Je nach Serversoftware wiederholen Websites in Fehlermeldungen
JavaScript-Code in ausführbarer Weise. Damit lassen sich
"per Site"-Zugriffsbeschränkungen in Filtersystemen
oder dem Zonenmodell des Internet Explorers aushebeln.
Häufig basieren JavaScript-Exploits auf einer Verletzung der Cross Frame Security. Jede HTML-Seite kann die Anzeige lokaler Dateien in einem Frame oder neuen Fenster veranlassen. Hin und wieder versuchen Websites damit, unbedafte Anwender zu verunsichern, indem sie ihnen C:\AUTOEXEC.BAT oder andere Dateien, die üblicherweise an bekannter Stelle vorhanden sind, innerhalb der WWW-Seite anzeigen und behaupten, Zugriff darauf zu haben. Genau diesen Zugriff verhindert allerdings üblicherweise das DOM - die Informationen stehen nur dem lokalen Browser zur Verfügung. Immer wieder zeigen sich aber Lücken in diesem Zugriffsschutz: Dann kann JavaScript-Code einen solchen Frame mit einer lokalen Datei nicht nur dem Benutzer anzeigen lassen, sondern auch auf dessen Inhalte zugreifen. Damit steht einer Übermittlung an den Ursprungsserver des Codes nichts mehr im Wege. Sofern der Angreifer den Pfad zu einer solchen Datei kennt, kann er sie in einem praktisch unsichtbaren Frame öffnen und dann ihre Inhalte ausspionieren. Häufig bleiben solche Sicherheitslücken allerdings auf Text-, HTML- und ähnliche Dateien beschränkt, die der Browser von sich aus in einem "normalen" Fenster anzeigen kann.
Durch Verletzungen der Cross Frame Security können Websites
lokale Dateien ausspionieren, sofern der Pfad dorthin bekannt
ist.
Aufgrund der unzähligen Implementierungsfehler in der Absicherung aktiver Inhalte sollte man zumindest überall dort, wo sensitive Informationen verarbeitet oder gespeichert werden, aktive Inhalte abschalten. Noch besser ist es natürlich, Computer mit sensitiven Bereichen strikt vom Internet zu trennen.
Da ActiveX-Controls Zugriff auf alle lokalen Ressourcen besitzen, sollte man ActiveX und den Aufruf der Controls durch Active Scripting prinzipiell deaktivieren. Keinesfalls sollte JavaScript für E-Mail- und Newsreader aktiviert sein, da ansonsten unaufgefordert und unkontrolliert aktive Inhalte ausgeführt werden. E-Mails können sogar zielgerichtete Angriffe transportieren.
Falls auf aktive Inhalte beim Internetzugang nicht verzichtet werden kann, sollte man die Bereitstellung spezieller "Surf-Rechner" erwägen. Diese sollten aus Sicherheitsgründen vom Produktivnetz getrennt sein. Administratoren sollten die einschlägigen Informationsquellen (etwa [6-11]) aufmerksam verfolgen und regelmäßig die Sicherheitsupdates für Browser und Betriebssystem einspielen.
Dr. Roland Meister ist System Engineer bei 
GeNUA,
Gesellschaft für Netzwerk- und UNIX-Administration,
Kirchheim bei München
JavaScript
Documentation Microsoft Scripting Technologies Standard ECMA-262 ECMAScript Language
Specification Standard ECMA-290 ECMAScript Components
Specification Document
Object Model (DOM) Microsoft Technet Security CERT
Coordination Center www.securityfocus.com SANS
(System Administration, Networking and Security) Institute Georgi
Guninski Security Research Brown Orifice BSI warnt vor dem Einsatz von
JavaScript© SecuMedia-Verlags-GmbH, D-55205 Ingelheim,
KES 5/2000, Seite 24
