BesucherDu bist der
Besucher
1.
Einleitung
2. Bedrohungen
3. Problemanalyse und
Lösungsansätze
Java
ActiveX
JavaScript
Plug-ins, Attachments u. Zusatzprogramme
4. Organisatorische
Sicherheitsmaßnahmen
5.
Sicherheitsmaßnahmen bei Anwendungen
a) E-Mail
Programme
b)
Allgemein einstellbare Sicherheitsmaßnahmen bei Browsern
Internet Explorer
Netscape Browser
c)
Checkliste zur Browsereinstellung
d)
Zusatzprogramme und Tools
6. Zusammenfassung und Ausblick
Neben den in der Presse häufig genannten
Gefahren, die bei der Nutzung des Internet auftreten können (offene Übertragung
der Daten, Angriffe durch Hacker), sind neue Risiken und Gefahren entstanden,
die auch für jeden Internet-Surfer eine Beschäftigung mit dem Thema Sicherheit
unerläßlich machen.
Die Ursache für diese neuen Bedrohungen liegt in der Tatsache, daß nicht mehr
nur reine ASCII-Texte übertragen werden, die der Empfänger lediglich liest und
u. U. speichert. Vielmehr werden heutzutage eine Vielzahl von Daten übertragen,
die beim Empfänger aktiv Veränderungen am Zustand seines Systems vornehmen
können. Diese Veränderungen reichen vom einfachen Anzeigen speziell formatierter
Daten bis zum Löschen der gesamten Daten oder der Übertragung von Daten an einen
beliebigen Rechner im Internet. Man spricht daher auch von aktiven oder auch
ausführbaren Inhalten (executable content).
Weitere Ärgernisse bei der Nutzung des Internet entstehen durch vom Anwender in
der Regel unerwünschte Aktivitäten. Die Versendung von Massen-Emails mit
Werbebotschaften (Spamming), gefälschte Warnmeldungen über neue Computer-Viren (Hoaxes)
und die Sammlung von Daten über die Internet-Nutzung (Cookies) haben zwar nicht
direkt mit dem Problem Content Security zu tun, treten aber sehr viel häufiger
auf. Viele Server nutzen Cookies, um User, die die Seiten schon einmal besucht
haben, wiederzuerkennen und ihnen so ein speziell aufgearbeitetes Angebot machen
zu können. Andererseits können die Summe der Cookies auch einige Informationen
über die persönliche Internet-Nutzung enthalten, indem z. B. analysiert wird,
welche Seiten der User besucht hat.
Aktive Inhalte können auf drei verschiedene
Arten Schaden anrichten:
»
Zerstörung von Daten
(Verlust der Verfügbarkeit)
Daten (bei einigen Systemen sogar Firmware) können gelöscht oder auf andere
Weise unbrauchbar gemacht werden.
»
Übermittlung von Daten
(Verlust der Vertraulichkeit)
Programme, die Zugriff auf vertrauliche Daten des Anwenders haben (z.B.
Paßwörter oder Daten der letzten Einkommensteuererklärung), können diese über
bestehende Internet-Verbindungen direkt übertragen. Besteht keine Verbindung,
können die Daten auch an einem geheimen Ort gespeichert und zu einem späteren
Zeitpunkt übertragen werden.
»
Verändern von Daten
(Verlust der Integrität)
Die Infektion von Programmen durch einen Computer-Virus oder das Verändern von
Datenbankeinträgen sind Beispiele für eine Veränderung
von Daten, die durch aktive Inhalte initiiert werden können.
Programme mit unerwünschten Funktionen lassen sich in folgende Klassen einteilen:
Hierbei handelt es sich um Programme, die neben ihrer eigentlichen Funktion, die
dem Anwender bekannt ist, noch weitere Funktionen ausführen, von denen der
Anwender nichts weiß und deren Ausführung er im Regelfall auch nicht bemerkt.
Ein Spezialfall eines Trojanischen Pferdes ist eine logische Bombe. Hierbei
handelt es sich ebenso um ein Programm mit einer verdeckten Schadfunktion, die
aber in Abhängigkeit von äußeren Bedingungen gestartet wird (z.B. der Uhrzeit
oder dem Datum).
» Viren
Ein Computer-Virus ist eine nicht selbständige Programmroutine, die sich selbst
reproduziert und dadurch vom Anwender nicht kontrollierbare Manipulationen in
Systembereichen, an anderen Programmen oder deren Umgebung vornimmt.
Man unterscheidet im wesentlichen drei Arten von Viren:
die File-Viren,
die sich an eine Programmdatei anhängen und beim Start dieses Programms
ausgeführt werden,
die Boot-Viren, die im Boot-Sektor einer Diskette oder im Boot- oder
Partitions-Sektor einer Festplatte stehen und beim Starten (Booten) des Rechners
aktiv werden, und
die Makro-Viren,
die sich als Makros innerhalb von Office- oder anderen Dateien (z. B.
Postscript) befinden und beim Start der entsprechenden Programme ausgeführt
werden.
Viren lassen sich am leichtesten durch eine gewisse Vorsorge (z.B. nicht von
Diskette booten) und den Einsatz von Viren-Suchprogrammen abwehren. Das Internet
hat als wichtigste Verbreitungsquelle für Computer-Viren die Originaldatenträger
der Hersteller (z.B. CDs) abgelöst. Es existieren eine Reihe von WWW-Servern und
Newsgruppen, die zur Verbreitung genutzt werden.
Normale HTML-Seiten, die von einem WWW-Server zu einem Browser übertragen
werden, stellen nur ein sehr unflexibles Instrument dar, um ein dynamisches und
benutzerorientiertes Angebot zu bieten. Dies führte dazu, daß verschiedene
Mechanismen entwickelt wurden, die mit Hilfe von ausführbaren Programmcode beim
Nutzer eine nahezu unbegrenzte Funktionsvielfalt ermöglichen. Dies gilt sowohl
im positiven wie im negativen Sinne. Während früher Programme ausschließlich von
lokalen Medien wie CD-ROM oder Diskette installiert wurden, hat schon die
Möglichkeit des Downloads von Programmen aus Mailboxen eine wesentliche
Verschlechterung der Sicherheit gebracht. Erstmals war es leicht möglich,
Software aus vollkommen unbekannter Quelle zu installieren. Dies allerdings nur
für einen relativ kleinen Kreis von Anwendern. Die Tatsache, daß in naher
Zukunft große Teile des Internet-Angebots gar nicht oder nur mit Einschränkungen
ohne das Herunterladen und Ausführen von Programmen auf dem
lokalen
Rechner nutzbar sind, erweitert dieses Risiko auf einen sehr großen
Benutzerkreis.
Es lassen sich im wesentlichen drei völlig unterschiedliche Ansätze identifizieren, wie diese Risiken verringert werden können. Zwei davon basieren auf Mechanismen bzw. Verfahren, die von den Firmen, welche die jeweilige Technologie für aktive Inhalte entwickelt haben, vorgeschlagen bzw. angeboten werden. Hier ist auf der einen Seite die Firma SUN, die zusammen mit den Spezifikationen für die Programmiersprache Java ein umfangreiches Sicherheitsmodell vorgelegt hat. Es beruht darauf, daß die Zugriffsrechte des geladenen Java-Programms (Applets) auf die lokalen Ressourcen stark eingeschränkt sind. Auf der anderen Seite steht der Ansatz der Firma Microsoft, bei welchem der geladene Programmcode mit denselben umfangreichen Zugriffsrechten abläuft, die auch der Anwender hat, die Herkunft der Programme aber durch digitale Signaturen "nachprüfbar" ist. Der dritte Ansatz ist unabhängig von der Technologie und basiert auf der Filterung und ggf. der Überprüfung aktiver Inhalte, bevor sie auf dem Zielrechner zur Ausführung gelangen. Die verschiedenen Ansätze werden im folgenden genauer erläutert.
Java ist eine von der Firma SUN Anfang der 90er Jahre entwickelte Programmiersprache, die viele Eigenschaften von C++ übernommen (z.B. die Objektorientierung) hat. Sie ist jedoch wesentlich eingeschränkter in ihren Möglichkeiten, da Funktionen, die häufig zu Fehlern geführt haben (z.B. die Verwendung von Pointern) nicht möglich sind.
Abbildung 1: Integration eines Java-Applets in eine HTML-Seite
Der wesentliche Unterschied zwischen Java und
anderen Programmiersprachen ist, daß Java-Programme normalerweise zunächst nicht
in hardwareabhängigen Maschinencode übersetzt werden oder als Quelltext
interpretiert werden, sondern in einen plattformunabhängigen sogenannten
Bytecode.
Für jede Hardware gibt es ein spezielles Programm (die Java Virtual Machine, JVM),
die in der Lage ist, diesen Bytecode auszuführen. Vor der Ausführung durch die
JVM wird der Bytecode durch ein spezielles Programm, den sogenannten Java Class
Loader, in den Speicher des Computers geladen.
Normalerweise werden die vorkompilierten Java-Programme, sogenannte
Applets,
nachdem sie aus dem Internet geladen worden sind, von einer JVM innerhalb eines
Browsers interpretiert und ausgeführt. Hierzu werden die Java-Befehle mit Hilfe
eines eigens dafür eingeführten Tags in HTML-Seiten eingebunden. Dies ist in der
Abbildung 1 am Beispiel des Applets
"AppletKiller.class"
dargestellt. Beim Laden dieser HTML-Seite wird dieses Applet ausgeführt und
bewirkt, daß alle anderen Applets, die anschließend geladen werden, sofort
gelöscht werden.
Da die Netze, über die Java-Applets übertragen werden, in der Regel keinerlei
Schutz gegen Manipulationen der übertragenen Java-Applets bieten, wurden bereits
bei der Entwicklung von Java eine Reihe von Sicherheitsanforderungen definiert,
die dafür sorgen sollen, daß Java-Applets keinen Schaden auf dem Rechner
anrichten können, auf dem sie ausgeführt werden. Hierzu gehören:
» Kontrolle auf die Einhaltung der Grenzen bei verwendeten Array- oder
String-Variablen. Hierdurch wird eine der häufigsten Ursachen für Fehler in
Programmen (Buffer Overruns oder Speicherüberlauf) verhindert.
» Homogenität der verwendeten Sprach-Konstrukte auf allen unterstützten
Plattformen unabhängig vom verwendeten Prozessor.
» Keine Verwendung von Pointern.
» Keine Möglichkeit beliebiger Umwandlung von Datentypen wie zum Beispiel die
Umwandlung von Integer-Variablen in Pointer.
» Automatische Speicherverwaltung (Garbage Collector). Hierdurch wird erreicht,
daß nicht mehr benötigter Speicherbereich automatisch wieder freigegeben wird.
» Offenlegung der Spezifikationen und teilweise sogar des Quellcodes der
verwendeten Interpreter und Compiler.
Einige dieser Sicherheitsfunktionen werden bereits beim Übersetzen eines
Java-Programms vom Compiler übernommen. Dies ist aber alleine nicht ausreichend,
da es möglich wäre, Applets auch mit einem manipulierten Compiler zu übersetzen,
der keine Prüfungen vornimmt. Daher muß jedes Java-Applet, welches aus dem
Internet geladen wird, vor seiner Ausführung weitere Sicherheitsstufen
durchlaufen.
Die erste dieser Stufen wird von dem sogenannten
Bytecode-Verifer
durchgeführt. Dieser überprüft, ob das Applet vollständig geladen wurde und
nicht gegen einige wichtige Grundregeln, die jedes Java-Applet erfüllen muß,
verstößt. Sichergestellt wird beispielsweise, daß allen Variablen gültige Werte
übergeben werden.
Auf der zweiten Sicherheitsstufe sorgt der
Class-Loader
dafür, daß die Menge der Schnittstellen eingeschränkt ist, die von einem Applet
auf dem lokalen System verwendet werden können. Zusätzlich übernimmt der
Class-Loader die Aufgabe, dafür zu sorgen, daß keine ungeprüften Klassen
eingefügt und vorhandene Klassen nur in einem genau definierten Rahmen
überschrieben werden können.
Die dritte Sicherheitsstufe wird bei der Ausführung einer Klasse durch den
sogenannten
Security-Manager
bereitgestellt. Er kontrolliert, ob ein Zugriff auf sicherheitskritische
Ressourcen des Rechners, auf dem das Applet abläuft, gestattet ist oder nicht.
Der Security-Manager unterscheidet bei der Prüfung streng nach der Herkunft der
Klasse. Lokale können mehr Rechte erlangen als Klassen, die aus dem Internet
geladen worden sind. Durch diesen Mechanismus wird erreicht, daß Java-Applets
nur in einer eingeschränkten Umgebung mit eingeschränkten Rechten ablaufen, wo
sie normalerweise keinen Schaden anrichten können. So ist ihnen beispielsweise
der Zugriff auf Dateien oder auf fremde Speicherbereiche nicht möglich. Aufgrund
dieser Eigenschaften wird das Sicherheitskonzept auch als "Sandkasten" oder
"Sandbox"
bezeichnet.
Leider sind die Rechte, die ein spezieller Security-Manager (z.B. im Netscape
Navigator oder im Microsoft Internet Explorer) vergibt, nicht einheitlich
geregelt, sondern werden in Form von verschiedenen Sicherheitsrichtlinien von
den Herstellern der Browser vorgegeben. Insbesondere die Einführung von
signierten Applets mit deutlich erweiterten Rechten mit Hilfe der Java
Capabilities Class durch die Firma Netscape oder innerhalb des Java Development
Kits 1.2 von der Firma
SUN
stellt eine wesentliche Änderung und Aufweichung des herkömmlichen "Sandkastens"
dar. Es bleibt abzuwarten, wie lange es dauert, bis auch dieses Konzept durch
Fehler in der Programmierung überwunden werden kann.
Bei ActiveX handelt es sich um
eine Erweiterung der schon länger bekannten OLE-Technik (Object Linking and
Embedding), die z.B. auch beim Einfügen von Excel-Tabellen in Winword-Dokumente
verwendet wird. ActiveX ist also kein eigenständiges System, sondern ein Teil
der Microsoft-Betriebssysteme wie Windows 95 oder Windows NT. Ein
ActiveX-Control ist ein kleines Windows-Programm, das sich beispielsweise mit
Hilfe eines Web-Browsers ausführen läßt. Diese Controls können bereits auf dem
Rechner vorhanden sein, oder werden beim Aufruf einer Web-Seite automatisch
heruntergeladen.
ActiveX basiert auf der Möglichkeit, wiederverwendbare Softwarekomponenten in
binärer Form mit standardisierten Interfaces bereitzustellen, die von
verschiedenen Client-Programmen genutzt werden können. Diese Softwarekomponenten
müssen dem sogenannten COM-Standard (Component Object Model) entsprechen. Dabei
ist es völlig egal, in welcher Programmiersprache die Controls geschrieben
worden sind, es sind also ActiveX-Controls in Basic, C oder sogar Java denkbar.
ActiveX-Controls werden innerhalb einer HTML-Seite durch ein spezielles Tag
gekennzeichnet, das OBJECT-Tag. Das in Abbildung 2 dargestellte Listing zeigt
die Integration eines Diagramms, welches mittels eines ActiveX-Controls
manipuliert werden kann. Die mögliche Verknüpfung von ActiveX-Controls mit einer
Skriptsprache (Active Scripting) erschwert die Analyse der Funktionen (z. B. mit
welchen Parametern ein Control aufgerufen wird).
ActiveX-Controls können niemals eigenständig ablaufen, sondern benötigen immer
ein anderes Programm, den sogenannten ActiveX-Container, um geladen und dann
gestartet zu werden. Diese Aufgabe übernehmen z.B. Browser wie der Microsoft
Internet Explorer oder diverse Plug-ins, die für eine Vielzahl von anderen
Programmen geschrieben worden sind.
Aufgrund der engen Verflechtung der ActiveX-Controls mit dem Betriebssystem hat
das Control Zugriff auf alle Systemressourcen inkl. der lokal gespeicherten
Daten und Programme. Es ist also z.B. möglich, ein Control zu schreiben, welches
ein Überweisungsformular einer Home-Banking-Anwendung erstellt und beim nächsten
Kontakt mit der Bank verschickt. Auch ist es einem Control generell möglich, die
Sicherheitseinstellungen des Internet Explorers (ab Version 3.0) zu verändern.
<OBJECT ID="Zeichnung1"
WIDTH=400
HEIGHT=300
CLASSID="CLSID:61241E80-778C-11EF-93D5-0420AF49504B"
CODEBASE="MSChart.OCX" >
</OBJECT>
<OBJECT ID="X-Achse"
WIDTH=28
HEIGHT=300 CLASSID="CLSID:673FA7F0-EB4B-11CD-8320-08022B2F7F5B">
</OBJECT><p>
<OBJECT ID="Rotation"
WIDTH=400
HEIGHT=28 CLASSID="CLSID:673FF7F0-EC8B-21CD-8220-08002B3F4F5B">
</OBJECT>Abbildung 2: Beispiel für einen Aufruf eines ActiveX-Controls
Nachdem die Teile eines Controls geladen
worden sind, wird ein weiterer Systemdienst aktiviert, der Windows Trust
Verification Service (WTVS). Um nun sicherzustellen, daß dem Control ein
gewisses Maß an Vertrauen entgegengebracht werden kann, hat Microsoft drei
Forderungen aufgestellt, die von allen Entwicklern von Controls beachtet werden
müssen.
1. Der Programmierer bzw. die Softwarefirma muß seine bzw. ihre Identität
offenlegen.
2. Der Programmierer bzw. die Softwarefirma muß für den Anwender
vertrauenswürdig sein.
3. Das Control darf nach seiner Veröffentlichung (Zertifizierung) nicht mehr
verändert werden.
Die Forderungen 1 und 3 lassen sich durch die Benutzung einer digitalen Signatur
für das Control erreichen, viel problematischer ist der zur Erfüllung der
Forderung 2 notwendige Vertrauensbeweis.
Will ein Programmierer ein ActiveX-Control mit einer digitalen Signatur
versehen, so muß er sich an eine Zertifizierungsstelle (Certification Authority,
CA) wenden. Von dort bekommt er ein Zertifikat für seinen öffentlichen
Schlüssel. Mit Hilfe seines privaten Schlüssels erzeugt er nun eine digitale
Signatur für das von ihm erstellte Control und legt diese digitale Signatur
zusammen mit dem Control auf einem WWW-Server ab. Zusätzlich muß er
sicherstellen, daß kein Angreifer böswillige Manipulationen an dem Control und
der Signatur vornehmen kann. Hierzu ist es sinnvoll, die Signatur auf einem
anderen Server zum Abruf bereitzustellen. Dies kann z.B. ein Datenbankrechner
sein, der ausschließlich die Signaturen von Programmen verschiedener Hersteller
zum Download bereithält. Eine solche Funktionalität wäre z.B. als Dienstleistung
einer Zertifizierungsstelle denkbar.
Der potentielle Empfänger lädt das ActiveX-Control und die zugehörige digitale
Signatur auf seinen Rechner. Dort prüft der Browser zunächst anhand der ihm
bekannten Site-Zertifikate der Zertifizierungsstellen, ob das Zertifikat des
Programmierers gültig ist. Anschließend wird die digitale Signatur des Controls
geprüft. Ist auch diese gültig, wird das Control ausgeführt. Zur Überprüfung
werden asymetrische Verfahren verwendet, so daß die Kontrolschlüssel offen über
das Internet übertragen werden können.
Die geschilderte Methode der Quellenüberprüfung von Software wird von Microsoft
Authenticode
genannt. Das Hauptproblem bei der Anwendung der digitalen Signatur wird von
diesem Verfahren allerdings nicht gelöst, da es dem Anwender in der Regel nicht
möglich ist, eine Zertifizierungsstelle auszuwählen, der er ausreichend
Vertrauen entgegenbringt, um die digitale Signatur zu akzeptieren. Da die
Zertifizierung mit Kosten verbunden ist, wird ein Autor sein Control lediglich
von einer Zertifizierungsstelle signieren lassen.
JavaScript ist eine einfache
Programmiersprache, die von der Firma Netscape entwickelt worden ist, um die
Erzeugung von aktiven Inhalten in HTML-Seiten zu erleichtern. Obwohl der Name
eine enge Verwandtschaft zu Java andeuten könnte, haben die beiden Sprachen nur
wenig Gemeinsamkeiten. JavaScript ist nur eingeschränkt objektorientiert ("objektbasiert")
und wird innerhalb einer HTML-Seite an den Browser übertragen. Der Anfang eines
JavaScript Programms wird innerhalb einer HTML-Seite durch das Tag
<SCRIPT Language="JavaScript">
gekennzeichnet, das Ende entsprechend durch das
</SCRIPT>-Tag.
Da JavaScript für die Bearbeitung von HTML-Seiten entwickelt worden ist,
entsprechen die Objekte, mit denen JavaScript arbeitet, im wesentlichen den
einzelnen Komponenten einer WWW-Seite. Jedes dieser Objekte hat verschiedene
Eigenschaften und Methoden, mit denen diese Eigenschaften verändert werden
können.
In einem typischen JavaScript-Programm werden zunächst eine Reihe von Funktionen
definiert, die anschließend innerhalb des eigentlichen HTML-Codes aufgerufen
werden.
Um die Gefährdungen, die bei der Ausführung von JavaScript-Programmen entstehen,
beherrschen zu können, wurden von Netscape verschiedene Sicherheitsmodelle
entwickelt. Hierzu gehören die "Same Origin Policy", "Data Tainting" und die "Signed
Script Policy".
» Same Origin Policy
Bei diesem Sicherheitsmodell wird festgelegt, daß ein JavaScript-Programm,
welches von einer "Quelle" geladen worden ist, bestimmte Zugriffe auf Objekte
innerhalb des Browsers nicht ausführen darf. Die "Quelle" eines
JavaScript-Programms wird anhand der URL der HTML-Seite festgelegt, in der
dieses Programm enthalten ist.
» Data Tainting
Data Tainting ist eine Funktion des Navigators 3, die es ermöglicht, daß auf
Objekte eines Fensters von einem anderen Fenster aus zugegriffen werden kann,
und zwar unabhängig von der Quelle der Fenster. Im Navigator 4 ist diese nicht
implementiert worden. Um Mißbrauch zu verhindern, kann der Autor des Fensters,
auf dessen Objekte zugegriffen werden soll, verschiedene Objekte als privat
kennzeichnen ("tainting") und Zugriffe nur nach Rückfrage gestatten.
» Signed Script Policy
Die "Signed Script Policy" ist erst mit der Version 4 des Navigators eingeführt
worden. Sie basiert auf der im Zusammenhang mit Java eingeführten Möglichkeit,
Objekte digital signieren zu lassen, um so die Authentizität zu gewährleisten.
Ein signiertes JavaScript-Programm kann erweiterte Zugriffsrechte auf Ressourcen
des lokalen Rechners bekommen.
Es sind verschiedene Probleme bekannt, durch die ein JavaScript-Programm Schäden
verursachen kann. Hierzu gehört z.B. die Möglichkeit, beliebig viele Fenster mit
Meldungen (sogenannte Alert-Boxen) zu öffnen, also ein
Denial-of-Service-Angriff,
genauso wie die Möglichkeit, Eingabefenster zu simulieren und dadurch
Benutzernamen, Paßwort oder andere Authentisierungsinformationen abzufangen.
Durch ein entsprechendes JavaScript-Programm kann die Statuszeile eines Browsers
so verändert werden, daß nicht mehr die richtige URL eines Links angezeigt wird,
sondern eine beliebige andere.
Viele Dateien, die aus dem Internet geladen
werden können, liegen in einem Format vor, welches ein normaler Browser nicht
anzeigen kann. Hierzu gehören z.B. eine Reihe von Bildformaten oder Audiodaten.
Auch innerhalb von Emails lassen sich solche Daten als Anhänge (Attachments)
übertragen. Um diese Dateien anzeigen zu können, werden Zusatzprogramme
benötigt.
Helper-Applications sind
eigenständige Programme, die automatisch vom Browser oder vom Email-Client
gestartet werden. Ihre Auswahl geschieht anhand der Dateiendungen. Bei einer
Datei mit der Endung ".ps" wird also z.B. ein Programm zum Betrachten von
Postscript-Dateien gestartet. Helper-Applications sind eigenständige Anwendungen
mit einem eigenen Fenster und mit eigenen Ressourcen, d.h. insbesondere, daß
dieses Programm alle Berechtigungen hat, die auch jedes andere Programm dieses
Benutzers hätte. Einschränkungen, die innerhalb der Konfigurationsmöglichkeiten
des Browsers gemacht worden sind, werden nicht beachtet.
Plug-ins sind Programme, die so
ausgeführt werden, als wären sie ein Bestandteil des Browsers. Werden Plug-ins
neu installiert, so muß gleichzeitig eine Dateiendung und ein MIME-Typ angegeben
werden. Anhand dieser Daten erkennt der Browser dann zukünftig, welches Plug-in
gestartet werden muß.
Welche Zusatzprogramme gestartet werden, wird zum einen anhand der Dateiendung
festgelegt, zum anderen aber auch anhand des MIME-Typs.
MIME
steht für "Multipurpose Internet Mail Extensions". Es handelt sich um einen
Standard für den Versand von mehrteiligen, multimedialen oder Binär-Daten im
Internet [RFC 2045, RFC 2046]. Hierzu gehören Bilder, Audiodaten, Dateien von
Textverarbeitungsprogrammen, Programmdateien und sogar einfache Texte, bei denen
es darauf ankommt, daß ihr Format bei der Übertragung nicht verändert wird.
Unter Sicherheitsgesichtspunkten ist der MIME-Content-Type "Application"
kritisch. Er wird verwendet, um den Transport von Daten zu kennzeichnen, die von
Programmen ausgeführt werden können, die auf dem Rechner des Anwenders
installiert sind. Bei entsprechend konfigurierten Email-Programmen kann es sogar
geschehen, daß diese Programme automatisch gestartet werden, wenn eine Email
empfangen wird, die Daten mit dem MIME-Content-Type "Application" enthält.
Bei der Art der Daten gibt es keine Einschränkungen, es können genauso Programme
für interpretierte Programmiersprachen (BASIC) wie Shell-Scripte sein. Auch
Datenformate, bei denen auf den ersten Blick nicht zu vermuten ist, daß sie ein
Sicherheitsrisiko darstellen, können zu einer Bedrohung führen. Ein Beispiel
hierfür sind Texte im PostScript-Format.
Der automatische Start eines normalen PostScript-Interpreters birgt ein Reihe
von Gefährdungen, die durch spezielle PostScript-Befehle verursacht werden
können. Hierzu gehören die Befehle "deletefile",
"renamefile", "filenameforall" und "file".
So führt die Ausführung einer Email, welche die folgenden Zeilen enthält, zum
Löschen der angegebenen Datei mit dem Namen
DATEINAME.TXT:
Content-Type: application/postscript
Content-Description: löscht eine Datei
...
%!
(DATEINAME.TXT) deletefile quit
Auch im WWW können Daten dieser Art verschickt werden und stellen durch das
automatische Starten von Helper-Applications oder Plug-ins ein ähnlich hohes
Risiko dar.
Die gängigen Browser erlauben ein automatisches Update ohne Zutun des Benutzers aus dem Internet. Dabei kann jedoch natürlich nicht davon ausgegangen werden, daß die neuen Version fehlerfrei ist. Weiterhin besteht die Möglichkeit, daß Konfigurationen, die der Anwender ausgewählt hat, überschrieben werden. Da das Update über das Internet erfolgt, besteht weiterhin die Gefahr, daß ein Rechner die Identität des Update-Servers vortäuscht, und so böswilligen Code auf den lokalen Rechner schmuggelt (IP-Spoofing).
Eines der größten Probleme bei der Konzeption
einer Firewall
ist die Behandlung der Probleme, die durch die Übertragung ausführbarer Inhalte
zu den Rechnern im zu schützenden Netz entstehen. Hierunter fällt nicht nur die
Erkennung und Beseitigung von Computer-Viren, die verhältnismäßig einfach auch
auf den Rechnern der Anwender durchgeführt werden kann, sondern auch das viel
schwieriger zu lösende Problem der Erkennung von ActiveX-Controls, Java-Applets
oder Scripting-Programmen mit einer Schadfunktion. Für diese Bedrohungen
existieren zur Zeit keine brauchbaren Programme, die eine ähnlich wirksame
Erkennung ermöglichen, wie sie im Bereich der Computer-Viren möglich ist.
Die Größe der Gefährdung, die von aktiven Inhalten für die Rechner im zu
schützenden Netz ausgeht, läßt sich anhand des folgenden Beispiels darstellen.
Ein Java-Applet in einem Browser darf gemäß der Java-Spezifikationen eine
Netzverbindung zu dem Server aufbauen, von dem es geladen worden ist. Diese zur
Zeit noch recht wenig benutzte Möglichkeit ist eine zentrale Voraussetzung, wenn
Netzwerk-Computer (NC) oder ähnliches eingesetzt werden sollen, die auch ohne
spezielle Initiierung durch den Anwender Programmteile vom Server laden müssen.
Um diese Eigenschaft trotz der Verwendung eines Packet-Filters vollständig
unterstützen zu können, müssen sehr viel mehr Portnummern freigeschaltet werden,
oder es muß ein dynamischer Packet-Filter eingesetzt werden.
Proxy-Prozesse sind aufgrund ihres Aufbaus prinzipiell sehr gut dazu geeignet,
die übertragenen Nutzdaten zu analysieren. Wie in Abbildung 1 und Abbildung 2
dargestellt, werden die entsprechenden Programme über spezielle Tags innerhalb
einer HTML-Seite aufgerufen. Denkbar ist also die Lösung, alle Zeilen mit
entsprechenden Tags und die dazwischen liegenden Zeilen aus einer HTML-Seite zu
löschen oder sie durch Ausgabezeilen zu ersetzen, die dem Anwender einen Hinweis
geben, daß das gewünschte Java-Applet von der Firewall abgeblockt worden ist.
Das Problem bei dieser Vorgehensweise besteht darin, daß es nicht auf eine
einfache Weise möglich ist, alle HTML-Seiten und in diesen wiederum alle zu
löschenden Tags zu erkennen. So können, und dies wird heute schon vielfach
gemacht, HTML-Seiten als Inhalt einer Email übertragen werden. Intelligente
Email-Programme erkennen dies und starten automatisch einen Browser, der diese
HTML-Seite anzeigen kann und dann natürlich auch das Java-Applet bzw.
ActiveX-Control ausführt. Auch die Erkennung eines speziellen Tags innerhalb
einer HTML-Seite ist aufgrund der komplexen Möglichkeiten der aktuellen
HTML-Version nicht einfach.
Java erlaubt eine zweite Möglichkeit der Erkennung. Alle Java-Klassen-Dateien
beginnen mit den Hexadezimalzahlen CA, FE, BA und BE. Dieses
Merkmal kann ebenfalls zur Erkennung durch eine Firewall herangezogen werden.
Diese Methode hat den Nachteil, daß auch normale Dateien mit dieser Bytefolge
beginnen können und dann auch durch die Firewall geblockt würden. In Ergänzung
zu einem Filter, der die notwendigen Tags erkennt, ist aber eine wirkungsvolle
Kontrolle möglich. Leider werden Java-Applets nicht durchgängig als Datei mit
der Endung .class
verschickt. Statt dessen können auch komprimierte Dateien eingesetzt werden, die
z.B. die Endung
.jar
(Java-Archive) haben. Das bedeutet, daß ein Java-Filter auch alle von beliebigen
Browsern unterstützten Komprimierungsverfahren kennen und berücksichtigen muß.
Eine weitere Alternative, aktive Inhalte mit Schadfunktion zu erkennen, besteht
darin, ähnlich wie bei Programmen zur Abwehr von Computer-Viren, eine Datenbank
mit Signaturen anzulegen und jedes aus dem Internet geladene Programm mit diesen
Signaturen zu vergleichen. Entsprechende Hilfsprogramme existieren derzeit nur
in sehr eingeschränktem Maße.
Ein weiteres Problem bei der Entdeckung von aktiven Inhalten mit
Schadensfunktion besteht darin, daß diese in verschiedenen Formaten z.B.
innerhalb einer Email übertragen werden können. Komprimierte Dateien, Dateien in
speziellen Kodierungen (BINHEX, BASE64)
oder sogar verschlüsselte Daten müssen von dem Filter-Programm erkannt und
analysiert werden. Dabei ist es durchaus möglich, das mehrere dieser Schritte
nacheinander durchlaufen werden müssen und es bleibt das Risiko, daß eine
spezielle Darstellungsform als solche nicht erkannt wird und die Datei daher
nicht in eine Form gebracht wird, die für eine Suche nach Schadensfunktionen
geeignet ist. Auch muß für eine Suche zunächst die komplette Übertragung
abgewartet werden, bevor das Ergebnis der Suche zur Verfügung steht - der
Anwender wartet also u.U. lange ohne einen erkennbaren Fortschritt, um dann die
gewünschte Datei als ganzes zu bekommen. Außerdem erfordert die Entdeckung einer
a priori unbekannten Schadensfunktion eine vollständige semantische Analyse des
Maschinencodes. Eine solche Analyse ist mit heutigen Rechnern aus theoretischen
Gründen nicht durchführbar, allenfalls kann man nach dem Aufruf bestimmter
Systemresourcen fahnden.
Ein weiterer Ansatz zur Vermeidung von Risiken, die von aktiven Inhalten
ausgehen, besteht in der Verwendung eines sogenannten Quarantänerechners
(Gummizelle). Dieser steht vor der Firewall im unsicheren Bereich und wird dazu
benutzt, Anwenderprogramme ablaufen zu lassen, die so konfiguriert sind, daß die
graphischen Oberflächen durch die Firewall hindurch auf die Arbeitsplatzrechner
der Anwender geschickt werden. Ein Programm mit Schadfunktion kann dann
lediglich den Quarantänerechner schädigen. Ein Nachteil dieser Lösung ist aber,
daß keinerlei Daten dynamisch vom Internet auf die Rechner der Anwender geladen
werden können und damit jegliche Interaktivität verloren geht.
Ein speziell auf Java bezogener Ansatz für einen zentralen Filter basiert auf
der Ausnutzung der mit der Java-Version 1.2 etablierten Sicherheitsmechanismen.
Er ist an zwei Voraussetzungen geknüpft: Zum einen müssen das
Java-Sicherheitsmodell, die den Java-Bytecode kontrollierenden bzw.
interpretierenden Komponenten und die Java-Basisklassenbibliothek korrekt
implementiert sein. Außerdem muß die in sog. Policy-Dateien definierte
unternehmensweite Sicherheitspolitik (d.h. die Vereinigung der zentralen policy
mit den jeweiligen lokalen policies) korrekt sein. Unter diesen Voraussetzungen
kann 100%-pure-Java-Code keine der Sicherheitspolitik zuwiderlaufenden
Aktivitäten ausführen. Sichert man also durch entsprechende zentrale Maßnahmen
auf einem Proxy-Server im Intranet hinter der Firewall die Integrität der
Komponenten der virtuellen Maschine, der Basisklassenbibliothek und der
Policy-Dateien und filtert alle native-code enthaltenden Applets bzw.
Applikationen aus, kann man unerlaubte, die Sicherheitspolitik verletzende
Aktivitäten abwehren. Dies betrifft jedoch nicht sogenannte
denial-of-service-Angriffe, die über exzessive Auslastung von Speicher,
Videospeicher oder Prozessor laufen, da Zugriffe auf diese Resourcen jedem
Java-Programm erlaubt sein müssen. Hier muß der Filter auf eine Bytecode-Analyse
mit allen schon erwähnten Problemen zurückgreifen. Der wesentliche Vorteil
dieses Ansatzes ist, daß auch über andere Kanäle als HTML-Dokumente ins Intranet
gelangte Java-Applets bzw. -Applikationen kontrolliert werden. Produkte, die
diesen Ansatz realisieren, sind derzeit am Markt noch nicht verfügbar, jedoch
existieren im BSI Planungen für ein Projekt zu seiner Realisierung als in
Behördennetzen einsetzbares Tool.
Der große Vorteil eines zentralen Filters besteht darin, daß mit Hilfe
unterschiedlicher Mechanismen (Signatur-Datenbank, Digitale Signatur, Analyse)
eine einheitliche Sicherheitspolitik erreicht werden kann. Dennoch wird ein
großer Teil der Verantwortung für die Sicherheit des Netzes in die Hände der
Benutzer gelegt.
Die Ausführung aktiver Inhalte ist einerseits
mir großen Risiken und Gefahren verbunden auf der anderen Seite aber aufgrund
der wachsenden Verbreitung in vielen Bereichen unverzichtbar, so daß eine
Regelung für den Umgang unumgänglich ist. Ziel ist es dabei, aktive Inhalte
daran zu hindern:
» Schaden oder zeitweise Einschränkung der Verfügbarkeit des Rechners zu
verursachen
» den Rechner zu Angriffen auf weitere Rechner zu nutzen
» Daten innerhalb des Rechners oder des Netzes auszuspähen
Die sichere Kommunikation zwischen außen und innen ist meist durch eine
Firewall
bereits hinreichend gewährleistet. Diese Systeme schützen vor Angriffen von
außen. Durch die aktiven Inhalte können jedoch Angriffe quasi von innen
gestartet werden, so daß hier eine besondere Sensibilisierung der
Administratoren und Anwender notwendig erscheint.
Als primäre Maßnahme ist die konsequente Nutzung administrativer Möglichkeiten
wie das Schließen nicht benötigter Ports auf den Rechnern und die
Rechteverwaltung für den Zugriff auf Daten und Resourcen zu sehen. Der Einsatz
einer Authentisierung zur Nutzung von Datenbanken und anderen Diensten im
Intranet sollte selbstverständlich sein. Auch Client-Server-Dienste sind durch
aktive Inhalte prinzipiell mißbrauchbar; auf sie sollte demnach nach Möglichkeit
verzichtet werden. Das eigene Netz ist verstärkt auf Schwachstellen zu
untersuchen, beispielsweise mit den am Markt vorhandenen Netzwerkanalysetools.
Eine mögliche Schadfunktion ist bei aktiven Inhalten nicht ohne weiteres zu
erkennen, da sowohl ActiveX, als auch Java in (vor-)kompilierter Form vorliegen.
Da JavaScript hingegen eine Script-Sprache ist, ist hier eine Analyse des Codes
vor Ausführung zu empfehlen. ActiveX und Java unterscheiden sich wesentlich in
ihrem Sicherheitskonzept. ActiveX arbeitet vertrauensbasiert, es wird nur eine
Ausführung von Controls gestattet, die aus vertrauenswürdiger Quelle stammen.
Kommen sie jedoch zur Ausführung, haben sie alle Rechte des Anwenders. Welche
Quelle als vertrauenswürdig eingeschätzt wird, kann in der Konfiguration der
Browser eingestellt werden. Java-Applets hingegen besitzen nur eingeschränkte
Rechte: auf die meisten Resourcen ist ihnen kein Zugriff gestattet, sie laufen
lediglich in einer eingeschränkten Umgebung ("Sandbox").
Für interne Onlinedokumente und Programme sollte deren Authentizität durch
Signierung und Firmenzertifikate gewährleistet werden. Eigene aktive Inhalte im
Intranet sollten mit Java und nicht mit ActiveX oder JavaScript realisiert
werden. Da die Zertifizierungsmechanismen der verschiedenen Browser
unterschiedlich und nicht zueinander kompatibel sind, sind normalerweise zwei
verschiedene Zertifizierungsverfahren notwendig. Allerdings steht mit dem JAVA
Plug-in Paket der Firma Sun ein Ersatz für die integrierten Java
Laufzeitumgebung der Browser zur Verfügung, der durch den Plug-in-Mechanismus in
die gängigen Browser eingebunden werden kann. Dies hat den zusätzlichen Vorteil,
daß das Sicherheitskonzept dieser Laufzeitumgebung sehr gut dokumentiert ist.
Diese Laufzeitumgebung bietet auch die Möglichkeit, daß Sandbox-Verfahren durch
einen vertrauensbasierenden Ansatz (beispielsweise um Daten einer Datenbank
abzufragen) zu ergänzen.
Wegen der großen nur schwer zu kalkulierenden Sicherheitsrisiken sollte ActiveX
grundsätzlich nicht zum Einsatz kommen. Auch JavaScript sollte wegen der großen
Fehleranfälligkeit normalerweise nicht eingesetzt werden. Das Risiko bei reinem
Java ist durch die sogenannte "Sandbox" wesentlich geringer. Wenn man dem Applet
nicht manuell erweiterte Rechte zubilligt, können lediglich Fehler in der
Implementierung der Laufzeitumgebung des Browsers zu Zugriffen beispielsweise
auf Dateien oder Netzwerkadressen führen.
Besonders wichtig ist es, eine Regelung zu finden, wie der Zugriff auf aktive
Inhalte des Internets zu reglementieren ist. Denkbar sind hier drei Modelle:
1. ganz offen (keine Beschränkung, reine Eigenverantwortung des Anwenders)
2. ganz geschlossen
3. nur für bestimmte Gruppen offen
Die erste Möglichkeit beinhaltet ein hohes Sicherheitsrisiko, verursacht nicht
nur durch mangelndes Risikobewußtsein beim Anwender. Selbst bei der Wahl einer
sicheren Grundeinstellung und hinreichender Sensibilisierung und Schulung der
Anwender kann bei zeitweiser Benutzung aktiver Inhalte (beispielsweise für
Intranet-Dokumente oder die Benutzung der Online-Hilfe von Netscape) das
anschließende Abschalten vergessen werden. Auch kann nicht sichergestellt
werden, daß alle Anwender das mögliche Risiko richtig einschätzen. Sicher werden
viele Anwender mit der hiermit verbundenen hohen Mitverantwortung für die
Sicherheitspolitik überfordert sein. Der Vorteil dieses Modells liegt allerdings
darin, daß alle Anwender die Angebote des Internets ohne Einschränkungen nutzen
können. Von dieser Möglichkeit ist wegen der hohen Risiken jedoch abzuraten.
Möglichkeit Nummer zwei - alle aktiven Inhalte aus dem Internet werden
abgewiesen - schließt Risiken bei der Nutzung des WWW weitgehend aus. Allerdings
sind durch das starke Vordringen aktiver Inhalte im Internet immer mehr
Web-Seiten praktisch nicht mehr nutzbar. Da aktive Inhalte oder auch
eigenständige Programme auch durch Email (eventuell sogar verschlüsselt)
verschickt werden können, ist hier eine vollständige Ausfilterung aktiver
Inhalte nur schwer möglich, so daß zusätzlich ein entsprechendes Bewußtsein für
die Mitverantwortung bei den Anwendern geschaffen werden muß.
Die dritte Möglichkeit, die Nutzung aktiver Inhalte auf einen eingeschränkten
Kreis zu begrenzen, erscheint demnach am sinnvollsten. Bei diesen Anwendern muß,
beispielsweise durch entsprechende Schulungen, ein besonderes Risikobewußtsein
entwickelt werden. Weiterhin müssen klare Kriterien vorhanden sein, wie dieser
Kreis zu bestimmen ist. Durch weitere Sicherheitsvorkehrungen, beispielsweise
durch eine zusätzliche Authentisierung, kann ein Mißbrauch der erweiterten
Möglichkeiten durch Dritte unterbunden werden. Bestimmte bindende
Verhaltensmuster, z. B. das Verwenden des Passwort-Schutzes des
Bildschirmschoners oder das ausschließlich selektive Einschalten der aktiven
Inhalte, sind zu entwickeln und einzuhalten.
Um dem Vergessen des Abschaltens der aktiven Inhalte nach der Nutzung
vorzubeugen, sollte eine technische Lösung angestrebt werden. Dieses kann
beispielsweise durch die Software X-Ray-Vision geschehen oder auch durch ein
regelmäßiges Überschreiben der Konfiguration, beispielsweise beim Rechnerstart.
Damit die Nutzung von aktiven Inhalten im Intranet möglich bleibt, ist eine
Firewall notwendig, die die Übertragung aktiver Inhalte einerseits für die
normale Anwendergruppe aus dem Internet verhindert, für die Gruppe mit
besonderen Rechten andererseits aber zuläßt. So können die Browser der normalen
Anwender durchaus mit der Option der eingeschalteten aktiven Inhalte genutzt
werden, beispielsweise um aktive Inhalte im Intranet zu nutzen. Sinnvoll ist in
diesem Zusammenhang, auch den Download von ausführbaren Programmen und dynamisch
gelinkten Libraries zu reglementieren.
Eine Kontrolle über die installierten ActiveX-Controls, Plug-ins oder
Java-Applets muß für jeden Rechner regelmäßig erfolgen. Für ActiveX-Controls
steht hierfür das Programm XCavator zur Verfügung, das installierte Controls
auflistet und einzeln löschen kann. Über installierte Plug-ins informieren die
gängigen Browser in ihrer Hilfe-Funktion. Über Java-Applets, die mehr Rechte
benötigen, als ihr die Sandbox zugesteht, geben die aufgelisteten Zertifikate in
den Sicherheitseinstellungen der Browser Auskunft. Da die Vergabe besonderer
Rechte bei den Implementierungen der Java-Runtime-Enviroment in den einzelnen
Browsern unterschiedlich realisiert ist, sollte diese durch die der Firma Sun
ersetzt werden.
Problematisch ist die umständliche Administration hinsichtlich der
Sicherheitspolitik, die grundsätzlich an jedem Desktoprechner dezentral
konfiguriert werden muß und durch den Anwender mit wenigen Mausklicks außer
Kraft gesetzt werden kann. Wird eine automatische Rekonstruktion der sicheren
Grundeinstellung (s.o.) gewählt, ist dieser Punkt weniger problematisch.
Hauptquelle für Risiken durch ausführbare Inhalte in Web-Dokumenten ist der Anwender, denn die Applets oder Controls gelangen durch ihn auf den einzelnen Rechner. In diesem Abschnitt werden sicherheitsrelevante Einstellungen bei Mail-Programmen und WWW-Browsern vorgestellt, die vom Anwender ausgewählt werden müssen. Neben den Einstellungen, die direkt aktive Inhalte betreffen, werden auch die Wahlmöglichkeiten aus dem Bereich der Verschlüsselung vorgestellt, was beispielsweise bei Bankanwendungen im Internet von zentraler Bedeutung ist.
Beim Empfang von Email ist das sofortige Ausführen von Attachments ein Sicherheitsrisiko. Diese Attachments sind so zu behandeln, wie eine Datei oder ein Programm auf einer Diskette. Sie sind demnach auf Viren, Trojanische Pferde, Makro-Viren etc. zu untersuchen, so kann beispielsweise bei MS Outlook durch das Einstellen eines hohen Sicherheitsgrads (Extras - Optionen - Anlagen) das automatische Starten einer Anwendung abgestellt werden (Abb. 3).
Abbildung 3: Einstellung zu Attachements bei MS Outlook.
Neben der in WWW-Browsern fest
einprogrammierten Funktionalität (HTML, Java, JavaScript) können die gängigen
Browser durch Plug-ins oder ActiveX-Controls erweitert werden. Weiterhin können
auch externe Programme zur Darstellung bestimmter Dateien mit darin enthaltenen
Makros aufgerufen werden (z. B. Word für *.doc--Files) oder ausführbare
Programme nach dem Download direkt gestartet werden.
Plug-ins oder ActiveX-Controls, die separat zum Browser installiert werden
müssen, unterliegen grundsätzlich keinem Sicherheitsstandard, so daß bei einigen
Plug-ins und bei ActiveX-Controls eine Zertifizierung durch eine digitale
Signatur eingeführt wurde, die Auskunft über den Autor und die zertifizierende
Stelle gibt. Das Zertifikat kann bei der Installation des Controls oder des
Plug-ins mit den Daten der Zertifikataussteller, die dem Browser schon bekannt
sind oder die er sich aus dem Internet herunterladen kann, verglichen werden.
Der Anwender muß selbst entscheiden, welchen Zertifizierungsstellen er Vertrauen
entgegenbringt. Eine Garantie für ein fehlerfreies Programm, das keine
Schadfunktion enthält und auch nicht mißbraucht werden kann, wird damit
natürlich nicht gegeben, da das Zertifikat lediglich die Urheberschaft
beurkundet.
Die Möglichkeit zum Ausführen aktiver Inhalte kann bei allen Browsern
deaktiviert werden, da eine Ausführung ohne Kontrolle durch den Benutzer ein
Sicherheitsrisiko in sich birgt. Auch die Verwendung eines Proxy-Servers ist zu
empfehlen, die notwendigen Parameter sind vom Systemverwalter zu erfragen. Da
die Default-Einstellungen der beiden weitverbreitesten Browser Netscape
Communicator und Microsoft Internet Explorer je nach Release-Nummer und
Betriebssystem unterschiedlich sein können, müssen die Einstellungen stets
kontrolliert werden.
Für die beiden marktgängigsten Browser, den Netscape Communicator und dem
Microsoft Internet Explorer, werden die Einstellungen kurz erläutert. Bei beiden
Browsern ist zu beachten, daß Sicherheitseinstellungen an verschiedenen Stellen
vorgenommen werden können.
Proxy: Beim Netscape Browser (Vers. 4.x) kann unter "Bearbeiten - Einstellungen - Erweitert - Proxies" einen Proxy-Server eingestellt werden (Abb. 4).
Abbildung 4: Einstellung eines Proxy-Servers.
Java etc.:
Die Ausführung von Java und JavaScript kann im Menüpunkt "Erweitert" abgeschaltet werden (Abb. 5). Dies kann auch kurzfristig ohne Neustart des Browsers erfolgen, so daß beispielsweise die Hilfe-Funktion, die auf JavaScript angewiesen ist, genutzt werden kann. Allerdings können diese beiden Sprachen nur global ein- oder abgeschaltet werden. Der Netscape Browser kann JavaApplets, die erweiterte Rechte (beispielsweise Zugriff auf alle Netzwerk-Adressen) benötigen, nur ausführen, wenn diese eine gültige Signatur haben (s. u.). Da ActiveX vom Netscape Browser nicht unterstützt wird, wird das Laden von ActiveX-Controls ignoriert; von der Einbindung zusätzlicher Plug-ins, die den Browser in diese Richtung erweitern, ist wegen der angesprochenen Sicherheitsprobleme abzuraten. Die Version 4.5 des Netscape Browsers hat zusätzlich noch die Möglichkeit JavaScript speziell für Mail oder News-Foren abzuschalten. "Formatvorlagen aktivieren" erlaubt sogenannten "Style Sheets" das Aussehen von WWW-Seiten zu beeinflussen. Durch die "Automatische Installationsoption" erreicht man, daß Updates des Browsers über das Netz ohne eigenes Zutun erfolgen. Über installierte Plug-ins kann man sich - wenn JavaScript aktiviert ist - unter "Hilfe - über Plug-ins" informieren. Im unteren Teil des Menüpunkts "Erweitert" können die Richtlinien für den Umgang mit Cookies eingestellt werden.
Abbildung 5: Die erweiterten Einstellungen des Netscape Browsers.
Erweiterte Zugriffsrechte:
Seit der Version 4 des Netscape Browsers wurden die Möglichkeiten von Java und JavaScript, lokale Ressourcen zu nutzen, wesentlich erweitert, so daß viele Anwendungen erst möglich geworden sind, andererseits aber auch zusätzliche Risikofaktoren hinzugekommen sind. Allgemeinere Sicherheitseinstellungen finden sich unter "Communicator - Sicherheitsheitsinformationen (CTRL-Umsch.-I)". Hier können u. a. Java-Applets und JavaScript-Skripte je nachdem, von welcher Organisation sie zertifiziert wurden, mit erweiterten Zugriffsrechten beispielsweise auf Dateien ausgestattet werden (Abb. 6). Dazu ist es notwendig, daß Java-Applets ausgeführt werden dürfen (s.o.). Wird ein Java-Applet geladen, das erweiterte Zugriffsrechte benötigt, so erscheint eine Warnmeldung, in der angegeben ist, wer das Applet zertifiziert hat und welche zusätzlichen Rechte dieses Applet anfordert. Wird das Applet akzeptiert und "Dieses Vorgehen übernehmen" angeklickt, so werden in Zukunft jedem Applet und jedem Scipt, das das gleiche Zertifikat vorweisen kann, die gleichen Rechte ohne Rückfrage zugestanden. Ist dem ersten Applet beispielsweise das Lesen oder Schreiben von Dateien erlaubt, werden diese Rechte auch an später geladene Applets die vom gleichen Autor signiert wurden ohne weitere Nachfrage übertragen, so daß diese beispielsweise Dateien überschreiben können, ohne daß der Anwender darüber informiert wird.
Abbildung 6: Zugriffsrechte für Java oder JavaScript.
Download:
Wie oben beschrieben, können auch Dateien (nicht nur ausführbare Programme) eine Schadfunktion (PS-Files, Makro-Viren etc.) enthalten, so daß normalerweise die zugehörigen Anwendungen nicht automatisch starten sollten. Eine Nachfrage, wie mit der einzelnen Datei umgegangen werden soll, wird erreicht, indem man "Bearbeiten - Einstellungen - Navigator - Anwendungen" anklickt und für jede kritische Anwendung im Punkt "Bearbeiten" die Option "Auf Festplatte speichern" oder "Vor dem Herunterladen von Dateien dieses Typs Benutzer fragen" wählt (Abb. 7).
Abbildung 7: Einstellung zum Download von Dateien.
Bei der Anwahl einer derartigen Datei wird ein Dialog geöffnet, in welcher Weise
von Fall zu Fall mit ihr umzugehen ist. Ein direktes Öffnen sollte nur bei
Dateien aus sicherer Quelle gewählt werden.
Abbildung 8: Meldung beim Herunterladen einer Datei.
Verschlüsselung:
Beim Zugriff auf verschlüsselte (https://...) wird über die Zertifizierung der Seite unter "Communicator - Sicherheitsinformationen - Zertifikat anzeigen" informiert. Eine Kontrolle des Zertifikats und eine Überprüfung der eigenen Richtlinien für dieses Zertifikat erfolgt in den "Sicherheitsinformationen" unter "Zertifikate - Web-Sites" für einzelne Web-Sites sowie "Unterzeichner" für die Zertifikataussteller (Abb. 9). Im Unterpunkt "Eigene" können eigene Zertifikate, die der eigenen Authentisierung gegenüber anderen Netzteilnehmern dienen, angefordert werden und im Punkt "Andere" die Zertifikate anderer Netzteilnehmer eingebunden werden, um beispielsweise verschlüsselte Email verschicken zu können.
Abbildung 9: Zertifikat einer https-Verbindung.
Einstellungen zur Kryptographie werden ebenfalls bei den "Sicherheitsinformationen" verändert. Hier können zusätzliche Programme zur Verschlüsselung, beispielsweise mit Smart-Cards, eingebunden werden. Weiterhin kann im Punkt "Navigator" ausgewählt werden, daß beim Zugriff und beim Verlassen eines verschlüsselten Netzes, beim Anzeigen einer Seite, die sowohl verschlüsselte als auch unverschlüsselte Inhalte enthält und beim Senden unverschlüsselter Informationen eine Warnmeldung angezeigt wird. Besitzt man mehr als ein Zertifikat um sich gegenüber Web-Seiten auszuweisen, so kann man im Punkt "Zertifikat zur Ausweisung gegenüber Web-Sites" einstellen, ob die Auswahl automatisch, manuell oder immer gleich erfolgen soll. Für die verschlüsselte Übertragung mit dem SSL-Protokoll können in diesem Fenster die Versionen ausgewählt und über Schalter konfiguriert werden (Abb. 10). Nach Möglichkeit sollte eine lange Schlüssellänge gewählt werden. Allerdings ist die Verwendung langer Schlüssel aufgrund US-Exportbeschränkungen nicht immer freigegeben, so daß der Browserbeispielsweise mit dem Programm "fortify" angepaßt werden muß.
Abbildung 10: Einstellungen zur Verschlüsselung.
SmartBrowsing:
Der Browser hat ab der Version 4.5 das sogenannte SmartBrowsing eingebaut. Wird dieses aktiviert, so werden Informationen über die aktuell aufgerufene Seite an einen Internet-Server gesendet, der anschließend Web-Seiten mit verwandten Themen vorschlägt. Die Einstellung hierzu befindet sich unter "Bearbeiten - Einstellungen - Navigator - SmartBrowsing". Da durch Nutzung dieses Dienstes ein Bewegungsprofil erstellt werden kann, sollte er nicht genutzt werden.
Proxy:
Die Einstellung eines
Proxy-Servers erfolgt durch Anklicken von "Ansicht - Optionen - Verbindungen".
Nach der Aktivierung müssen die Einstellungen manuell eingetragen werden.
Java etc.: Beim Microsoft Internet Explorer (Vers. 3.0x und höher) sind
die Vorgaben für den Umgang mit aktiven Inhalten unter "Ansicht - Optionen -
Sicherheit" zu finden. Das Ausführen aktiver Inhalte kann hier deaktiviert
werden (Abb. 11). Die Verwendung ActiveX-Steuererlemente und Plug-ins läßt sich
nur gemeinsam abschalten. Die Verwendung von ActiveX in Scripten, sowie das
Ausführen von Java-Applets kann ebenfalls abgestellt werden. Zusätzlich läßt
sich im ersten Punkt auch die Übertragung aller aktiver Inhalte unterbinden. Im
Bereich "Inhaltsratgeber" können bestimmte Inhalte für den Benutzer
ausgeschlossen werden (beispielsweise Gewalt oder Sex), vorausgesetzt das die
entsprechenden Seiten durch die ausgewählten Filter erfaßt werden. Analog zum
Netscape Browser können Zugriffsrechte an zertifizierte Applets im Abschnitt
"Zertifikate" vergeben und kontrolliert werden. Unter "Client" befinden sich die
verfügbaren eigenen Zertifikaten, unter "Sites" die bereits gespeicherten
anderer Institutionen, über die unter "Herausgeber" Informationen zu finden
sind.
Abbildung 11: Einstellungen zu aktiven Inhalten.
Im Fenster, das durch die Schaltfläche "Sicherheitsgrad" erreicht wird, kann eingestellt werden, welche Zugriffsrechte beispielsweise auf Dateien lokal vorhandenen oder aus dem Internet geladenen Applets zugestanden werden. Die Einstellung "Hoch" sichert, daß Java-Applets nur in einer Sandbox (s.o.) ausgeführt werden können (Abb. 12).
Abbildung 12: Einstellung des Sicherheitsgrads.
Download:
Der Umgang mit heruntergeladenen Datenfiles kann eingestellt werden, indem man "Ansicht - Optionen - Programme - Dateityp" anklickt und dort für alle kritischen Dateien den entsprechenden Vorgang als Standard definiert und den Explorer sich das Öffnen nach dem Übertragen bestätigen läßt. Da man meist auf einen Link klickt, ohne sich vorher darüber wirklich klar zu sein, was er öffnet, ist die automatische Nachfrage stark zu empfehlen (Abb. 13). Beim Internet Explorer kann die Anwendung zu bestimmten Datentypen unabhängig von der Windows-Voreinstellung in der Registry eingestellt werden, so daß hier beispielsweise der Wordviewer anstelle von Word eingesetzt werden kann, um die Ausführung von Makro-Viren zu unterbinden.
Abbildung 13: Download-Einstellungen.
Verschlüsselung:
Beim Zugriff auf eine verschlüsselte Seite kann über "Datei - Eigenschaften - Sicherheit" Information über das Sicherheitszertifikat ausgegeben werden (Abb. 14).
Abbildung 14: Informationen über eine verschlüsselte Internetseite.
Klickt man "Ansicht - Optionen - Erweitert", erreicht man das in Abbildung 15 gezeigte Fenster. Hier sollten alle Warnungen eingeschaltet werden, um über die Übertragung von Daten vom eigenen Rechner informiert zu werden, und zu erfahren, wann man verschlüsselte Seiten besucht, abgelaufene oder ungültige Zertifikate akzeptiert oder Cookies annimmt. Zusätzlich kann der "Java Just in Time"--Compiler (JIT) eingeschaltet werden, der bewirkt, daß geladene Java-Applets sofort nach dem Laden kompiliert werden. "Formatvorlagen verwenden" erlaubt die Verwendung von Style-Sheets, die das Aussehen von Web-Seiten beeinflussen. Die "Java Protokollierung" bewirkt, daß über alle Java-Programmaktivitäten ein Protokoll geführt wird. Bei einer Benutzung von Java ist eine Protokollierung sinnvoll. Das Protokoll wird in der Datei "javalog.txt" abgelegt, die sich üblicherweise unter "c:\Windows\Java" befindet.
Abbildung 15: Erweiterte Einstellungen.
Kryptographie:
Einstellungen zur Kryptographie erfolgen unter "Ansicht - Optionen - Erweitert - Kryptographieeinstellungen". Hier können die benutzten Protokolle ausgewählt werden und eingestellt werden, daß Seiten, die verschlüsselt übertragen wurden, nicht gespeichert werden. Eine Verschlüsselung erfolgt hier lediglich mit einem 40 bit-Schlüssel.
Abbildung 16: Kryptographie-Einstellungen.
Erweiterungen ab Internet Explorer 4.0x - Zonenkonzept:
Beim Internet Explorer ab der Version 4.0x wurde das Sicherheitskonzept überarbeitet. Zentrale Einstellungen blieben jedoch im Wesentlichen unverändert, so beispielsweise die Einstellung des Proxy-Servers ("Internetoptionen - Verbindung"). Allerdings sind die Internetoptionen ab der Version 5 nicht mehr unter "Ansicht", sondern unter "Extras" zu finden. Die Einstellungen der Sicherheitsoptionen wurde mit der Einführung der Internet-Zonen, für die individuelle Sicherheitseinstellungen vorgegeben werden können, jedoch wesentlich verändert ("Internetoptionen - Sicherheit") (Abb. 17). Der Anwender kann hier das Internet selbst in Zonen, denen er Vertrauen entgegen bringt, und anderen einteilen. Dieses Konzept darf nicht mit der Strukturierung des Internets durch IP-Adressen (Subnets) und DNS verwechselt werden. Die lokale Internet-Zone umfaßt dabei im Normalfall alle Server, bei denen der Explorer keinen Proxy benutzen muß, es sei denn, sie sind bereits von Hand einer anderen Zone zugeordnet. Der vertrauenswürdigen Zone müssen die Server explizit zugewiesen werden, alle anderen WWW-Adressen sind in der Internet-Zone zusammengefaßt. Problematisch ist dabei, daß selbst in der Sicherheitsstufe "Hoch" Active Scripting, das JavaScript- oder VBScript-Skipten den Zugriff auf ActiveX-Controls erlaubt, noch aktiviert ist.
Abbildung 17: Die Einstellungen zu den Internetzonen.
In den einzelnen Zonen können spezielle Einstellungen separat vorgegeben werden (Option "Einstellungen" bei Sicherheitsstufe "Angepasst"), so kann beispielsweise das Ausführen aktiver Inhalte durch Anklicken der Option "Fragen" auch von Fall zu Fall innerhalb der jeweiligen Zone entschieden werden (Abb. 18), während es im vertrauensunwürdigen Bereich generell unterbunden wird. Die bestehende Gefahr des DNS-Spoofing (ein WWW-Server täuscht eine falsche Identität vor) muß aber beachtet werden
.
Abbildung 18: Individuelle Einstellungen zu aktiven Inhalten.
Weitere sicherheitsrelevante Punkte können - wie schon beim Explorer 3.0x - auch unter dem Karteireiter "Erweitert" eingestellt werden. Speziell die Einstellungen für Verschlüsselung, die Annahme von Cookies und die Einstellung zum Java "Just-InTime-Compiler" (JIT) finden sich dort (Abb. 19 u. 20).
Abbildung 19: Einstellungen zur Verschlüsselung.
Abbildung 20: Einstellungen zu Java.
» Proxy einstellen
» Hohe Sicherheitsstufen auswählen
» JavaScript und ActiveX abstellen bzw. auf lokale Adressen begrenzen
» Java abstellen, eventuell im Einzelfall wieder aktivieren oder auf lokale
Adressen begrenzen
» Nachfrage vor dem Aufruf externer Programme zur Darstellung von Dateien
einstellen
» Automatisches Starten von heruntergeladenen Programmen abstellen
» Zertifikate überprüfen, Rechte der einzelnen Zertifikate kontrollieren
» Warnmeldungen einschalten
» Java-Protokollierung aktivieren
» "Cookies nur an Ursprungsserver" einschalten
» Automatisches Update des Browsers abstellen
» Überprüfen welche ActiveX-Controls und Plug-ins installiert sind, möglichst
löschen
Nicht nur im Internet werden zahlreiche
Zusatzprogramme und Tools angeboten, die die gängigen Browser erweitern und für
bestimmte Einsätze optimieren. Hier können lediglich wenige kurz vorgestellt
werden.
Das Programm X-Ray-Vision
von Intracept (http://www.intracept.com/)
erlaubt es feste Einstellungen für aktive Komponenten und Cookies zu wählen, die
bei jeder neu geladenen Web-Seite wieder aktiviert werden, unabhängig davon, wie
diese Einstellungen vorher verändert worden, so daß man das Rückstellen
temporärer Einstellungen nicht vergessen kann. Zusätzlich lassen sich von den
Grundeinstellungen abweichend für einzelne Web-Seiten zusätzliche Rechte
vergeben.
Anwendern des Netscape Navigators 3.0x unter Windows NT steht mit Java-Filter
von der Princeton University (http://www.cs.princeton.edu/sip/JavaFilter)
ein Tool zur Verfügung, das es erlaubt einzustellen, daß nur noch von vorher
ausgewählten WWW-Seiten Java-Applets heruntergeladen werden dürfen.
Mit Hilfe des Tools Xcavator
(http://www.winmag.com/software/xcavate.htm)
können alle vom Internet Explorer ab Version 3.0
installierten ActiveX-Controls aufgelistet werden, so daß eine bequeme Kontrolle
möglich ist. Auch bietet dieses Utility die Möglichkeit installierte
ActiveX-Controls per Knopfdruck zu löschen.
Bereits oben wurde das Programm Fortify
(http://www.fortify.net/)
erwähnt, das die Exportversion des Netscape Browsers, deren
Verschlüsselungskomponenten auf 40 Bit Schlüssellänge beschränkt sind, auf
legalem Weg so patcht, daß es mit den gleichen Schlüssellängen wie die
US-Version arbeitet.
Aktive Inhalte stellen eine der größten
Gefährdungen bei der Nutzung des Internet dar. Die Ausführung von unbekannten
Programmen auf lokalen Systemen ist nur dann akzeptabel, wenn entweder die
Rechte dieser Programme stark eingeschränkt sind, oder die Programme von einer
ähnlich vertrauenswürdigen Quelle stammen, wie die bereits vorher installierte
Software. Beide Ansätze werden bei Java verfolgt, während das
Authenticode-Modell von Microsoft in der vorliegenden Form nicht geeignet ist.
Eine zentrale Filterung alleine reicht nicht aus, vielmehr muß die
Benutzerverantwortung das Kernelement einer Sicherheitspolitik sein. Speziell
gelten folgende Empfehlungen:
1. Es sollten nur Programme (ActiveX-Controls, Java-Applets usw.) automatisch
ausführbar sein, die von einer vertrauenswürdigen Quelle stammen, d.h., daß sie
nur dann ohne Rückfrage ausgeführt werden dürfen, wenn sie mit einer digitalen
Signatur versehen sind. Für den verwendeten Schlüssel muß ein Zertifikat des BSI
vorliegen.
2. Müssen Programme ohne digitale Signatur ausgeführt werden, so sollten die
folgenden Kritierien in der angegebenen Reihenfolge zur Prüfung herangezogen
werden. Die Sicherheit nimmt hierbei nach von A nach D ab.
A) Welche Rechte erhält das Programm auf dem Arbeitsplatz-PC? Durch einen
speziellen Mechanismus ("Sandbox") besitzen Java-Applets in der Regel nur sehr
beschränkte Rechte. Aber Achtung: Diese Beschränkung kann durch eine
Konfigurationsänderung aufgehoben werden.
B) Läßt sich der Quellcode des Programms prüfen? JavaScript Programme sind in
der Regel relativ kurz, so daß eine Analyse in Hinblick auf potentiell
gefährliche Routinen möglich ist. Die Ausführung der Programme sollte also
zunächst abgeschaltet und erst nach Prüfung wieder eingeschaltet werden.
C) Gibt es weitere Hinweise für die Vertrauenswürdigkeit des Programms?
Programme, die von einem Server geladen werden, dessen Betreiber
vertrauenswürdig ist, können ausgeführt werden. Aber Achtung: IP-Adressen o.ä.
bieten nicht die Gewißheit, daß es sich um den richtigen Server handelt. Aus
diesem Grunde ist auch das im Internet Explorer vorgesehene Verfahren der
"Sicherheitszonen" nicht ausreichend.
D) ActiveX-Controls haben sämtliche Rechte, die auch der Anwender hat (also
Löschen, Verändern von Dateien usw.). Unsignierte Controls sollten daher in der
Regel nur verwendet werden, wenn sie per Diskette oder CD-ROM installiert werden
können und daher wie herkömmliche Software zu behandeln sind.
3. Um eine größere Sicherheit bei der Ausführung von Java-Applets zu erreichen,
sollte nur die Virtual Machine der Firma SUN eingesetzt werden. Diese ist als
Plug-in von
Sun
verfügbar und leicht zu installieren.
am 26.01.2002 Aktualisiert by Reini