Bundesamt für Sicherheit in der Informationstechnik

Java-Applets

Java wurde von der Firma Sun Microsystems entwickelt und 1995 als neue, objektorientierte und plattformunabhängige Programmiersprache vorgestellt. Der Begriff Applet kommt vom englischen „application snippet“ und bedeutet soviel wie Anwendungsschnipsel. Java-Applets sind in Java geschriebene und vorkompilierte Programm-Module (Anwendungsschnipsel), die als Aktiver Inhalt in eine Webseite eingebunden werden können.

Java-Applets bringen die für Java typische Eigenschaft der Plattformunabhängigkeit mit sich. Die lauffähigen Programm-Module werden dafür in zwei Stufen erstellt. Der Entwickler lässt zunächst die Module von entsprechenden Softwarewerkzeugen in einen Bytecode vorkompilieren. In der zweiten Stufe durchlaufen sie beim Anwender die Java Virtual Machine (JVM). Das ist eine auf die Plattform angepasste Laufzeitumgebung, die den Bytecode interpretiert und ausführt. So kann ein und derselbe Bytecode auf unterschiedlichen Plattformen ausgeführt werden.

Für lokale Java-Anwendungen wurden Java Virtual Machines in alle gängigen Betriebssysteme integriert. Damit die in HTML-Seiten eingebundenen Java-Applets gleichermaßen ausgeführt werden, ist auch in den gängigen Browsern eine solche Java Virtual Machine vorhanden.

Die Java-Applets werden im HTML-Code als so genannte Objekte eingefügt. Hierbei wird angegeben, woher das Java-Applet geladen werden soll. Da die Applets immer einen definierten Bereich auf der dargestellten Seite benötigen, muss beim Aufruf außerdem die Höhe und Breite des Bereichs festgelegt werden.

Die Aufgabengebiete sind sehr unterschiedlich. So können Java-Applets

  • Film- und Animationssequenzen enthalten,
  • Nachrichten und Börsenmeldungen als eine bewegte Laufleiste darstellen oder auch
  • Interaktionen mit dem Anwender ermöglichen.

Häufig kommen Java-Applets auch bei webbasierten Systemen wie Online-Banking und Online-Brokerage zum Einsatz. Aber auch zu Lehrzwecken kann diese Technologie beispielsweise in Form von Weblehrgängen genutzt werden.

Java-Applets-Sicherheitsmodell

Ein zentraler Bestandteil der Programmiersprache Java ist ihre Sicherheitsarchitektur. Für die aus dem Internet geladenen Java-Applets wurde festgelegt, dass sie per Definition nicht vertrauenswürdig sind. Sie laufen deshalb in einer abgesicherten Umgebung (Sandbox).

Der so genannte "Security Manager" muss in jedes ausführbare Applet eingebunden werden und sorgt dafür, dass die Applet-Funktionen auf diesen Bereich beschränkt bleiben und lokale Dateien weder gelesen noch bearbeitet werden können. Java-Applets dürfen nur zu dem Rechner, von dem sie geladen worden sind, Netzwerkverbindungen herstellen. Es ist Java-Applets untersagt, lokale Anwendungen zu starten oder dynamische Bibliotheken (DLLs) zu laden.

Auch der Umgang mit Klassen hat unter Java eine besondere Bedeutung. Wie in jeder objektorientierten Programmiersprache können vordefinierte Klassen im Programm eingesetzt, sowie zusätzliche Klassen zur Verwendung in anderen Programmen definiert werden. Um anderen Entwicklern eigene Klassen zur Verfügung zu stellen, können nichtlauffähige Applets mit einer Sammlung der einzelnen Klassen erstellt werden, die dann von anderen Applets oder Java-Programmen aufgerufen werden können. Die in Bytecode übersetzten Klassen und die ausführbaren Applets erkennt man an der Datei-Endung „*.class“. Mehrere dieser Dateien können als Archiv mit der Endung „*.jar“ oder „*.cab“ komprimiert zusammengefasst werden. Durch die Komprimierung in Archiven wird erreicht, dass die Applets schneller geladen werden können.

Der in die Laufzeitumgebung integrierte Classloader hat die Aufgabe, Java-Klassen in die JVM zu laden. Das Sicherheitsmerkmal ist, dass der Classloader unterscheidet, ob lokal auf dem Rechner vorhandene oder aus dem Internet bezogene Klassen geladen werden. Sobald ein Java-Applet aus dem Internet geladen wird, sorgt der Classloader dafür, dass die Klassen und ihre Funktionen auf einen festgelegten Namensraum begrenzt werden. Hierdurch wird eine eingeschränkte Ausführungsumgebung gesichert. Auch für diese Einschränkung wird der oben beschriebene Security Manager eingesetzt.

Vor Ausführung der Applet-Klassen durchlaufen sie eine Bytecode-Prüfung. Es wird geprüft, ob die Klassen der Java-Spezifikation genügen und ob die Restriktionen des Namensraums eingehalten werden. Es soll unter anderem sichergestellt werden, dass der Java-Bytecode kein Über– oder Unterlaufen des Speichers verursacht.

Signierte Applets

Mit der Java Version 1.2 wurden zusätzliche Funktionen zur Zugriffskontrolle eingeführt. Diese ermöglichen, dass digital signierten Applets mehr Rechte eingeräumt werden, als in der reinen Sandbox-Umgebung möglich sind.

Mit der digitalen Signatur unterschreibt der Entwickler, dass das Applet von ihm entwickelt wurde. Dies soll eine Vertrauensbeziehung zwischen ihm und dem Anwender herstellen. Letzterer entscheidet anhand der Signatur und den Informationen zum Entwickler, ob er dem Applet mehr Rechte auf seinem Rechner einräumt.

