Sicherheit in Rich Internet Applications

Florian Kelbert

Seminar Internetdienste: Web 2.0 und Rich Internet ApplicationsInstitut für Angewandte Informationsverarbeitung

Wintersemester 2007/2008Universität Ulm

Zusammenfassung

Rich Internet Applications (RIAs) be�nden sich zum jetzi-gen Zeitpunkt noch zum gröÿten Teil am Anfang ihrer Ent-wicklung. Sie sollen dem Anwender in naher Zuunft ein voll-kommen neues Erlebnis des Internets ermöglichen, indem In-ternetanwendungen interaktiver werden und zu groÿen Tei-len auf dem Desktop ausgeführt werden. Auf diese Weisewird potentiell gefährlicher aus dem Internet stammenderProgrammcode auf dem Computer des Anwenders ausge-führt wird. Um zu verhindern, dass derartiger Programm-code Schäden auf dem System des Benutzers verursacht, istes unerläÿlich dass die RIAs entsprechende Sicherheitsvor-kehrungen tre�en. In dieser Arbeit werden die Sicherheits-modelle verschiedener RIAs vorgestellt.

Sicherheit in Rich Internet Applications Inhaltsverzeichnis

Inhaltsverzeichnis

1 Grundlagen 31.1 JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 DHTML � HTML, JavaScript und DOM . . . . . . . . . . . . . . . . . . . . . . 41.3 SSL und HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Ajax und Mashups 52.1 Ajax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Mashups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3 JavaScript-Sicherheitsmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.4 Schwachstellen und Bedrohungen . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 Adobe Flash-Player 73.1 Flash-Player als Laufzeitumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . 73.2 ActionScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.3 Persistenter Speicher, Arbeitsspeicher und Prozessüberwachung . . . . . . . . . . 83.4 Sicherheitseinstellungen und Zugri�skontrolle . . . . . . . . . . . . . . . . . . . . 83.5 Das Sandbox-Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4 Adobe Integrated Runtime (AIR) 104.1 AIR als Laufzeitumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104.2 Das Sandbox-Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.3 AIR-Anwendungen auf Basis von HTML . . . . . . . . . . . . . . . . . . . . . . . 12

5 OpenLaszlo 13

6 Microsoft Silverlight 136.1 CoreCRL als Laufzeitumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136.2 Das Transparenzmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

7 Mozilla Prism 15

8 Sun JavaFX 168.1 JavaFX Script und Java SE 6 als Laufzeitumgebung . . . . . . . . . . . . . . . . 168.2 Sicherheitsmodell von Java SE 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

9 Zusammenfassung und Ausblick 18

10 Quellenangaben 19

2

Sicherheit in Rich Internet Applications Grundlagen

1 Grundlagen

1.1 JavaScript

JavaScript ist eine Skriptsprache die bevorzugt eingesetzt wird, um Webseiten dynamisch zuändern. Die Skripte können dafür entweder direkt in den HTML-Quelltext eingebettet oder ineiner separaten Datei ausgeliefert werden. Sie werden dann von einem Interpreter im Internet-Browser ausgeführt. Seit 1997 ist JavaScript unter dem Namen ECMAScript standardisiert.

Das Sandbox-Modell

Der Internet-Browser stellt für JavaScript eine Sandbox bereit. Die mit einer Webseite aus-gelieferten JavaScripte werden nur innerhalb dieser Sandbox ausgeführt und entsprechend denSicherheistrichtlinien des Internet-Browsers in ihren Möglichkeiten eingeschränkt. In der Regelwird so dem Skript beispielsweise der Zugri� auf das Dateisystem oder auf die Netzwerkschichtverboten. Auf diese Weise kann verhindert werden, dass ein ausgeführtes Skript gröÿeren Schadenin der Benutzerumgebung anrichtet. Andere Funktionen von JavaScript, wie beispielsweise dasVerschieben von Browserfenstern oder das Manipulieren des Textes in der Statusleiste, könnenje nach Browser teilweise oder komplett abgeschaltet werden.

JavaScript bietet zwei unterschiedliche Sicherheitsrichtlinien: �Same Origin� und �Signed Script�.Es ist die Aufgabe des Internet-Browsers für die Einhaltung dieser Sicherheitsrichtlinien zu sor-gen.

Die �Same Origin�-Richtlinie

Die �Same Origin�-Richtlinie ist dabei die Standardeinstellung. Diese Richtlinie besagt, dassSkripte nur auf die Eigenschaften und Methoden von Dokumenten mit derselben Herkunft zu-greifen dürfen. Das bedeutet, dass Domain, Server, Protokoll und Port des ausgeführten Skriptsund des zu ändernden Dokumentes dieselben sein müssen, um die Anweisungen erfolgreich aus-zuführen. Diese Überprüfung �ndet jedes Mal statt, wenn ein Skript versucht auf ein anderesFenster oder Frame zuzugreifen. Per <script>-Tag eingebundene Skripte werden als Teil der Sei-te angesehen, in die sie eingebettet sind. Ein solches Skript kann aber aus einer anderen Domainstammen als das Dokument, in das es eingebettet wurde. Damit kann das Skript schlieÿlich aufDokumente zugreifen, die aus einer anderen Domain stammen.

Ein Problem entsteht auÿerdem, wenn eine Domain mehrere Unterverzeichnisse, beispielsweisefür unterschiedliche Benutzer, bereithält. Ein JavaScript das aus einem der Unterverzeichnissestammt und ausgeführt wird, könnte dann auf geö�nete Dokumente der anderen Unterverzeich-nisse zugreifen und diese manipulieren. Die �Same-Origin�-Prüfung würde dies nicht verhindern.Einem Skript ist es auÿerdem erlaubt, die Domain des eigenen Dokumentes auf eine allgemei-nere Domain zu setzen (beispielsweise von www.mathematik.uni-ulm.de auf uni-ulm.de). Damitwären auch �Same Origin�-Checks auf dieser allgemeineren Domain erfolgreich.

Die �Same-Origin�-Richtlinie wird von allen heute verbreiteten Internet-Browsern umgesetzt.Damit ist es Skripten in der Regel nicht möglich, Eigenschaften von Dokumenten aus eineranderen Domain zu ändern.

Die �Signed Script�-Richtlinie

Die Idee der �Signed Script�-Richtlinie ist, dass der Unterzeichner eines digital signierten Java-Scriptes veri�ziert werden kann. Vertraut der Benutzer dem Unterzeichner des Skriptes, so kann

3

Sicherheit in Rich Internet Applications Grundlagen

er diesem mehr Rechte zugestehen, als es die Sandbox eigentlich zulassen würde und so beispiels-weise den Zugang zum Dateisystem gewähren. �Signed Script� wird jedoch nur von Mozilla undNetscape, nicht aber von Microsoft, und damit dem Internet Explorer, unterstützt.

Um ein JavaScript signieren zu können, benötigt der Entwickler ein von einer Zerti�zierungs-stelle ausgestelltes digitales Zerti�kat. Mit Hilfe des SignTools von Netscape wird die HTML-Seite mit allen enthaltenen JavaScripten in einer JAR-Datei zusammengefasst und anschlieÿendsigniert. Die Signatur dieser Archivdatei muss dann beim Benutzer überprüft werden.

1.2 DHTML � HTML, JavaScript und DOM

DHTML steht für �Dynamisches HTML� und bezeichnet Webseiten, die sich im Gegensatz zuherkömmlichen statischen HTML-Seiten im Internet-Browser des Benutzers ändern können. Be-deutend hierbei ist, dass dazu kein weiterer HTTP-Request an den Webseiten-Server nötig wird.Die Daten und Anweisungen für Änderungen an der Webseite liegen bereits im ausgeliefertenDHTML-Dokument vor.

Um die eigentlich statischen HTML-Seiten dynamisch ändern zu können, ist eine Skriptsprachenotwendig. Hierzu wird meist JavaScript verwendet. Auÿerdem wurde vom W3-Konsortium mitdem �Document Object Model�, kurz DOM, eine API de�niert, die den Zugri� auf die einzelne-ne Elemente eines HTML- (und auch XML-)Dokuments vereinheitlicht. Dieses Modell wird vonJavaScript ab der Version 1.5 umgesetzt. Die Anweisungen für die gewünschten dynamischen Än-derungen werden als JavaScript im DHTML-Dokument untergebracht und im Internet-Browserdes Benutzers ausgeführt.

