Java fördert nun signierte Applets

Inhaltsverzeichnis

Java kommt seit einigen Monaten nicht aus der Schusslinie. Die Sicherheitslöcher haben nicht nur Fachmedien ausführlich behandelt, sondern wurden sogar von der Populärpresse zu vielen Endanwendern gebracht. Oracle reagiert konsequent, aber vergleichsweise lautlos. Am 16. April 2013 ist Java 7 Update 21 mit der bisher weitreichendsten Änderung erschienen. Die Sicherheitseinstellungen erlauben dann das lautlose Ausführen unsignierter Applets nicht mehr.

Java-Applets sind mitverantwortlich für den Erfolg von Java. Bewegung im Browser war zu den Anfangszeiten des Internet ein absolutes Novum. Der anfängliche Hype ist lange vorbei. Selbst der zwischenzeitliche Marktführer, Flash, ist in der Verbreitung rückläufig. Dennoch ist das "write once run everywhere"-Paradigma weiterhin eine Hauptmotivation für die Verwendung von Java-Applets – allerdings nicht mehr im Multimedia-Bereich, sondern viel mehr im Umfeld professioneller Anwendungen.

Hier findet man hauptsächlich zwei Anwendungsfälle: die Anbindung spezieller Endgeräte wie Kartenleser und die Verteilung von Java-Clients im Web. Während Letzteres zunehmend eine Altlast in großen Unternehmen darstellt, sind die Client- und plattformunabhängige Anbindung von Hardware und auch die verschlüsselte Übertragung mit Zertifikaten brandaktuelle Anforderungen vieler Online-Angebote von Behörden. In Deutschland ist ein prominentes Beispiel das Elster-Steuerportal. Wer eine Steuererklärung machen will oder muss, ist zwangsläufig auf Java angewiesen. In anderen Ländern ist das nicht viel anders. Die hilflosen Empfehlungen, Java komplett vom Rechner zu entfernen, sind somit nur auf den ersten Blick eine Lösung. Die verschreckte Reaktion, die irgendwann einmal installierte Version gar nicht mehr anzufassen oder gar zu aktualisieren, stellt ein großes Sicherheitsrisiko dar. Die klare Empfehlung lautet also, die Java Runtime immer auf der aktuellen Version zu verwenden und die verfügbaren Sicherheitseinstellungen geeignet vorzunehmen.

Sicherheit einstellen

Mit dem Java 7 Update 10 wurden die nutzerspezifischen Sicherheitseinstellungen erstmalig ausgerollt. Damit war es möglich, nur Anwendungen auszuführen, deren Code mit dem Zertifikat von einer gültigen und vertrauenswürdigen Stelle (CA) signiert wurden. Mit Update 17 erweiterte Oracle das Java Control Panel um einen einfach zu bedienenden Schieberegler zur Einstellung des Sicherheitslevels nicht signierter Applets. Es lässt sich zwischen den Einstellungen niedrig, mittel, hoch und sehr hoch auswählen. Je niedriger die Sicherheitseinstellung, desto weniger Warnungen werden dem Anwender im Browser angezeigt. Er versteht sich also nicht als Einschränkung bezüglich der Fähigkeiten von Java im Browser generell, sondern hat lediglich Einfluss auf die Anzahl der Meldungen im Browser. Das ermöglicht den Endanwendern die schnelle und komfortable Einstellung der Sicherheitsmeldungen. Dieses Update hatte keinen Einfluss auf die bisherigen Anwendungen. Mit dem nun verfügbaren Update 21 ändert sich das. Oracle hat Anfang des Jahres angekündigt, dass sich das Verhalten des Browser-Plug-ins beim Umgang mit unsigniertem Code ändern wird.

