Bundesamt für Sicherheit in der Informationstechnik

JavaScript/JScript

JavaScript wurde von der Firma Netscape entwickelt und im Jahr 1995 erstmals der Öffentlichkeit mit den Betaversionen des Web-Browsers Netscape Navigator 2.0 unter dem Namen LiveScript vorgestellt. LiveScript war eine an die Syntax der Programmiersprache Java angelegte Skriptsprache. Sie sollte es ermöglichen, Web-Inhalte interaktiv zu gestalten, und ergänzte statisches HTML um dynamische Bereiche. Noch vor dem endgültigen Release des Netscape Navigators 2.0 wurde die Skriptsprache in Zusammenarbeit mit der Firma Sun Microsystems – den Entwicklern von Java – in den öffentlichkeitswirksameren Namen JavaScript umbenannt.

Trotz der Namensähnlichkeit von JavaScript zu Java sind die beiden Sprachen vom Konzept her nicht vergleichbar. Java wurde als plattformunabhängige Programmiersprache mit eigenem Sicherheitskonzept für Netzwerkapplikationen entwickelt. Mit Java werden ausführbare Programme erstellt, die beim Benutzer nur im Bytecode vorliegen. JavaScript liegt sowohl beim Anbieter als auch beim Anwender im Textformat vor. Der Inhalt des Programms ist somit für jeden nachvollziehbar, der sich mit der Sprache auskennt.

Microsoft implementierte als Antwort auf JavaScript 1996 in der Version 3.0 des Internet Explorers eine fast identische, in gewissen Grenzen kompatible Skriptsprache namens JScript. JScript bietet dieselben Möglichkeiten wie JavaScript, wurde aber um spezifische auf den Internet Explorer und die Windows-Umgebung bezogene Funktionen erweitert.

Den auftretenden Schwierigkeiten der Browser, trotz der Unterschiede zwischen den Skriptsprachen alle Webseiten gleichermaßen gut darzustellen, begegnete Netscape mit dem Versuch, JavaScript zu standardisieren: Mit der European Computer Manufactoring Association (ECMA) wurde der auf JavaScript aufbauende ECMA-Skript-Standard erarbeitet. An den geschaffenen Standard mit dem Namen ECMA-262 halten sich inzwischen JavaScript und JScript weitestgehend. Dennoch gibt es feinere Unterschiede zwischen den beiden Sprachen, die es Browsern erschweren, alle HTML-Seiten, die JavaScript- bzw. JScript-Elemente enthalten, gleichermaßen richtig darzustellen.

Es gibt zwei verschiedene Arten, um JavaScript/JScript-Code in eine Webseite einzubinden. Zum einen kann der Skriptcode direkt in die Webseite eingefügt werden, zum anderen kann aus dem HTML-Code heraus der Skriptcode einer separaten JavaScript-/JScript-Datei aufgerufen werden. Um kenntlich zu machen, dass es sich um Skriptcode handelt, gibt es in HTML entsprechende Markierungen, so genannte Tags. Stößt der Browser bei der Abarbeitung auf ein Skript-Tag , wird zur Ausführung des Skriptcodes der für diese Skriptsprache zuständige Skript-Interpreter aufgerufen. Der Internet Explorer nutzt beispielsweise für die Interpretation und Ausführung von JScript-Code das Windows Skript-Modul JScript, welches u. a. ein Bestandteil der Windows Script-Umgebung ist. Andere Web-Browser unterstützen kein JScript und haben für die Ausführung von JavaScript ihre eigenen Skript-Module implementiert.

JavaScript/JScript Sicherheitsmodell

Um die möglichen Gefährdungen bei der Ausführung von JavaScript-Programmen eingrenzen zu können, wurden von Netscape verschiedene Sicherheitsmodelle entwickelt.

Same Origin Policy

Ein von einem Webserver geladenes JavaScript-Programm hat nur Zugriff auf Eigenschaften derjenigen Objekte, die vom selben Ort wie das JavaScript stammen. Damit soll ausgeschlossen werden, dass fragwürdige Webseiten Zugriff auf die Daten von anderen mit dem Browser geöffneten Dateien oder Webseiten erhält. In der JavaScript Version 1.1 wurde diese Richtlinie erstmals implementiert, in allen weiteren Versionen ist sie als Standard-Richtlinie eingestellt. Inzwischen haben alle gängigen Browser-Hersteller die "Same Origin Policy" implementiert.

Data Tainting

Mit "Data Tainting" konnte die "Same Origin Policy" gelockert werden. Es wurde die Möglichkeit geschaffen, auf Daten anderer Browser-Fenster zuzugreifen, auch wenn die Quelle nicht dieselbe ist. Hierfür musste die Grundeinstellung im Browser verändert werden. Um einen Missbrauch zu verhindern, können die Entwickler der Fenster einzelne Objekte als privat kennzeichnen ("tainting") und Zugriffe nur nach Rückfrage beim Anwender gestatten. "Data Tainting" wurde nur vom Netscape Navigator 3.0 (JavaScript 1.1) unterstützt, jedoch mit der Version 4.0 (JavaScript 1.2) wieder abgeschafft und durch die "Signed Script Policy" ersetzt. Alle anderen gängigen Browser haben "Data Tainting" nie unterstützt.