Für die Sicherheit der DHTML-Anwendung ist folglich der Internet-Browser verantwortlich.Aus Sicherheitsgründen bieten diese meist die Möglichkeit, JavaScript komplett oder teilweisezu deaktivieren. Das Sicherheitsmodell des Internet-Browsers schränkt also die Fähigkeiten derverwendeten Skriptsprache und damit des DHTML-Dokuments ein.

1.3 SSL und HTTPS

TCP/IPProtokoll-Stack

SSL, Secure Sockets Layer, ist ein Protokoll das entwickelt wurde, um eineverschlüsselte Datenübertragung im Internet zu ermöglichen. Im TCP/IP-Referenzmodell �ndet sich SSL zwischen Transportschicht (meist TCP oderUDP) und Anwendungsschicht (zum Beispiel HTTP oder FTP) wieder.Damit kann jedes Protokoll der Anwendungsschicht mit SSL-Unterstützungimplementiert werden und so diesen Mechanismen nutzen. SSL stellt danndie Authentizität des Servers sowie die Vertraulichkeit und Integrität, dasbedeutet die Unverfälschtheit, der übetragenen Daten sicher.

Bei HTTPS handelt es sich nicht um ein eigenes Protokoll. HTTPSist ein URI-Schema und weist darauf hin, dass HTTP in Verbindung mitdem darunterliegenden SSL-Protokoll verwendet wird. So werden HTTP-Dokumente vor der eigentlichen Übertragung durch SSL verschlüsselt undgeschützt.

Mit allen in dieser Arbeit besprochenen Rich Internet Applications ist esmöglich SSL zu nutzen. So können die Webanwendungen dem Benutzer perHTTPS zugänglich gemacht werden und auch ein späterer Datenaustausch zwischen Client undServer kann über eine sichere SSL-Verbindung geschehen.

4

Sicherheit in Rich Internet Applications Ajax und Mashups

2 Ajax und Mashups

2.1 Ajax

Ajax steht für �Asynchronous JavaScript and XML� und ist keine eigene oder gar neue Technolo-gie. Vielmehr ist Ajax ein Begri� für die Kombination unterschiedlicher DHTML-Mechanismen,die gemeinsam ermöglichen, dass nur bestimmte Teile einer ansonsten statischen Webseite neugeladen und/oder dargestellt werden.

HTML dient dabei als Grundlage für den Transport und die Darstellung der Inhalte. DOM wirdverwendet, um auf die einzelnen Elemente des HTML-Dokumentes und dessen zugehörigen CSS-Dateien zuzugreifen und diese zu verändern. Als Datenformat, in dem die Daten zwischen Clientund Server ausgetauscht werden, können unterschiedliche Formate wie XML, HTML, JSON oderPlaintext genutzt werden. Mittels des JavaScript-Objekts XMLHttpRequest können Client undServer Daten im vereinbarten Format austauschen � ohne dass ein Neuladen der Seite nötigwird. Als Transportgrundlage hierfür dient das HTTP-Protokoll, jedoch können die Anfragenasynchron abgearbeitet werden, wodurch die Webseite auch während der Kommunikation mitdem Server benutzbar bleibt. Auÿerdem ist es durch den XMLHttpRequest möglich, nur Teileder Webseite neu anzufordern. Um diese Funktionalitäten zu ermöglichen, ist eine Skriptspra-che erforderlich, die im Internet-Browser des Clients interpretiert wird. Hierfür wird JavaScriptverwendet. JavaScript verarbeitet die Benutzereingaben, stellt die dynamischen Inhalte dar undorganisiert die Kommunikation mit dem Server, der die Webseite und deren dynamische Inhaltezur Verfügung stellt. Um die asynchrone Kommunikation zu ermöglichen, stellt JavaScript dasbereits erwähnte XMLHttpRequest-Objekt bereit.

2.2 Mashups

Als �Mashup� wird eine Webseite bezeichnet, die Inhalte aus mehreren unterschiedlichen Quel-len zusammenfasst. Diese unterschiedlichen Inhalte interagieren üblicherweise miteinander, umgemeinsam eine Aufgabe zu erledigen. Einzelne Komponenten des Mashups sind dabei selbst-ständige kleine Ajax-Anwendungen. Ajax stellt wiederum die Techniken für die Kommunikationzwischen den einzelnen Komponenten zur Verfügung.

2.3 JavaScript-Sicherheitsmodell

Da bei Ajax JavaScript die zentrale Technologie ist, um die Dynamik in den Webseiten zu er-möglichen, machen die JavaScript-Sicherheitsrichtlinien einen Groÿteil des Sicherheitsmodellsvon Ajax aus. Die Hauptbestandteile hierbei sind die bereits in Abschnitt 1.1 erläuterte �SameOrigin�-Richtlinie und das Sandbox-Modell von JavaScript. Da mit Ajax die Programmlogik derWebseite teilweise von der Server-Seite auf die Client-Seite verlagert wird, müssen die Entwick-ler der Webanwendungen vor allem bei sicherheitskritischen Funktionalitäten besondere Vorsichtwalten lassen. Zugri�skontrollen für Webseiten oder Dienste dürfen keinesfalls nur beim Clientimplementiert werden, da der an den Client gegebene Programmcode vor der Ausführung modi-�ziert werden kann.

2.4 Schwachstellen und Bedrohungen

Umgehen der �Same Origin�-Richtlinie

Trotz der Umsetzung der �Same Origin�-Richtlinie in allen modernen Internet-Browsern, kanndiese nur in begrenztem Umfang für mehr Sicherheit sorgen, da das Umgehen dieser Richtlinie auf

5

Sicherheit in Rich Internet Applications Ajax und Mashups

unterschiedlichen Wegen möglich ist. Wird ein Tag dynamisch durch JavaScript in eine Webseiteeingefügt, so wird auf die im �src�-Attribut angegebene URL, die auch auf eine andere Domainverweisen kann, zugegri�en. Dadurch wird es möglich, Daten an einen anderen Server zu sendenund anschlieÿend von diesem eine Antwort zu erhalten, sofern dieser Daten in einem zu JavaScriptkompatiblen Format wie JSON zurückliefert. Darüber hinaus können Ajax Proxy-Server, dieHTTP-Anfragen und -Antworten zwischen Client und Server weiterleiten, den Webanwendungenerlauben, die �Same Origin�-Richtlinie zu umgehen. Dazu kommunizieren die Proxy-Server mittelsXMLHttpRequests mit einem Server aus einer dritten Domain. Viele Internet-Browser besitzenauÿerdem die Möglichkeit Erweiterungen zu installieren, welche wiederum die �Same Origin�-Richtlinie des Browsers auÿer Kraft setzen können.

Cross-Site Scripting (XSS)

Mit Cross-Site Scripting können Angri�e auf den Benutzer einer Webseite durchgeführt werden.Diese zielen darauf ab, bösartigen Programmcode in eine ansonsten harmlose Webseite einzu-schleusen. Dies kann beispielsweise geschehen, wenn eine Webanwendung mit Hilfe der docu-

ment.write()-Funktion Benutzereingaben in eine Webseite einbaut ohne spezielle und potenziellgefährliche Zeichen, im HTML-Kontext sind das vor allem spitze Klammern und Anführungs-zeichen, zu �ltern. Ebenso gefährlich ist das Ausführen von fremdem und unge�ltertem Pro-grammcode mit der eval()-Funktion. Der eingeschleuste Programmcode wird dann im Kontextdes Dokumentes, in das er eingefügt wurde, ausgeführt und besitzt entsprechend alle Rechtedes Dokumentes. Über diese Wege können bösartige Skripte, die beispielsweise den Benutzer aufeine Phishing-Seite weiterleiten oder Cookies auslesen, in eine Webseite eingebaut oder direktausgeführt werden.

�Denial of Service�-Angri�e (DoS)