Was sich lange Zeit schwammig angehört hatte und nur wenige in den konkreten Auswirkungen bewerten konnten, ist nun bekannt. Tatsächlich ändert sich die Möglichkeit zur Sicherheitseinstellung im Java Control Panel. Der Level "niedrig" steht nicht mehr zur Verfügung. Für Java im Browser bedeutet das, dass das Ausführen unsignierter Applets nicht mehr ohne Warnung für den Endanwender möglich ist. Im Rahmen der Änderung werden auch die Meldungen der Java Runtime beim Ausführen eingebetteter Inhalte präziser.

Was bedeutet das nun konkret?

Die Änderungen lassen sich am besten anhand von ein paar Beispielen illustrieren. Zu diesem Zweck wird ein einfaches Swing-Applet verwendet. Die Klasse public class AppletDemo extends Japplet überschreibt die init()-Methode und erstellt einen neuen GUI-Thread, der auf dem Container ein JLabel mit dem Text "You are successfully running a Swing applet!" hinzufügt. Neben der Java-Klasse gehört noch eine HTML-Seite dazu. Dabei gibt es diverse Möglichkeiten, Java-Applets in den Browser einzubetten. Die älteste ist die Variante unter Verwendung des <applet>-Tags. Er wurde mit HTML 4.1 als "deprecated" gekennzeichnet und lässt sich in HTML5 nicht mehr verwenden. An seine Stelle tritt der <object>-Tag. In HTML5 ist darüber hinaus der <embed>-Tag hinzugekommen. Um sich nicht mit den browserspezifischen Details herumärgern zu müssen, stellt Java das sogenannte Deployment Toolkit zur Verfügung. Das ermöglicht eine einfache und browserübergreifende Einbindung mit ein paar Zeilen JavaScript:

<script src="http://www.java.com/js/deployJava.js"></script>
            <script>
                var attributes = {
                    code:'appletdemo.AppletDemo.class', width: 300, 
                         height: 300};
                var parameters = {jnlp_href: 'applet_demo.jnlp'};
                deployJava.runApplet(attributes, parameters, '1.6');
            </script>

Für einen Entwickler sind die Schritte durchaus bekannt. Neben dem gezeigten Beispiel kann der JNLP-Mechanismus (Java Network Launching Protocol) auch Java-WebStart- oder JavaFX-Applikationen starten. Über die zugehörige Konfigurationsdatei (siehe die Sourcen) lassen sich zusätzliche Einstellungen wie Berechtigungen oder plattformspezifische Abhängigkeiten vornehmen. Egal auf welche Art das Java-Plug-in in die Webseite eingebunden und in welchem Browser diese dann läuft, wird der Code in einer sogenannten Sandbox ausgeführt. Die Fähigkeiten oder besser Berechtigungen für nicht signierten Sourcecode steuert der bekannte Java-Sicherheitsmechanismus mit policy-Dateien. Neben den globalen $JRE_HOME/lib/security/java.policy und $USER_HOME/.java.policy lassen sich für den Browser noch zwei weitere angeben. Das geschieht indirekt über eine Datei mit dem Namen deployment.properties (Details dazu finden sich hier). Diese Rechte definieren die Möglichkeiten, welche unsigniertem Code in der Sandbox zur Verfügung stehen.

Wer also aus einem unsignierten Applet heraus auf lokale Ressourcen wie das Dateisystem zugreifen möchte, wird mit einem unsignierten Applet schnell in einen entsprechenden Ausnahmefehler laufen. Der Versuch, ein neues File in d:\temp zu schreiben:

Path target = Paths.get("D:\\temp\\test.txt");
                    try {
                        Path file = Files.createFile(target);
                        created = true;
                    } catch (IOException ex) {
                        System.err.println("Creating file failed");
                        ex.printStackTrace(System.err);
                    }

führt beispielsweise zu:

java.security.AccessControlException: access denied
        ("java.io.FilePermission" "D:\temp\test.txt" "write")

Nicht einfach nur lästig, sondern funktionsverhindernd. Aber genau das soll ja die Sandbox ermöglichen: eine eingeschränkte und sichere Ausführungsumgebung, in der sich nicht auf böswillige Art auf bestimmte Informationen auf dem Client zugreifen lässt.