Signed Script Policy

Seit der JavaScript Version 1.2 gibt es die "Signed Script Policy", die auf dem Java-Sicherheitsmodell für digital signierte Objekte basiert. Entwickler können ihren Skriptcode digital signieren lassen, um damit mehr Zugriffsrechte auf dem lokalen Anwenderrechner zu bekommen. Eine digitale Signatur identifiziert den Entwickler und stellt sicher, dass der Skriptcode nach dem Signieren nicht verfälscht wurde. Wenn digital signierter JavaScript-Code mit einer Webseite heruntergeladen wird, erscheint im Web-Browser ein Fenster, wonach der Anwender entscheiden kann, ob er diesem JavaScript-Code zusätzliche Zugriffsrechte einräumen möchte. Microsoft verfolgt für JScript in der Version 5.6 ähnliche Ansätze wie die "Signed Script Policy". Entwickler haben die Möglichkeit, JScript-Code digital signieren zu lassen, um unberechtigte Veränderungen am Code nach der Signatur zu verhindern. Anwender können zudem die Echtheit der digitalen Signatur von JScript-Code überprüfen, bevor es zur Ausführung kommt.

Gefahren und Risiken im Umgang mit JavaScript/JScript

Es sind verschiedene sicherheitsrelevante Schwachstellen bekannt, durch die bei Ausführung von JScript/JavaScript-Code Schäden auf dem Anwenderrechner entstehen können.

Relativ harmlos ist die missbräuchliche Verwendung einiger JScript/JavaScript-Funktionen, durch die "nur" der normale Rechnerbetrieb des Anwenders gestört wird. Es ist beispielsweise möglich, unzählig oft weitere Fenster zu öffnen und damit eine Art Denial-Of-Service-Angriff auf den Anwenderrechner zu verursachen. Die geöffneten Fenster binden Rechner-Ressourcen und zwingen den Anwender, diese Fenster entweder zu schließen oder den Rechner neu zu starten.

Auch in die harmlosere Kategorie fällt das Problem, dass sich Programmierfehler erst zur Laufzeit auf dem Rechner des Anwenders auswirken. Da nicht sichergestellt ist, dass der Programmierer sein Skript mit allen Browservarianten getestet hat, unterstützt der verwendete Browser möglicherweise nicht alle Konstrukte und kann abstürzen.

Doch es gibt auch kritische Schwachstellen. Ein solches Sicherheitsrisiko kann vom JScript/JavaScript-Interpreter selbst ausgehen. Ist dieser fehlerhaft programmiert, entstehen Sicherheitslücken, die Angreifer ausnutzen können. Im schlimmsten Fall erhält ein Außenstehender vollständigen Zugriff auf den Rechner.

Ebenfalls kritisch sind einige Möglichkeiten, mit JScript/JavaScript-Elementen den Anwender zu täuschen. So können ganze Eingabefenster von vertrauenswürdigen Webseiten simuliert werden, wodurch beispielsweise Benutzernamen, Passwort oder andere sensible Daten wie Kreditkarteninformationen abgefangen und übertragen werden können.

Auch mit JavaScript/JScript möglich ist, die Anwender über das Ziel von Links zu täuschen. Über spezielle Funktionen kann die Statusleiste des Web-Browsers verändert werden, so dass die dort angezeigte Adresse nicht der der tatsächlich verlinkten Webseite entspricht.

Relativ gefährlich ist es, wenn sich der Anwender aufgrund eingesetzter Schutzprogramme in falscher Sicherheit wiegt. Es gibt beispielsweise Filter-Programme, die an Firewall-Systemen eingesetzt werden können. Diese Filter-Programme haben spezielle Funktionen, um Skriptcode auf bösartige Funktionen zu untersuchen und bei Bedarf diesen heraus zu filtern. Unter JavaScript/JScript können jedoch durch Verschleierung entsprechender HTML-Tags mit JavaScript/JScript-Funktionen beispielsweise Java-Applets auf dem lokalen Rechner des Anwenders ausgeführt werden, auch wenn die Firewall die Applets eigentlich herausfiltern sollte.

Nachfolgend ein Beispiel für die Verschleierung von HTML-Tags:

document.write('<APP');
document.write('LET\n');
document.write('CODE=client.Main.class \n>');
document.write('CODEBASE=base \>');
document.write('ARCHIVE=clientapplet.jar \>');
document.write('</APPLET>') ;

Auch die Verwendung von Signaturen birgt Risiken, wenn ihre Sicherheitsfunktionen nicht richtig eingeschätzt werden. Der Anwender erhält zwar die Gewissheit, dass die JavaScript/JScript-Dateien unverändert sind. Bezüglich der Vertrauenswürdigkeit und der Kompetenz des Entwicklers werden jedoch durch die Signatur keine Anhaltspunkte gegeben. Auch wird keine Aussage zum Funktionsumfang der JavaScript/JScript-Dateien und der davon ausgehenden Gefahren getroffen.

Ein spezielles Risiko entsteht durch den Einsatz von JScript. Diese Variante der Skriptsprache JavaScript ermöglicht es beispielsweise ActiveX-Controls Link zu DefActiveX-Controls.doc aufzurufen, über die ein weitreichender Zugriff auf den Rechner des Anwenders möglich wird.