Im Internet-Browser ausgeführte Skripte können dazu führen, dass der Browser oder, in seltenenFällen, das ganze Betriebssystem nicht mehr reagiert. Eine Endlosschleife, die unter Umstän-den bei jedem Durchlauf Speicher allokiert, groÿe Datenmengen über das Netzwerk anfordert,Popup-Fenster ö�net oder die Position des Browser-Fensters ändert, macht in den meisten Fällenzumindest das aktuelle Browserfenster oder die Netzwerkverbindung unbrauchbar. Ein solcherAngri� wird als �Denial of Service�-Angri� bezeichnet.

Cross-Site Request Forgeries (CSRF)

Ist bei einer Webanwendung die Authentisierung des Benutzers erforderlich, so müssen Benut-zername und Passwort normalerweise nicht bei jedem neuen HTTP-Request vom Benutzer ein-gegeben werden. Da HTTP jedoch ein zustandsloses Protokoll ist, werden die Informationen zueinem Login vom Internet-Browser gespeichert. Bei weiteren HTTP-Requests fügt der Internet-Browser diese Informationen automatisch hinzu, so dass der Benutzer weiterhin an der Weban-wendung authentisiert bleibt. Dies geschieht auch dann, wenn der Request nicht vom Benutzerselbst beabsichtigt war. Um dieses Verhalten des Internet-Browsers auszunutzen, genügt es, wennder bei einer Webanwendung authentisierte Benutzer eine Webseite mit bösartigem JavaScript-Programmcode besucht. Dieser Programmcode kann dann beliebige HTTP-Requests im Namendes authentisierten Nutzers an die Webandwendung schicken, da der Internet-Browser selbst-ständig die zur Authentisierung nötigen Informationen anfügt.

6

Sicherheit in Rich Internet Applications Adobe Flash-Player

Unbemerktes Versenden von Daten durch XMLHttpRequests

Bei herkömmlichen statischen Webseiten können Daten wegen der synchronen Abarbeitung derAnfragen erst an den Webserver versendet werden, wenn der Benutzer dies mit einem Klick aufeinen entsprechenden Button veranlasst. Mit XMLHttpRequests und der asynchronen Abarbei-tung der Anfragen hat eine Ajax-Anwendung dagegen die Möglichkeit, Daten an einen Server zuversenden ohne dass die Webseite erneut geladen wird oder der Benutzer auf andere Weise davonerfährt. Eine Phishing-Seite könnte mit dem regelmäÿigen Versenden von XMLHttpRequests anBenutzereingaben gelangen, selbst wenn sich der Benutzer später entscheidet die Eingaben nichtabzusenden.

Zusätzliche Bedrohungen bei Mashups

Auf Grund der Tatsache, dass Mashups aus mehreren Ajax-Anwendungen bestehen, sind auchMashups von oben genannten Angri�en bedroht. Mashups bieten jedoch noch zusätzliche An-gri�sziele: Da es Mashups dem Benutzer erlauben können, beliebige Ajax-Anwendungen einzu-binden, ist es nicht auszuschlieÿen, dass bösartige Seiten in ein Mashup eingebunden werden.Sofern das Mashup keine ausreichenden Schutzmechanismen implementiert, ist es der bösartigenSeite mit entsprechenden JavaScript-Anweisungen möglich, sowohl den Benutzer als auch die dasMashup zur Verfügung stellende Webseite beispielsweise mit einer DoS-Attacke anzugreifen.

Gegenmaÿnahmen

Um die Gefahr einzuschränken, dass fremder Programmcode in eine Ajax-Anwendung einge-schleust wird, ist die Validierung sämtlicher Benutzereingaben nötig. Potenziell gefährliche Zei-chen wie spitze Klammern und Anführungszeichen müssen herausge�ltert oder maskiert werden.Desweiteren sollte nach Möglichkeit kein automatisch generierter, oder von unsicheren externenQuellen eingebunder, Programmcode ausgeführt werden. Um CSRF-Angri�e zu erschweren, kannder Referrer-Header, der angibt von welcher Seite ein Request abgeschickt wurde, des HTTP-Requests validiert werden. Weitere Möglichkeiten CSRF-Angri�e zu erschweren, bestehen darin,die Authentisierung mit Hilfe eines versteckten Feldes auf jedem Formular zu vollziehen oder einweiteres, vom Server generiertes, Geheimnis einzuführen, das bei weiteren Requests des Benutzersmitgeschickt wird.

3 Adobe Flash-Player

3.1 Flash-Player als Laufzeitumgebung

Der Flash-Player und die zugehörigen SWF-Dateien (Small Web Format) sind eine Möglichkeit,Rich Internet Applications an den Benutzer auszuliefern. Hierbei werden die Inhalte in SWF-Dateien kompiliert und üblicherweise auf einem Webserver zugänglich gemacht. Diese SWF-Dateien bestehen zum einen aus multimedialen Inhalten wie Bildern, Video und Audio undzum anderen aus ausführbarem Programmcode. Der Client muss den Flash-Player installierthaben und kann damit nach dem Download der SWF-Dateien deren Inhalte anzeigen aundausführen. Der Flash-Player stellt dann die Laufzeitumgebung für die SWF-Applikationen darund kontrolliert damit die Zugri�e auf die Systemressourcen.

7

Sicherheit in Rich Internet Applications Adobe Flash-Player

3.2 ActionScript

ActionScript ist die Programmiersprache für die Flash-Player-Laufzeitumgebung und basiert aufdem ECMAScript-Standard. ActionScript-Code liegt in SWF-Dateien im Bytecode-Format vorund wird von der �ActionScript Virtual Machine�, die Teil des Flash-Players ist, ausgeführt.Vor der Ausführung wird der Bytecode von veri�ziert und auf Vollständigkeit überprüft, sodass invalider Bytecode bereits vor der Ausführung erkannt und zurückgewiesen werden kann.Durch die Integration von ActionScript werden mit dem Flash-Player interaktive und komplexeAnwendungen möglich.

3.3 Persistenter Speicher, Arbeitsspeicher und Prozessüberwachung

Der Flash-Player verbietet den Inhalten der SWF-Dateien den Zugri� auf das lokale Dateisystem.Lediglich das Anlegen, Beschreiben und Löschen sogenannter �Shared Objects� in einem spezielldafür vorgesehenen, und mit pseudo-zufälligen Zeichen versehenen, Verzeichnis wird unter stren-ger Aufsicht der Laufzeitumgebung gestattet. Diese stellen einer SWF-Datei einen persistentenSpeicher, vergleichbar mit Cookies, zur Verfügung und werden mit einer bestimmten SWF-Dateiassoziiert. Weiterhin limitiert der Flash-Player die Gröÿe eines �Shared Objects� standardmäÿigauf 100KB, um �Denial of Service�-Angri�e die auf dem Belegen von Speicherplatz basieren, zuerschweren.

Fehler im Programmablauf wie Pu�erüberläufe oder Endlosschleifen können von der Laufzeit-umgebung erkannt und verhindert oder abgebrochen werden. Dazu überwacht der Flash-Playerdie Ausführung der SWF-Dateien und gibt dem Benutzer die Möglichkeit ein Skript abzubrechen,falls die Ausführung nicht zum Ende gelangt und eine Endloschleife vermutet wird. Auÿerdemsorgt die Laufzeitumgebung für die Verwaltung und Zuteilung des Arbeitsspeichers an einzelneSWF-Anwendungen und die zugehörige Speicherbereinigung (Garbage Collection).

3.4 Sicherheitseinstellungen und Zugri�skontrolle

Hierarchie derZugri�skontrolle

