Als Ende der 80er Jahre am Genfer Kernforschungszentrum CERN das Konzept entstand, das einmal als World Wide Web das Internet salonfähig machen würde, dachte noch niemand an multimediale Inhalte. Doch das System fand Anklang auch außerhalb der wissenschaftlichen Bereiche, die Nachfrage stieg, und mit ihr stiegen die Ansprüche.

Die Einführung des Common Gateway Interface (CGI) machte es möglich, Web-Inhalte Server-seitig dynamisch zu generieren, die Anbindung an bereits bestehende Infrastrukturen zu realisieren und somit Aktualität zu gewährleisten. Gleichwohl war diese Interaktivität bestenfalls unzureichend.

Daten mußten grundsätzlich zum Server geschickt, ausgewertet, geprüft und das Ergebnis zum Anwender zurückgesendet werden. Diesen Mangel an "Eigenintelligenz" beheben die sogenannten aktiven Inhalte, in HTML eingebettete Programme, die den Verkehr zum Server auf ein Minimum reduzieren.

Die beiden bekanntesten Technologien, Java und Active X, arbeiten, trotz ihrer konzeptionellen Unterschiede prinzipiell auf derselben Basis: Eine HTML-Seite enthält einen Verweis auf eine Programmdatei; diese wird, wie jeder andere Content auch, vom Web-Server nachgeladen und kommt in einem Teilbereich des Browser-Fensters zur Ausführung.

Konventionelle Maßnahmen, wie zum Beispiel Firewalls, mit denen Intranets gegen etwaige Angriffe geschützt werden, gehen im Regelfall von der recht einseitigen Sichtweise aus, daß die Bedrohung von außen kommt. Amerikanische Untersuchungen zeigen hingegen, daß es einen prozentual hohen Anteil von Bedrohungen gibt, die ihren Ursprung innerhalb des Intranets haben.

Das Risiko, das sich hierbei durch aktive Inhalte ergibt, ist in erster Linie ein Anwenderproblem. Der große Vorteil des World Wide Web, die Navigation durch Hyperlinks, gerät zum Nachteil, wenn Benutzer sich unkontrolliert von Seite zu Seite klicken.

Im Zuge einer solchen Session können mitunter einige Dutzend Seiten besucht worden sein, deren exakter Inhalt nicht bekannt ist. Insbesondere die Existenz aktiver Inhalte und deren Funktionalität ist erst ersichtlich, wenn die Seite heruntergeladen ist. Zu diesem Zeitpunkt ist das betreffende Programm bereits zur Ausführung gekommen.

Für Administratoren ist dieser Zustand besonders unangenehm: Kommt es zu einem "Hostile Access" in das eigene Netz, ist der wahre Verursacher nur schwer auszumachen: Das Programm hat sich mittlerweile aus dem Browser entfernt und der Anwender durch das Anklicken weiterer Seiten die Spur unbewußt verwischt.

Die Betätigungsfelder für aktive Inhalte, die sich innerhalb eines Intranet theoretisch ergeben, sind vielfältig. Im Gegensatz zu konventionellen Attacken von außen bietet das Plazieren innerhalb des Intranet den Zugriff auf netzwerkweite Ressourcen. Das Grundprinzip des Intranet als Client-Server-Architektur und somit die Bereitstellung von Diensten im Netzwerk bieten die Basis für Zugriffe aller Art.

Neben den bekannten Denial-of-Service-Angriffen stellen vor allem Spionage und Sabotage ein hohes Risiko dar. Installierte Datenbanken sind ebenso direkt zugänglich wie interne FTP- und Web-Server, was das Ausspähen und sogar Manipulieren von Daten erheblich erleichtert. Grundsätzlich kann jede Ressource innerhalb des Intranet, seien es Netzwerkdienste oder Dateisysteme, betroffen sein.

Interessant ist auch der Zusammenhang mit sogenannter Spam-Mail: Hat das betreffende Programm die interne Adresse des Mail-Servers ermittelt, ist es in der Lage, Nachrichten in beinah beliebigen Mengen zu versenden. Daß deren Inhalt weder erwünscht noch im Sinne der jeweiligen Firmenpolitik sein muß, ist hinlänglich bekannt.

Es existieren prinzipiell zwei verschiedene Ansätze, um Anwender vor unliebsamen Angriffen zu schützen: vertrauensbasierte Maßnahmen ("Trust-based"-Verfahren) wie Vertrauenslisten und Zertifikate sowie laufzeitbasierte Verfahren (Sandboxing, Remote Execution).

Java und Active X verwenden trust-based Mechanismen, die auf einer schwarzweißen Weltanschauung basieren: Eine Quelle ist entweder vertrauenswürdig oder eben nicht. Wird sie als vertrauenswürdig erklärt, können Dokumente und Programme geladen und dem Anwender weitergereicht werden.

Als Quelle gilt per definitionem nicht nur eine bestimmte Herkunft - es werden vielmehr auch die Erzeuger berücksichtigt. Ein Programm wird also einem bestimmten Hersteller zugeordnet. Wenn dessen Authentizität geprüft ist, wird die Entscheidung getroffen, ob das Dokument als "trusted" einzustufen ist oder nicht.

