Mobile Code Security Im Rahmen des Seminars Web Security Andreas Marx WIF 02 98

Inhalt  Mobile Code  Schutzmöglichkeiten und -konzepte  Browser-Integration  Java  ActiveX  JavaScript & Co.  Ausblick / Diskussion

Mobile Code  Wird bei Bedarf aus dem Web heruntergeladen  Ist ausführbarer Inhalt (z. B. Programmcode)  Client-seitig, z.B. Java Applets, ActiveX Controls, JavaScript, Visual Basic Script, Safe-Tcl, Telescript  Server-seitig, z.B. Servlets  Problem: Sicherheit (u. a. Integrität, Vertraulichkeit)?!?

Schutzmöglichkeiten (1)  Alles abschalten! Am wirkungsvollsten, aber nicht der Sinn der Sache (Noch unbekannte) Sicherheitslücken? Ist wirklich alles abgeschaltet?  Digitale Zertifikate Kennzeichnen nachvollziehbar den Herausgeber Aber wer ist vertrauenswürdig?

Schutzmöglichkeiten (2)  Sandbox: Gesicherte Umgebung mit sehr eingeschränkten oder gar keinen Zugriff auf Ressourcen  (Ständige) Überwachung: Komplex und Zeitintensiv In Praxis kaum verbreitet

Schutzkonzepte (1)  Zugriffsschutz auf Systemressourcen Im Laufzeitsystem implementiert Z. B. Speicherzugriffe nur im eigenen Adressbereich  Konzeptioneller Ressourcenzugriffsschutz Bei Zugriff auf Ressourcen anderer Rechner Explizite Aufrufe, d. h. einfach zu überwachen Z. B. Datenbanken

Schutzkonzepte (2)  Systemressourcenverbrauchskontrolle Zeitintensive Überwachung Alle Änderungen am Systemzustand werden überwacht, Transaktionen Abbruch, wenn Ressourcen zu lange beansprucht werden  Konzeptionelle Ressourcenverbrauchskontrolle Kombinierbar mit Zugriffskontrolle in Abhängigkeit vom Systemzustand (z. B. Auslastung) Nur bestimmte Anzahl von DB-Zugriffen bei gewisser Auslastung zulassen

Browser-Integration  Hilfsprogramme bzw. Plug-Ins Kommen bei nicht (direkt) vom Browser unterstützten Dateiformaten zum Einsatz Z. B. AVI, MPG, MP3, RM, PDF Sind in der Regel schon vorher installiert Keine Ausführungsbeschränkungen oder Prüfungen Vertrauenswürdige Herkunft, Originale Z. T. aber auch Zugriffsschutzmodelle (kaum relevant)

Java (1)  Ursprung: Oak (1991)  Durchbruch mittels WWW als Java (1994)  Designziele: Plattform-unabhängig, Kompakt, Verfügbar, über das Netz herunterladbar  Als Programm oder im Browser startbar  Bytecode, wird interpretiert (langsam) oder per Just-in-Time-Compiler (JIT) direkt in Maschinencode übersetzt

Java (2)  JDK 1.0.x: Lokale Programme haben Vollzugriff Mobile Code läuft nur in der Sandbox  JDK 1.1.x: Einführung von digitalen Signaturen Mobilen Code kann man auch Vollzugriff ermöglich  JDK 1.2.x: Feinere Zugriffsrechte definierbar

Java (3)  Laden von Java Applets im Browser: Bytecode Verifier Applet Class Loader Applet (in eigenem Namespace) Ausführung in der Java Virtual Machine Überwachung durch den Security Manager Datenaustausch nur mit Herkunftsseite möglich  Probleme: u.a. Sicherheitslücken (insbesondere in frühen Versionen) und in „MS-Java“

ActiveX (1)  Microsoft‘s Ansatz von mobilen Anwendungen  Sammlung von Technologien, Protokollen und APIs, um ausführbaren Code über das Internet zu laden  Ursprung: OCX-Controls zur „nahtlosen“ Integration von Desktop und Netzwerk  Nur für Windows-Plattformen (Intel, 32 Bit)  Nicht auf Sicherheit ausgelegt, sondern dies wurde erst per Authenticode „drumherumgebaut“

ActiveX (2)  Arten von ActiveX-Controls: Native Code: Am gefährlichsten, direkt ausführbar, „Vollzugriff“ auf den Rechner Java Bytecode: Für JVM (Sandbox oder privilegiert), Überwachung möglich Mischform: Genauso gefährlich wie Native Code

ActiveX (3)  Authenticode: Digitale Signaturen (Public-Key-Zertifikate) Prüfung der Signatur beim Herunterladen des Controls (z.B. Unversehrtheit, Gültigkeit) Individuelle Entscheidung des Benutzers bei jedem ActiveX-Control (einzeln wählbar), ob er es ausführen möchte oder nicht  Gefahren: Keinerlei Beschränkungen, häufige Sicherheitslücken

JavaScript & Co. (1)  JavaScript: Von Netscape entwickelt (LiveScript)  JScript: Microsofts Implementierung von JavaScript  Visual Basic Script: Microsoft‘s eigene Skriptsprache

JavaScript & Co. (2)  Prozeduraler Aufbau (mit Parametern)  Werden interpretiert  Keine Klassen (Objekte) erzeugbar, aber auf vorhandene kann zugegriffen werden  Kann zwar nicht auf Dateien zugreifen, dafür aber auf andere Elemente (z.B. History, URLs)  Keine unterschiedlichen Sicherheitsrichtlinien für einzelne Skripte einer Webseite möglich, entweder alles oder nichts  Gefahren: DoS-Attacken (Fenster öffnen, Endlosschleifen), Generierung von anderem Code (Skripte oder Java), Web- Spoofing

Ausblick / Diskussion  Die Zukunft ist voller Überraschungen...  Was ist nun die „beste Möglichkeit“ für Mobile Codes, wie müsste sie aussehen und wie wäre sie zu implementieren?  Ist so etwas überhaupt realisierbar?