Die Laufzeitumgebung unterscheidet zwischen vier unterschiedlichen Perso-nengruppen: dem Administrator des Client-Computers, dem Benutzer desClient-Computers, dem Besitzer der Webseite, von dem die SWF-Dateistammt, und dem Autor der SWF-Datei. Jede dieser vier Personengrup-pen stellt Ressourcen bereit, für welche sie jeweils die Sicherheitseinstel-lungen und Zugri�sberechtigungen vornehmen können. Diese Sicherheits-einstellungen und Zugri�sberechtigungen werden in einer strengen Hierar-chie angeordnet. So haben die Einstellungen des Administrators des Client-Computers die höchste Priorität, gefolgt von den Einstellungen des ausfüh-renden Benutzers und den Einstellungen des Besitzers der Webseite. DieSicherheitseinstellungen des Autors der SWF-Datei haben schlieÿlich diegeringste Priorität. Schränkt beispielsweise der ausführende Benutzer denZugri� auf die von ihm bereitgestellten Ressourcen ein, so können wederdie Sicherheitseinstellungen der Webseite noch die des Autors diese Sperreumgehen. Selbstverständlich kann eine SWF-Datei überhaupt nur dann aufandere Ressourcen zugreifen, wenn diese die gewünschten Zugri�e erlauben.Der eine SWF-Datei ausführende Benutzer ist in der Lage den Zugri� der ausgeführten Dateiauf eine zweite Ressource einzuschränken oder zu verbieten. Jede der erwähnten Gruppen hatauÿerdem die Möglichkeit, die Sicherheitseinstellungen für die von ihr bereitgestellten Ressourcenzu delegieren.

8

Sicherheit in Rich Internet Applications Adobe Flash-Player

3.5 Das Sandbox-Modell

Sandboxen sind ein zentraler Punkt des Flash-Player-Sicherheitsmodells. Eine Sandbox ist dabeieine Art logischer Container der Ressourcen beinhaltet. Jede SWF-Datei wird einer solchenSandbox zugeordnet. Eine Sandbox legt sämtliche Zugri�srechte auf Ressourcen, basierend aufden Sicherheitseinstellungen der jeweiligen Ressourceninhaber, fest. Dazu gehören Zugri�e aufDateien und andere genutzte Ressourcen wie Video oder Audio. Jede dieser Sandboxen ist vomBetriebssystem, dem Dateisystem, anderen Anwendungen und den anderen Sandboxen isoliert.

Eine Sandbox pro Domain

Alle SWF-Dateien die derselben Sandbox zugeordnet werden, können vollkommen ungehindertuntereinander Daten austauschen und auf Daten innerhalb der Sandbox zugreifen. Diese Zu-ordnung wird auf Grund der Domain, aus der die SWF-Datei stammt, getro�en. Eine Sandboxrepräsentiert also jeweils eine konkrete Domain. Zwei aus derselben Domain stammende SWF-Dateien können daher gegenseitig ihre Variablen, Methoden und Einstellungen lesen und/oderändern, sofern dies der jeweilige Rechteinhaber erlaubt. Dieses Vorgehen wird �Cross-Scripting�genannt.

Eine SWF-Datei darf nur auf die Ressourcen aus einer anderen Sandbox zugreifen, wenn esihr von den jeweiligen Ressourceninhabern der anderen Sandbox ausdrücklich erlaubt wurde.Damit eine SWF-Datei Daten von einem Server laden kann, muss dieser in einer sogenann-ten Policy-Datei die entsprechende Leseberechtigung für die Domain, aus der die SWF-Dateistammt, au�isten. Zwei SWF-Dateien aus unterschiedlichen Sandboxen können ebenfalls nurinteragieren, wenn zuvor entsprechende Einstellungen vorgenommen wurden: Hat eine SWF-Datei 'A' einer Domain 'b.com' mit dem ActionScript-Methodenaufruf Security.allowDomain()

das Cross-Scripting gewährt, so kann in der Folge eine SWF-Datei 'B' aus der Domain 'b.com'auf die Variablen und Methoden von 'A' zugreifen. Dieses Gewähren von Rechten �ndet jedochasynchron statt, daher hat 'A' durch diese Einstellungen weiterhin keinen Zugri� auf 'B'. Andieser Stelle greifen auÿerdem die Sicherheitseinstellungen und zugehörigen Prioritäten der vieroben beschriebenen Personengruppen. Die Einhaltung dieser zugestandenen Rechte wird von derLaufzeitumgebung strengstens überwacht. Das Senden von Daten über Sandboxen hinweg wirdbei SWF-Dateien aus der Netzwerkdomäne in der Regel nicht von der Laufzeitumgebung kon-trolliert � es wird davon ausgegangen, dass die Daten beim Empfänger sicher weiterverarbeitetwerden.

Die Zuordnung zur Sandbox tri�t der Flash-Player auf Grund der Informationen die von demdarunterliegenden Protokoll bereitgestellt werden. Daher kann beispielsweise beim Transport vonSWF-Dateien mittels HTTP nicht davon ausgegangen werden, dass diese Informationen korrektsind, da es durch einen Angri� möglich wäre, die Zuordnung zwischen URL und zugehörigerIP-Adresse zu fälschen. Bei SWF-Dateien die mit HTTPS transportiert wurden, kann dagegendie Domaininformation veri�ziert werden. In der Standardeinstellung können daher mit HTTPtransportierte Inhalte nicht auf Inhalte zugreifen, die mit HTTPS transportiert wurden, auchwenn diese aus derselben Domain stammen.

Sonderregeln für lokale Dateien

Für lokale SWF-Dateien die nicht aus der Netzwerkdomäne stammen, gilt ebenfalls das bis-her beschriebene Sandbox-Modell, jedoch gibt es für diese die drei separaten Sandboxen �local-with-�lesystem�, �local-with-networking� und �local-trusted�. Gemäÿ ihren Namen erlauben die

9

Sicherheit in Rich Internet Applications Adobe Integrated Runtime (AIR)

beiden ersteren jeweils den Zugri� auf das Netzwerk oder das lokale Dateisystem. Die �local-trusted�-Sandbox erlaubt hingegen sowohl die Netzwerkkommunikation als auch den Zugri� aufdas lokale Dateisystem und den Zugri� auf jede andere SWF-Datei. Um die Kommunikationmit den gewünschten Ressourcen zu ermöglichen, müssen diese wiederum die gewünschten Zu-gri�e erlauben. Ein Datenaustausch zwischen der �local-with-�lesystem�- und der �local-with-networking�-Sandbox wird genauso verboten wie eine Kommunikation zwischen der �local-with-�lesystem�-Sandbox und Sandboxen die eine Netzwerkdomäne repräsentieren. Mit Hilfe dieserEinschränkungen wird ausgeschlossen, dass zwei kooperierende SWF-Dateien, von denen je ei-ne aus der �local-with-�lesystem�- und der �local-with-networking�-Sandbox stammt, Daten ausdem lokalen Dateisystem über das Netzwerk versenden. Daten können daher nur mit Hilfe ei-ner �local-trusted�-SWF-Datei von dem lokalen Dateisystem in das Netzwerk gelangen. SelbstAdministratoren haben nicht die Berechtigung, diese Einschränkungen zu umgehen.

Beim Kompilieren einer SWF-Datei kann der Autor angeben, dass die übersetzte Datei bei lo-kaler Ausführung der �local-with-networking�-Sandbox zugeordnet werden soll. Dadurch wird je-doch jede Berechtigung aufgegeben, auf das lokale Dateisystem zuzugreifen. Durch diese Maÿnah-me können Daten aus dem lokalen Dateisystem tatsächlich nur über die �local-trusted�-Sandboxin das Netzwerk gelangen. Im Gegenzug darf eine SWF-Datei aus der �local-with-networking�-Sandbox auf Ressourcen aus dem Netzwerk zugreifen, sofern ihr diese die gewünschten Zugri�egewähren. Ohne die erwähnte Angabe beim Kompilieren ordnet der Flash-Player eine lokaleSWF-Datei automatisch der �local-with-�lesystem�-Sandbox zu. Der Endbenutzer und der Sys-temadministrator haben jedoch immer die Möglichkeit lokale SWF-Dateien in die �local-trusted�-Sandbox zu verschieben oder sie von dort zu entfernen.

Standardberechtigungen des Flash-Players

4 Adobe Integrated Runtime (AIR)

4.1 AIR als Laufzeitumgebung

AIR ist eine Laufzeitumgebung, die für die Ausführung und Darstellung spezieller AIR-Anwen-dungen verantwortlich ist. Nach der Installation der Laufzeitumgebung können diese Anwendun-gen wie herkömmliche Desktop-Anwendungen ausgeführt werden. Die Laufzeitumgebung ver-waltet den Speicher und die zur Verfügung gestellte Rechenzeit. Die AIR-Anwendungen be-stehen entweder aus kompiliertem Bytecode (Flash/ActionScript) oder interpretiertem Skript