Es existieren zwei unterschiedliche Realisierungen des Verfahrens: Listen mit vertrauenswürdigen Applets, Web-Seiten oder Controls einerseits und Zertifikate andererseits.

Im ersten Fall überprüft der Browser anhand vorher festgelegter Listen, ob das angeforderte Dokument aus einer als vertrauenswürdig eingestuften Quelle stammt. Ist dies nicht der Fall, wird das Dokument abgelehnt. Hierbei ist nicht nur die mögliche Unvollständigkeit, sondern auch die fehlende Aktualität und Flexibilität der Listen von Nachteil.

Beim Verfahren mit Zertifikaten erhält ein Produkt digitale Stempel, um die Authentizität und Integrität zu garantieren. Das heißt also, daß der Hersteller dem Anwender ein digitales Zertifi- kat zur Verfügung stellt, das einzigartig ist und in etwa einem Firmenstempel entspricht. Es enthält einen mittels asymmetrischer Verschlüsselungsverfahren generierten Public Key des Herstellers.

Werden die entsprechenden Daten und Programme nun signiert, ist der Browser des Anwenders in der Lage, die Signaturen des angeforderten Dokuments mit der des Zertifikats zu vergleichen. Bei Übereinstimmung ist die verlangte Vertrauensbasis hergestellt.

Inkompatible Zertifizierungssysteme

Ein Nachteil in der Praxis ist allerdings, daß die beiden großen Browser-Hersteller Netscape und Microsoft keine miteinander kompatiblen Signatur- und Zertifikatverfahren verwenden. Dadurch entsteht neben Mehrkosten auch unnötiger Zeitaufwand. Jedes Produkt, Dokument oder Programm muß in zwei Versionen zur Verfügung stehen, um die Anwender beider Browser bedienen zu können. Es sind zwei verschiedene Zertifikate nötig.

Vertrauensbasierte Verfahren besitzen einen weiteren, gravierenden Nachteil: Sie sagen nichts über den reellen Inhalt oder die Funktionalität aus. Daß ein Dokument als vertrauenswürdig klassifiziert ist, bedeutet nicht, daß es auch tatsächlich vollkommen harmlos ist. Dieser "Stempel" bestätigt lediglich seine Herkunft von einer Seite, die als "trusted" gilt.

Das Kriterium, das für eine entsprechende Klassifizierung als vertrauenswürdige Quelle herangezogen wird, ist nicht zuletzt ein rein subjektives und obliegt der Kontrolle des Anwenders. Besteht ein Programm, auf welche Art auch immer, den Vertrauenstest, kommt es zur Ausführung - mit allen damit verbundenen Konsequenzen. Ein Restrisiko bleibt somit in jedem Fall bestehen.

Kontrollmechanismen zur Laufzeit

Im Gegensatz zu vertrauensbasierten Mechanismen endet bei laufzeitbasierten Verfahren die Kontrolle nicht nach dem Ladeprozeß. Dem Java-Applet wird vor und während der Laufzeit ein spezieller Kontrollmechanismus auferlegt.

Auch hier gibt es zwei verschiedene Verfahren. Das bekanntere ist vermutlich das Sandbox-Modell: Hierbei wird das Programm in einem in sich geschlossenen Kontext - quasi in einem virtuellen Käfig - auf dem Zielrechner ausgeführt. Der Zugriff auf Ressourcen jeder Art unterliegt einer strikten Kontrolle. Der virtuelle Käfig koppelt sozusagen das Programm von der Außenwelt ab und reduziert das Risiko somit drastisch.

Der Nachteil dieser Methode liegt allerdings in der enormen Einschränkung, die die Funktionalität aller Programme, d.h. so auch der ungefährlichen, betrifft. Daher werden bei diesem Verfahren im Regelfall eine Reihe von Ausnahmen festgelegt, die entweder im System verankert sein können oder durch Kopplung mit vertrauensbasierten Mechanismen erfolgen.

Unterzieht man Active X und Java einem Vergleichstest hinsichtlich Sicherheit, werden die konzeptionellen Unterschiede deutlich. Microsoft hat mit Active X ein Container-Framework für aktive Inhalte geschaffen, das sich ausschließlich Trust-based-Verfahren verschrieben hat. Mittels konfigurierbarer Vertrauenslisten und Zertifikate läßt sich im Browser eine entsprechende Vertrauensbasis generieren. Da sich Active-X-Controls sowohl in Visual Basic und Java als auch in nativem C++ realisieren lassen, scheidet aus konzeptionellen Gründen ein Laufzeitverfahren zur Kontrolle aus.

Suns Java-Technologie verwendet als primäre Sicherheitsinstanz das Sandboxing, das für jedes Applet im Browser einen eigenen abgeschlossenen Kontext errichtet. Gingen ursprüngliche Versionen der beliebtesten Internet-Programmiersprache noch sehr strikt vor, so sind heutige und zukünftige Releases aus Gründen der Anwendbarkeit durch die Kombination mit Zertifikaten und Vertrauenslisten flexibler handhabbar.