Damit ein Java-Applet digital signiert werden kann, benötigt der Entwickler ein Zertifikat. Das Zertifikat kann bei einem Zertifikatsaussteller erworben werden. Es enthält Signaturprüfdaten, die Aufschluss über den Inhaber des Zertifikats (hier: den Entwickler) geben, sowie eine digitale Signatur der Zertifizierungsstelle. Letztere ist die Unterschrift der Zertifizierungsstelle und stellt sicher, dass das Zertifikat echt ist.

Mit diesem Zertifikat werden vom Entwickler die entwickelten Java-Applets signiert und in ein Archiv gepackt. Das Archiv wird auf dem Webserver des Anbieters abgelegt und in einer HTML-Seite referenziert.

Fordert der Web-Browser des Anwenders eine solche HTML-Seite an, so wird zunächst die digitale Signatur des Archivs geprüft. Anschließend erscheint eine Meldung im Web-Browser, die die Signaturprüfdaten des Zertifikats anzeigt und erfragt, ob der Anwender dem Applet mehr Rechte erteilen will. Bestätigt der Anwender diese Meldung positiv, wird das digital signierte Java-Applet mit den entsprechend eingeforderten Rechten im Web-Browser ausgeführt. Es ist dem Entwickler dabei überlassen, ob er angibt, welche der möglichen erweiterten Rechte im Applet verwendet werden. Theoretisch möglich ist, dass ein signiertes Applet so viele Rechte wie eine lokal installierte Anwendung erhält.

Die endgültige Entscheidung, ob er den Entwickler für vertrauenswürdig hält, obliegt dem Anwender selber. In Unkenntnis der Programmierfähigkeit der Entwickler kann er diese Entscheidung allerdings meistens nur schwer treffen.

Ein weiteres Problem bei der digitalen Signatur von Java-Applets ist, dass die unterschiedlichen Browser unterschiedliche Zertifizierungsarten unterstützen. Für das Signieren der Applets im Internet Explorer wird momentan (bis Version 5.5) noch die von Microsoft entwickelte Authenticode-Technologie eingesetzt, die auch bei ActiveX-Controls angewendet wird. Sun und Microsoft haben sich jedoch inzwischen darauf geeinigt, zukünftig einheitliche Laufzeitumgebungen zu verwenden, so dass diese Unterschiede möglicherweise nicht mehr lange bestehen.

Gefahren und Risiken im Zusammenhang mit Java-Applets

Trotz der beschriebenen Sicherheitspolitik können Risiken für den Anwender nicht ausgeschlossen werden. Zunächst kann es zu Schwachstellen in der browserabhängigen Implementierung der Laufzeitumgebung kommen. Angreifer können durch Ausnutzung von Fehlern, die bei der Programmierung gemacht wurden, die Sicherheitsrestriktionen umgehen und Daten auf dem Rechner des Anwenders manipulieren.

Auch bei digital signierten Java-Applets gibt es Risiken für den Anwender. Die Entwickler können so genannte Testzertifikate erzeugen, um damit selbstgeschriebene Java-Applets zu signieren. Normalerweise werden mit diesen Zertifikaten Java-Applets auf einwandfreie Funktionalität getestet, bevor sie schließlich mit Zertifikaten von vertrauenswürdigen Zertifikatsausstellern signiert werden. Die Testzertifikate können jedoch von Angreifern zum Signieren von bösartigen Java-Applets (wie z. B. Trojanischen Pferden) missbraucht werden. Zwar erscheint im Web-Browser des Anwenders zunächst eine Warnmeldung beim Laden solcher Java-Applets. Ein unachtsamer Anwender sieht jedoch nicht den Unterschied oder liest den Text nicht so genau und klickt auf "Akzeptieren". Hierdurch werden dem Java-Applet erweiterte Zugriffsrechte auf die Daten des Anwenderrechners gegeben.

Eine weitere Gefahr geht vom Blockieren des Anwenderrechners durch Ressourcenüberlastung aus. Es können so genannte Endlosschleifen programmiert werden, die dazu führen, dass die Rechenkapazität des Prozessors vollständig belegt wird. Dadurch können Anwender auf andere Programme nicht mehr zugreifen. Oft hilft nur noch ein Neustart des lokalen Rechners. Ebenso können mit Java-Applets weitere Fenster generiert und angezeigt werden. Eine Überflutung des Bildschirms mit solchen Fenstern außerhalb des Web-Browsers führt zu Unübersichtlichkeit und Ablenkung von möglicherweise bösartigen Aktivitäten im Hintergrund. Durch das Wegklicken dieser Fenster kann unter Umständen auch ein Klick an einer falschen Stelle genügen, um ungewollt Schadprogramme auf den lokalen Rechner zu laden.

Java-Applets können neben den möglicherweise im HTTP-Header übertragenen Informationen wie Browser-Kennung, Betriebssystemversion oder die 2IP-Adresse des Internetanwenders auch Informationen über die eingesetzte Java Virtual Machine, (beispielsweise die Versionsnummer oder den Hersteller der Virtual Machine) auslesen. Diese Informationen können auf Anbieterseite verknüpft und von Angreifern zur Ausnutzung von Schwachstellen der entsprechenden Virtual Machines ausgenutzt werden.

Obige Ausführungen zeigen, dass durch die Verwendung von Aktiven Inhalten und den sich hierdurch bietenden Missbrauchsmöglichkeiten Gefährdungen für den lokalen Rechner und die darauf gespeicherten Informationen entstehen können.