10

Sicherheit in Rich Internet Applications Adobe Integrated Runtime (AIR)

(DHTML/JavaScript) und werden wie herkömmliche Programme mit den jeweiligen Privilegiendes Benutzers ausgeführt. Dadurch erhalten die Anwendungen Zugri� auf viele Funktionen desBetriebssystems, die browserbasierten Anwendungen nicht zur Verfügung stünden. Dazu gehörenbeispielsweise Zugri�e auf das Dateisystem und die Netzwerkkommunikation entsprechend denRechten des ausführenden Benutzers.

Signierung von AIR-Dateien

Ein zentraler Punkt bei der Entwicklung und Auslieferung von AIR-Anwendungen ist die Signa-tur der Installationsdateien. Jede AIR-Anwendung muss dazu mit einem Zerti�kat unterschriebenwerden. Auf diese Weise kann vor der Installation die Integrität der Anwendung und die Iden-tität des Unterzeichners veri�ziert werden. AIR nutzt dann die Public-Key-Infrastruktur undden Zerti�katsspeicher des Betriebssystems, um festzustellen ob dem Zerti�kat vertraut werdenkann. Dazu muss der Benutzer entweder direkt dem zu prüfenden Zerti�kat vertrauen oder ervertraut einer Kette von Zerti�katen. Hierbei ist jedes Zerti�kat der Kette vom darau�olgendenZerti�kat unterschrieben und das zu prüfende Zerti�kat wird so auf eine der Zerti�zierungsstellenVerisign oder Thawte zurückgeführt. Nur wenn eine dieser beiden Bedingungen erfüllt ist, kannder Unterzeichner und die Integrität der Installationsdatei veri�ziert werden.

Installation von AIR-Anwendungen

Die Installation von AIR-Anwendungen läuft unter strenger Kontrolle der Laufzeitumgebungund vollkommen unabhängig von einem Internet-Browser oder anderen Anwendungen ab. EineInstallation von AIR-Anwendungen auÿerhalb dieser Laufzeitumgebung ist nicht möglich. Durchdiese vereinheitlichte Installationsprozedur kann sichergestellt werden, dass der Installationsvor-gang für alle Anwendungen sicher und konsistent verläuft. Dem Benutzer wird angezeigt, obdie Veri�kation der Signatur erfolgreich und die Integrität der Installationsdatei gegeben war.Konnte die Signatur erfolgreich ver�ziert werden, wird dem Benutzer der Name des Unterzeich-ners angezeigt. Andernfalls wird ihm deutlich gemacht, dass die Ver�kation nicht möglich war.Auÿerdem wird dem Benutzer mitgeteilt, welche Rechte die Anwendung nach der Installationhaben wird. Mit Hilfe der nun vorliegenden Informationen kann der Benutzer entscheiden, ob erfortfahren oder die Installation abbrechen möchte.

4.2 Das Sandbox-Modell

Sandbox-Modell des Flash-Players als Grundlage

Das AIR-Sicherheitsmodell baut auf dem Sandbox-Modell des Flash-Players auf. Wie bereits inAbschnitt 3.5 erklärt, existieren dort domain-spezi�sche Sandboxen und solche für lokale Dateienmit Zugri� auf das Dateisystem oder das Netzwerk.

Zusätzliche �application�-Sandbox

AIR erweitert das Modell des Flash-Players um eine zusätzliche �application�-Sandbox. Dateiendie nicht dieser �application�-Sandbox zugeordnet werden, erhalten dieselben Einschränkungenwie beim Flash-Player-Modell. Dateien die sich innerhalb dieser neu eingeführten Sandbox be�n-den, erhalten dagegen von der Laufzeitumgebung alle Rechte die für AIR-Anwendungen verfügbarsind und vollen Zugri� auf die AIR-APIs. Wie auch beim Sandbox-Modell des Flash-Players sinddie Sandboxen voneinander isoliert und haben keinen Zugri� auf Dateien und Daten aus eineranderen Sandbox.

11

Sicherheit in Rich Internet Applications Adobe Integrated Runtime (AIR)

Bei der Installation einer AIR-Anwendung werden alle Dateien in einem Anwendungsverzeich-nis abgelegt und können somit beim Start der Anwendung der �application�-Sandbox zugeord-net werden. Der Zugri� auf besondere AIR-APIs, die beispielsweise den Zugri� auf das lokaleDateisystem ermöglichen, ist nur den Inhalten aus den �application�-Sandboxen gestattet. AIR-Anwendungen ist es auÿerdem erlaubt, weitere Dateien von beliebigen anderen Quellen, wie demeigenen Dateisystem oder aus dem Netzwerk, zu laden. Diese aus anderen Quellen geladenenDateien werden einer Sandbox entsprechend des Flash-Player-Modells zugeordnet. Inhalte dienicht einer �application�-Sandbox zugeordnet sind, können daher, wie im Flash-Player-Modellüblich, nur Inhalte aus der Domain aus der sie selbst stammen nachladen. Es ist jedoch möglich,dass Programmcode aus einer �application�-Sandbox diese Einschränkungen aufhebt.

Da die Inhalte der �application�-Sandbox Rechte für mächtige API-Funktionen besitzen, mussgewährleistet werden, dass diese Rechte nicht von unauthorisierten Inhalten aus anderen Sand-boxen verwendet werden. Daher kann Programmcode aus der �application�-Sandbox kein Cross-Scripting mit dem ActionScript-Aufruf Security.allowDomain() erlauben. Ebenso ist es nichtmöglich, fremde Inhalte in die �application�-Sandbox zu laden oder Programmcode dynamischzu erzeugen.

Sichere Kommunikation zwischen Sandboxen

An manchen Stellen ist es wünschenswert, dass Inhalte unterschiedlicher Sandbox miteinanderkommunizieren oder interagieren. Daher stellt AIR für solche Fälle einen besonderen Mechanis-mus bereit: Über eine sogenannte Sandbox-Brücke, die von Inhalten in der �application�-Sandboxeingerichtet wird, können Dateien von auÿerhalb der �application�-Sandbox die zur Verfügunggestellten Funktionen nutzen. Eine Brücke stellt damit ein Gateway zwischen den Inhalten ausunterschiedlichen Sandboxen dar und ermöglicht so deren Interaktion. Der Anwendungsentwick-ler kann so indirekt APIs für Inhalte, die nicht aus der �application�-Sandbox stammen, bereit-stellen.

4.3 AIR-Anwendungen auf Basis von HTML

AIR-Anwendungen können ausschlieÿlich mit HTML und JavaScript erstellt werden. Dazu stelltAIR eine browser-ähnliche Umgebung bereit, die HTML, DOM und JavaScript verarbeiten kann.Diese auf HTML basierenden AIR-Anwendungen können jedoch zusätzlich von der AIR-APIGebrauch machen. Auÿerdem führt AIR zwei neue Attribute für die HTML-Elemente Frameund IFrame ein, die es ermöglichen Teile einer HTML-AIR-Anwendung so zu behandeln alswürden sie aus einer anderen Domain stammen.

Um die in Abschnitt 2.4 vorgestellten Schwachstellen im Zusammenhang mit HTML und Java-Script in AIR-Anwendungen zu beseitigen, stellt AIR zusätzliche Sicherheitsmechanismen bereit.Dazu können vom Entwickler Frames und IFrames verwendet werden. Ein übergeordnetes Frameenthält dann die Hauptobjekte der Webanwendung und diese bleiben dort bestehen, solange die-ses Frame nicht auf eine andere Seite navigiert wird. In weiteren untergeordneten Frames werdendie eigentlichen Inhalte der Webandwendung geladen, ausgeführt und angezeigt. Alle Objek-te im übergeordneten Frame ordnet AIR der �application�-Sandbox zu und schränkt für dieseInhalte die Nutzung der eval()-Funktion ein, die es erlaubt dynamisch generierten Programmco-de auszuführen. Auf diese Weise wird ausgeschlossen, dass nicht aus der �application�-Sandboxstammender Programmcode mit den Rechten der �application�-Sandbox ausgeführt wird.