Im Gegensatz zu Active X besitzen Java-Applets keinerlei direkten Zugriff auf Hardware oder Systemressourcen, was beispielsweise Denial-of-Service-Angriffe erschwert.

Unglücklicherweise hat die Auseinandersetzung zwischen den beiden Konkurrenten Microsoft und Sun dem Thema Sicherheit deutlich geschadet. So gestatten die von Microsoft entwickelten Java-Bibliotheken den direkten und ungehinderten Zugriff auf das Windows-API sowie die einfache Einbettung von C++-Code in Java-Applets. Damit leidet bei Applets, die speziell für die Windows-Plattform entwickelt wurden, nicht nur die Plattformunabhängigkeit, sondern auch die Sicherheit.

Eine einheitliche Sicherheitsarchitektur unter Microsofts Internet Explorer und Netscapes Navigator ist ebenfalls nicht vorhanden. Das hat zur Folge, daß sowohl Anwender als auch Entwickler dazu neigen, die uneinheitlichen Verfahren nicht zu berücksichtigen und eigentlich wichtige Sicherheitsmechanismen zu umgehen.

Als Ausweg hat Sun eine Lösung entwickelt, die - zumindest innerhalb der Browser - Konformität schafft. Dieses "Activator" genannte Plug-in für die gängigen Browser lenkt die Ausführung von Applets in Suns Referenzlaufzeitumgebung, um so ein einheitliches Laufzeitverhalten für Java-basierte Web-Inhalte zu schaffen. Der damit verbundene Nachteil allerdings besteht in der Abhängigkeit von Sun-spezifischen Merkmalen. So ist etwa der Zugriff auf die wesentlich schnellere virtuelle Maschine von Microsoft verwehrt.

Wie hoch ist die Gefahr wirklich? Stellt man das bestehende Risiko zum gegenwärtigen Zeitpunkt den existierenden Maßnahmen gegenüber, könnte man glauben, eine Panik sei unnötig. Tatsächlich sind keine Fälle bekannt, in denen Java-Applets oder Active-X-Controls größeren wirtschaftlichen Schaden angerichtet hätten.

Menschen überwinden Kontrollmechanismen

Daß dies nicht so bleiben wird, ist jedoch angesichts der weiter steigenden Verbreitung aktiver Web-Inhalte, insbesondere im Bereich E-Commerce und Intranet-Anwendungen, schon jetzt abzusehen. Vertrauensbasierte Mechanismen allein werden keinen Schutz bieten, solange menschliche Faktoren das vernünftige Maß an Vertrauen bestimmen.

Gerade Active X hat hier noch enormen Nachholbedarf, birgt es doch zusätzlich durch seine uneingeschränkten Zugriffsmöglichkeiten ein enormes Betätigungsfeld für unerwünschte Aktionen. Suns Activator und neue Mechanismen in der Version 1.2 des Java Development Kit bringen für Applets deutlich mehr Sicherheit - wobei zu wünschen bleibt, daß diese Verbesserungen rasch Eingang in die entsprechenden Produkte finden.

Ein paar Mausklicks öffnen alle Tore

Eine zentrale Administration der Sicherheitspolitik steht auf der Wunschliste ebenfalls ganz oben. In der Praxis ist keines der genannten Verfahren in der Lage, eine unternehmensweite Sicherheitspolitik auf einfache Weise zu etablieren. Schließlich nutzen die besten Sicherheitsmechanismen nichts, wenn sie der Anwender mit wenigen Mausklicks deaktivieren kann.

Allerdings ist auch der Anwender gefordert, seinen Beitrag zu leisten. Wer das entsprechende Bewußtsein hat, wird den einen oder anderen Klick auf einen Hyperlink wohl doch unterlassen und unnötige Datentransfers unbekannter und potentiell problematischer Inhalte vermeiden.

Ein Restrisiko läßt sich nur durch das Abtrennen des Rechners vom Netzwerk und durch sein Ausschalten gewährleisten. Somit ist das einzige, was wirklich zu 100 Prozent sicher ist, die Tatsache, daß es in einer mobilen Informationsgesellschaft keine hundertprozentige Sicherheit gibt. Zur Minimierung der Gefahren jedoch kann jeder seinen Beitrag leisten.

Angeklickt

Noch ein Klick auf noch einen Hyperlink. Der Anwender hat normalerweise keine Ahnung, was dabei alles aus dem Internet auf seinen Rechner gerät. Er verläßt sich felsenfest darauf, daß sein Browser nichts Übles durchgehen läßt, und ist davon so überzeugt, daß er nicht einmal die Sicherheitseinrichtungen aktiviert hat. Doch schon deren Arbeitsweisen sind sehr unterschiedlich. Der Autor vergleicht die Sicherheitsbedingungen von Microsofts Active-X-Ansatz und Suns Sandbox-Verfahren.

*Oliver Fels ist Projektleiter für Internet- und Java-Sicherheit bei der Neurotec Hochtechnologie GmbH in Friedrichshafen am Bodensee. Der Beitrag basiert auf einer für das Bundesamt für Sicherheit in der Informationstechnik (BSI) realisierten Sicherheitsstudie, die ococat.htm im Internet abrufen läßt.