Die untergeordneten Frames erhalten eine eigene Sandbox und können uneingeschränkten vonder eval()-Funktion Gebrauch machen. Der Zugri� auf bestimmte AIR-APIs bleibt Inhalten

12

Sicherheit in Rich Internet Applications Microsoft Silverlight

die nicht aus der �application�-Sandbox stammen aber vorenthalten. Eine Brücke zwischen denuntergeordneten Frames und der �application�-Sandbox ermöglicht eine sichere Kommunikationzwischen den unterschiedlichen Sandboxen einer Webanwendung.

5 OpenLaszlo

OpenLaszlo-Anwendungen werden zunächst in der XML-Sprache LZX geschrieben und anschlie-ÿend entweder in das SWF-Format oder in das DHTML-Format übersetzt. Da ein OpenLaszlo-Server die Anwendung also sowohl im SWF-Format als auch im DHTML-Format bereitstellenkann, hängen die beim ausführenden Benutzer greifenden Sicherheitsmechanismen vom ausgelie-ferten Format ab.

Wurde die OpenLaszlo-Anwendung vom Server in eine SWF-Datei kompiliert, so wird die-se vom Flash-Player ausgeführt und angezeigt. In diesem Fall greifen also alle Sicherheitsme-chanismen des Flash-Players (siehe Abschnitt 3). Liegt die OpenLaszlo-Anwendung jedoch alsDHTML-Datei vor, ist der Internet-Browser für die Ausführung und Anzeige verantwortlich.Das Sicherheitsmodell der OpenLaszlo-Anwendung entspricht dann dem Sicherheitsmodell desausführenden Internet-Browsers, insbesondere in Bezug auf das in der DHTML-Seite enthalteneJavaScript (siehe Abschnitt 1.1).

OpenLaszlo selbst implementiert keine eigenen weitergehenden Sicherheitsmechanismen. Statt-dessen verlässt sich OpenLaszlo auf die Sicherheitsmechanismen des Flash-Players und des Internet-Browsers.

6 Microsoft Silverlight

6.1 CoreCRL als Laufzeitumgebung

Ab der Version 1.1 beinhaltet Silverlight eine reduzierte Version der, �Common Language Run-time� (CLR) genannten, vituellen Maschine von .NET. Diese reduzierte Version wird CoreCLRgenannt und wird als Plugin in den Internet-Browser integriert. Die CoreCLR stellt so die Lauf-zeitumgebung für Silverlight-Anwendungen dar und stellt Speicherverwaltung, Garbage Collec-tion das nötige Sicherheitsmodell zur Verfügung. Silverlight-Anwendungen können in jeder vondem .NET Framework unterstützen Programmiersprache (u.a. C#, J#, VB.NET), in einer dy-namischen Skriptsprache wie JavaScript oder einer Kombination hiervon geschrieben werden.

6.2 Das Transparenzmodell

Das von der CoreCLR umgesetzte Sicherheitsmodell basiert auf dem Transparenzmodell, das im.NET Framework v2.0 eingeführt wurde.

Transparenter und kritischer Programmcode

Als �transparent� wird in diesem Zusammenhang Programmcode bezeichnet, der keine Anweisun-gen ausführen kann, die die Rechte des Aufrufstacks erhöhen würden. Transparenter Programm-code wird mit den ihm zugesicherten Rechten oder den Rechten des ausführenden Benutzersausgeführt, wobei jeweils die restriktiveren Rechte ausschlaggebend sind. Im Gegensatz zum

13

Sicherheit in Rich Internet Applications Microsoft Silverlight

transparenten Programmcode steht der �kritische� Programmcode, der wesentlich mehr Rech-te besitzt. Assemblies, in der .NET-Terminologie Container für übersetzte Programmklassen,können sowohl transparenten als auch kritischen Programmcode enthalten, während einzelneMethoden ausschlieÿlich transparent oder kritisch sein können.

Beim CoreCLR-Sicherheitsmodell muss sämtlicher von Benutzern ausgeführter Programmcodetransparent sein, während der sogenannte �Plattform-Code�, also von der Silverlight-Plattformbereitgestellte Assemblies, sowohl transparente als auch kritische Methoden enthalten dürfen.Daher dürfen Silverlight-Anwendungen ausschlieÿlich aus transparentem Programmcode beste-hen.

Der zentrale Punkt des Sicherheitsmodells besteht darin, dass es transparentem Programm-code, und damit insbesondere Silverlight-Anwendungen, verboten ist, kritischen Programmcodeaufzurufen. Wird dies dennoch versucht, so wird eine MethodAccessException geworfen.

�Safe-critical� Programmcode

Erlaubte Aufrufe

Viele für Anwendungen wünschenswerte Funktionen, beispielsweiseder Zugri� auf das Dateisystem, müssen jedoch als kritisch markiertund implementiert werden, da es nur kritischem Programmcode er-laubt ist den nötigen Maschinencode auszuführen. Um den Silverlight-Anwendungen den Zugri� auf diese Funktionalitäten zu ermöglichen,wird eine neue Schicht zwischen dem transparenten und dem kritischenProgrammcode eingezogen. Dieser als �safe-critical� bezeichnete Pro-grammcode stellt Methoden zur Verfügung, die als API zum kritischenProgrammcode dienen. Transparentem Programmcode wird nun zu-sätzlich erlaubt, �safe-critical� Programmcode aufzurufen. Diese APIsüberprüfen dann die Zulässigkeit eines Aufrufs und validieren die Auf-rufparameter, bevor sie den Methodenaufruf an die eigentliche kritischeMethode weitergeben. Über den Umweg der �safe-critical� Methodenhaben die Silverlight-Anwendungen so überwachten Zugri� auf kriti-sche Methoden und deren sehr viel weiter reichende Funktionalitäten.

Während Silverlight-Anwendungen ausschlieÿlich aus transparentemProgrammcode bestehen dürfen, kann Plattform-Code auch aus �safe-critical� oder kritischem Programmcode bestehen. Die Entscheidungob eine Assembly �safe-critical� oder kritsche Methoden enthalten darf, tri�t die CoreCLR aufGrund des Verzeichnisses aus dem die Assembly geladen wurde und durch die Überprüfung derSignatur. Nur Assemblies die aus dem Silverlight-Installationsverzeichnis geladen und mit demMicrosoft-eigenen Schlüssel signiert wurden, werden dem Plattform-Code zugeordnet. Nicht vonMicrosoft stammende Assemblies können nicht mit diesem Schlüssel signiert sein und werdendaher ausschlieÿlich mit den Rechten des transparenten Programmcodes ausgeführt.

SecurityCriticalAttribute und SecuritySafeCriticalAttribute

Um das Modell umzusetzen, werden zwei Attribute eingeführt, mit denen sowohl Klassen als auchMethoden versehen werden können. Ist eine Klasse mit einem dieser Attribute versehen, so giltdieses für alle in der Klasse enthaltenen Methoden. Das Schlüsselwort SecurityCriticalAttributemarkiert dabei eine Methode oder Klasse als kritisch, während das Schlüsselwort SecuritySafeCri-ticalAttribute anzuwenden ist, wenn die Methode oder Klasse �safe-critical� sein soll. Methoden

14

Sicherheit in Rich Internet Applications Mozilla Prism

oder Klassen die nicht mit einem dieser Attribute versehen wurden, sind standardmäÿig trans-parent. Werden Methoden einer Silverlight-Anwendung mit einem der Attribute versehen, sohat dies keine Auswirkungen, da Anwendungen nur aus transparentem Programmcode bestehendürfen.

Zusätzlich existieren auch die herkömmlichen Schlüsselwörter public, private, protected undinternal, die bei der Frage nach der Rechtmäÿigkeit von Methodenaufrufen ebenfalls ausgewertetwerden müssen. So kann eine Silverlight-Anwendung keine transparente oder �safe-critical� Me-thode aufrufen, wenn diese aus einer anderen Assembly stammt und darin als internal markiertwurde.

Vererbung und Überschreiben virtueller Methoden

Insgesamt besteht das Silverlight-Sicherheitsmodell aus drei Ebenen unterschiedlichen Programm-codes, die sich wie folgt anordnen lassen: kritisch < �safe-critical� < transparent. Eine Klasse kannnur von solchen Klassen erben, die auf derselben oder einer höheren Ebene angesiedelt sind, wo-bei der transparente Programmcode die höchste Ebene darstellt. So dürfen �safe-critical� Klassenvon anderen �safe-critical� Klassen und transparenten Klassen, nicht aber von kritischen Klas-sen, erben. Da Silverlight-Anwendungen nur transparenten Programmcode enthalten, können dieKlassen einer Anwendung nur von anderen Anwendungs-Klassen oder von transparenten Klassendes Plattform-Codes erben. Damit das Erben von einer bestimmten Klasse tatsächlich möglichist, muss dies auch von der Oberklasse gestattet werden.

Ist es einer Klasse gestattet von einer anderen Klasse zu erben, dann können auch die geerbtenvirtuellen Methoden überschreiben werden. Transparente Klassen, und damit auch alle Klassenaus Silverlight-Anwendungen, können transparente sowie �safe-critical� Methoden überschrei-ben, während �safe-critical� und kritische Klassen jeweils �safe-critical� und kritische Methodenüberschreiben dürfen. Ebenso verhält sich das Sicherheitsmodell bei der Implementierung vonInterfaces. Transparenter Programmcode darf daher nur transparente und �safe-critical� Interfa-cemethoden implementieren.

7 Mozilla Prism

Prism ermöglicht es, Webanwendungen wie herkömmliche Desktop-Anwendungen erscheinen zulassen und sie auf ähnliche Weise zu verwenden. Die Webanwendungen werden nicht mehr ineinem Fenster oder Tab des Internet-Browsers ausgeführt, sondern in einem eigenen Fenster,das von sämtlichen Bedienelementen des Internet-Browsers befreit wurde. So sind beispielswei-se Desktop-Verknüpfungen und das Window-Manager-übliche Umschalten zwischen Webanwen-dungen und Desktop-Anwendungen möglich. Da es sich bei Prism (bisher) um eine reduzierteVersion des Internet-Browsers Firefox handelt, entspricht das Sicherheitsmodell von Prism demdes Firefox-Browsers.

Enthält eine Webanwendung Flash- oder Silverlightanwendungen und ist ein entsprechendesPlugin installiert, so greifen für diese Anwendungen die Sicherheitsmodelle der jeweiligen Techno-logien wie in den Abschnitten 3 und 6 beschrieben. Ist ein nötiges Plugin nicht vorhanden, dannkönnen diese Inhalte nicht dargestellt werden. Wird mit Prism eine DHTML-Seite angefordert,so greifen für das vorhandene JavaScript die in Abschnitt 1.1 erläuterten Mechanismen.

15

Sicherheit in Rich Internet Applications Sun JavaFX

8 Sun JavaFX

JavaFX besteht aus unterschiedlichen Komponenten, mit deren Hilfe sich Rich Internet App-lications erstellen und ausführen lassen. Die wichtigsten Bestandteile sind JavaFX Script undJavaFX Mobile, ein Betriebssystem für mobile Geräte (Mobiltelefone u.ä.) mit integrierter Java-Laufzeitumgebung. Mit JavaFX erstellte Anwendungen können sowohl mit JavaFX Mobile, alsauch auf dem Desktop mit der herkömmlichen Java SE (Java Platform, Standard Edition) aus-geführt werden.

8.1 JavaFX Script und Java SE 6 als Laufzeitumgebung

JavaFX Script ist eine JSR 223-kompatible Skriptsprache, die sich sehr stark an Java orien-tiert. JSR 223 ist dabei eine Spezi�kation, die eine Standard-API für Script-Engines de�niertund so das Benutzen von Java-Objekten in Skriptsprachen und anders herum ermöglicht. Ja-vaFX Script kann daher direkt Aufrufe an die Java-API absetzen und bestehende Java-Klassenverwenden. Dafür übersetzt eine Script-Engine den Skriptcode in Java-Objekte. Die Java SE 6,bestehend aus einer Laufzeitumgebung und den für die Ausführung von Java-Anwendungen er-forderlichen Bibliotheken, implementiert die JSR 223-API und ermöglicht so das Ausführen vonJavaFX Script und JavaFX-Anwendungen. Auf diese Weise greifen für JavaFX-Anwendungendie Sicherheitsmechanismen der Java SE 6.

8.2 Sicherheitsmodell von Java SE 6

Sandbox durch Veri�er, ClassLoader und SecurityManager

Das Java-Sicherheitsmodell basiert auf drei Komponenten, die es gemeinsam ermöglichen, Pro-grammcode sicher auszuführen: der Veri�er, der ClassLoader und der SecurityManager.

Vor der Ausführung von Java-Code in der �Java Virtual Machine� (JVM), wird der Bytecodevon einem Veri�er darauf hin überprüft, ob er konform zur Java-Spezi�kation ist. Der Veri�erüberprüft dazu das Format des Bytecodes und stellt unter anderem sicher, dass Zeiger nicht ver-fälscht, Zugri�sbeschränkungen nicht verletzt und Typen nicht auf unerlaubte Weise konvertiertwerden. Zusätzlich wird durch den Veri�er gewährleistet, dass kein Überlauf des Aufrufstacksstatt�nden kann. Das Ausführen fremden Programmcodes durch Manipulieren einer Rücksprun-gadresse ist somit ausgeschlossen. Ist eine Klassendatei nicht veri�zierbar, wird eine Exceptiongeworfen und der enthaltene Programmcode nicht ausgeführt.

Der ClassLoader entscheidet, ob und wie Klassen zu einer laufenden Umgebung hinzugefügtwerden können und stellt sicher, dass durch das Laden einer Klasse keine wichtigen Komponentender Laufzeitumgebung ersetzt werden.

Die JVM überwacht alle Zugri�e auf kritische Systemressourcen und überläÿt die Entschei-dung der Rechtmäÿigkeit eines Zugri�es dem SecurityManager. Nur lokale, mit dem Befehl �java�ausgeführte, Anwendungen können auch ohne SecurityManager, und damit ohne dessen Zugri�s-kontrollmechanismen, gestartet werden. Entscheidungen über die Rechtmäÿigkeit eines Zugri�sdelegiert der SecurityManager an den AccessController.

Neben der Ausführungseinheit beinhaltet die JVM auch eine Speicherverwaltung und die zuge-hörige Speicherbereinigung, so dass das sehr fehleranfällige Belegen und Freigeben von Speicherdurch den Programmierer nicht mehr nötig ist. Diese Arbeiten werden zuverlässig von der JVMerledigt.

16

Sicherheit in Rich Internet Applications Sun JavaFX

Gemeinsam realisieren Veri�er, ClassLoader und SecurityManager das Java-Sandbox-Modell.Durch das Zusammenspiel dieser Komponenten wird ausgeschlossen, dass eine Anwendung aufSystemressourcen zugreift, für die sie keine Rechte besitzt.

Individuelle Sicherheitsrichtlinien

Mit Java 2 (alle Java-Versionen > 1.1) ist es möglich, individuelle Sicherheitsrichtlinien für alleAnwendungen festzulegen. So kann nicht nur zwischen vertrauenswürdig und nicht vertrauens-würdig unterschieden werden, sondern es ist eine feingranulare Rechtevergabe für einzelne An-wendungen möglich. Diese Richtlinien können sowohl vom Anwendungsprogrammierer, als auchvom Benutzer oder dessen Administrator festgelegt werden. So kann der Zugri� auf einzelneKlassen teilweise oder vollständig erlaubt werden. Da mit Java 1.1 die Möglichkeit eingeführtwurde, Java-Archiv-Dateien (JAR) mit einem digitalen Zerti�kat zu signieren, können die Si-cherheitsrichtlinien auf Basis dreier unterschiedlicher Merkmale vorgenommen werden: Codebasevergibt Rechte für Klassen, die von einem bestimmten Ort stammen, während mit SignedBy

Bezug auf die Signatur genommen werden kann und Principal die Möglichkeit bietet, Rechte nurfür bestimmte Benutzer zu vergeben.

17

Sicherheit in Rich Internet Applications Zusammenfassung und Ausblick

9 Zusammenfassung und Ausblick

Insgesamt kann man feststellen, dass alle der in dieser Arbeit behandelten Rich Internet Ap-plications (RIAs) bestehende und bewährte Sicherheitsmodelle aufgreifen und diese zum Teilerweitern. Als Grundlage für viele RIAs dient Adobes Flash-Player, der in den meisten Fällen alsBrowser-Plugin installiert wird und den Adobe für die eigene Integrated Runtime um eine neueSandbox erweitert hat. Auch OpenLaszlo kann die Quelldateien neben dem DHTML-Format indas Flash-Format kompilieren. Das Sicherheitsmodell von Microsofts Silverlight baut auf demTransparenzmodell des .NET-Frameworks auf, das mit dem Konzept der CoreCLR gleichzeitigvereinfacht wird. Suns JavaFX nutzt dagegen die vorhandenen und weitreichenden Sicherheits-mechanismen der Java-Plattform. Mozillas Prism stellt unter den RIAs eine Ausnahme dar, daes sich hierbei, zumindest bisher, nur um eine reduzierte Version des Firefox-Browsers handelt.DHTML, Ajax und das damit eingesetzte JavaScript bieten mit der �Same Origin�-Richtlinie auchSicherheitsmechanismen an, jedoch bieten die weitreichenden Funktionalitäten von JavaScriptund die Komfort-Funktionen des Internet-Browsers eine vergleichsweise groÿe Angri�s�äche.

Im Moment be�nden sich RIAs noch am Anfang ihrer Entwicklung, so dass sicher auch im Be-reich der Sicherheitsmechanismen, insbesondere bei AIR und Silverlight, noch einige Änderungenanstehen können. Wie robust, fehleranfällig oder auch angreifbar die von AIR und Silverlight im-plementierten Sicherheitsmechanismen tatsächlich sein werden, wird sich erst mit deren weiterenVerbreitung zeigen, auch wenn die bisherigen Konzepte durchaus schlüssig und vielversprechendsind.

Abschlieÿend bleibt zu sagen, dass die Thematik �Sicherheit in Rich Internet Applications�in dieser Arbeit keinesfalls vollständig abgehandelt werden konnte. Über die Sicherheitsaspektevon Ajax/DHTML/JavaScript, Flash/AIR, Silverlight/.NET und Java lassen sich ganze Bücherschreiben, so dass im Rahmen dieser Arbeit nur ein Überblick über die verwendeten Sicherheits-modelle und -mechanismen möglich war.

18

Sicherheit in Rich Internet Applications Quellenangaben

10 Quellenangaben

JavaScript

JavaScript Securityhttp://www.devarticles.com/c/a/JavaScript/JavaScript-Security/

JavaScript Security in Mozillahttp://www.mozilla.org/projects/security/components/jssec.html

JavaScript/JScript Sicherheitsmodellhttp://www.bsi.de/fachthem/sinet/gefahr/aktiveinhalte/de�nitionen/javascriptsichmodell.htm

DHTML

Einführung in JavaScript und DOMhttp://de.selfhtml.org/javascript/intro.htm

What is Dynamic HTML (DHTML)?http://webdesign.about.com/od/dhtml/a/aa030298.htm

DOMhttp://webdesign.about.com/od/dhtml/g/bldefdom.htm

SSL und HTTPS

SSL (Secure Socket Layer)http://www.bsi-fuer-buerger.de/browser/02_05.htm

Die Funktionsweise von SSLhttp://www.repges.net/SSL/ssl.htm

Was ist https? Was ist SSL?http://www.mela.de/Unix/FAQ/#26

Ajax

Ajax and Mashup Securityhttp://www.openajax.org/whitepapers/Ajax%20and%20Mashup%20Security.html

The XMLHttpRequest Objecthttp://www.w3schools.com/xml/xml_http.asp

Ajax security � A reality checkhttp://searchsoftwarequality.techtarget.com/tip/0,289483,sid92_gci1219207,00.html

Ajax security: Are AJAX applications vulnerable to hack attacks?http://www.acunetix.com/websitesecurity/ajax.htm

Application Security in AJAXhttp://ajax.sys-con.com/read/430930.htm

A JavaScript DOS Attackhttp://www.guyrutenberg.com/2007/11/23/a-javascript-dos-attack/

19

Sicherheit in Rich Internet Applications Quellenangaben

Adobe Flash-Player

Adobe Flash Player 9 Securityhttp://www.adobe.com/devnet/�ashplayer/articles/�ash_player_9_security.pdf

Adobe Flash Security and Adobe Enterprise Solutionshttp://www.adobe.com/devnet/�ashplayer/articles/�ashsecurity.pdf

Programming ActionScript 3.0, Chapter 17: FlashPlayer Securityhttp://download.macromedia.com/pub/documentation/en/�ex/2/prog_actionscript30.pdf

Creating more secure SWF web applicationshttp://www.adobe.com/devnet/�ashplayer/articles/secure_swf_apps.html

Adobe Integrated Runtime (AIR)

AIR Securityhttp://livedocs.adobe.com/labs/air/1/devappshtml/help.html?content=security_1.html

Digitally signing an AIR �lehttp://livedocs.adobe.com/labs/air/1/devappshtml/

help.html?content=distributing_apps_13.html

Adobe AIR Securityhttp://download.macromedia.com/pub/labs/air/air_security.pdf

Adobe AIR HTML Securityhttp://download.macromedia.com/pub/labs/air/air_htmlsecurity.pdf

OpenLaszlo

OpenLaszlo Architecturehttp://www.openlaszlo.org/lps4/docs/deployers/deployers.architecture.html

Laszlo Systems: Technology White Paperhttp://www.openlaszlo.org/whitepaper/LaszloWhitePaper.pdf

Mozilla Prism

Mozilla Labs: Prismhttp://labs.mozilla.com/2007/10/prism/

Microsoft Silverlight

The Silverlight Security Modelhttp://blogs.msdn.com/shawnfa/archive/2007/05/09/the-silverlight-security-model.aspx

Silverlight Security II: What Makes a Method Criticalhttp://blogs.msdn.com/shawnfa/archive/2007/05/10/

silverlight-security-ii-what-makes-a-method-critical.aspx

Silverlight Security III: Inheritancehttp://blogs.msdn.com/shawnfa/archive/2007/05/11/silverlight-security-iii-inheritance.aspx

20

Sicherheit in Rich Internet Applications Quellenangaben

Transparency as Least Privilegehttp://blogs.msdn.com/shawnfa/archive/2007/10/30/transparency-as-least-privilege.aspx

Silverlight Security Model Primerhttp://devduck.spaces.live.com/blog/cns!15D0C43F1C8E7753!365.entry

When the Opposite of Transparent isn't Opaquehttp://blogs.msdn.com/shawnfa/archive/2005/08/31/458641.aspx

Introducing Microsoft Silverlight 1.1 Alphahttp://blogs.msdn.com/bclteam/archive/2007/04/30/

introducing-microsoft-silverlight-1-1-alpha-justin-van-patten.aspx

Silverlight 1.1 Alpha - Development with the .NET Frameworkhttp://msdn2.microsoft.com/en-us/library/bb404700.aspx

Sun JavaFX

What Is JavaFX? Here's The Answerhttp://www.psynixis.com/blog/2007/05/08/what-is-javafx-heres-the-answer/

Sun Radically Simpli�es Content Authoring - Previews JavaFX Scripthttp://www.sun.com/aboutsun/pr/2007-05/sun�ash.20070508.2.xml

Scripting for the Java Platformhttp://java.sun.com/developer/technicalArticles/J2SE/Desktop/scripting/

JSR 223 and Scripting Javahttp://www.judoscript.com/articles/jsr223.html

JavaFX != JavaFX Scripthttp://weblogs.java.net/blog/joshy/archive/2007/09/javafx_javafx_s.html

Java Scripting: JavaFX Scripthttp://developers.sun.com/events/techdays/presentations/locations-2007/

shanghai/java_track2/td_sha_javafx_lee.pdf

Securing Javahttp://www.securingjava.com

JDK 6 Security-related APIs & Developer Guideshttp://java.sun.com/javase/6/docs/technotes/guides/security/

21