Sicherheit in Rich Internet Applications

(1)

Florian Kelbert

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

Wintersemester 2007/2008 Universität Ulm

Zusammenfassung

Rich Internet Applications (RIAs) benden sich zum jetzi- gen Zeitpunkt noch zum gröÿten Teil am Anfang ihrer Ent- wicklung. Sie sollen dem Anwender in naher Zuunft ein vollkommen 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 Weise wird potentiell gefährlicher aus dem Internet stammender Programmcode auf dem Computer des Anwenders ausge- führt wird. Um zu verhindern, dass derartiger Programm- code Schäden auf dem System des Benutzers verursacht, ist es unerläÿlich dass die RIAs entsprechende Sicherheitsvor- kehrungen treen. In dieser Arbeit werden die Sicherheits- modelle verschiedener RIAs vorgestellt.

(2)

Sicherheit in Rich Internet Applications Inhaltsverzeichnis

Inhaltsverzeichnis

1 Grundlagen 3

1.1 JavaScript . . . . 3

1.2 DHTML HTML, JavaScript und DOM . . . . 4

1.3 SSL und HTTPS . . . . 4

2 Ajax und Mashups 5 2.1 Ajax . . . . 5

2.2 Mashups . . . . 5

2.3 JavaScript-Sicherheitsmodell . . . . 5

2.4 Schwachstellen und Bedrohungen . . . . 5

3 Adobe Flash-Player 7 3.1 Flash-Player als Laufzeitumgebung . . . . 7

3.2 ActionScript . . . . 8

3.3 Persistenter Speicher, Arbeitsspeicher und Prozessüberwachung . . . . 8

3.4 Sicherheitseinstellungen und Zugriskontrolle . . . . 8

3.5 Das Sandbox-Modell . . . . 9

4 Adobe Integrated Runtime (AIR) 10 4.1 AIR als Laufzeitumgebung . . . 10

4.2 Das Sandbox-Modell . . . 11

4.3 AIR-Anwendungen auf Basis von HTML . . . 12

5 OpenLaszlo 13 6 Microsoft Silverlight 13 6.1 CoreCRL als Laufzeitumgebung . . . 13

6.2 Das Transparenzmodell . . . 13

7 Mozilla Prism 15 8 Sun JavaFX 16 8.1 JavaFX Script und Java SE 6 als Laufzeitumgebung . . . 16

8.2 Sicherheitsmodell von Java SE 6 . . . 16

9 Zusammenfassung und Ausblick 18

10 Quellenangaben 19

(3)

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 in einer 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 ausgelieferten JavaScripte werden nur innerhalb dieser Sandbox ausgeführt und entsprechend den Sicherheistrichtlinien des Internet-Browsers in ihren Möglichkeiten eingeschränkt. In der Regel wird so dem Skript beispielsweise der Zugri auf das Dateisystem oder auf die Netzwerkschicht verboten. Auf diese Weise kann verhindert werden, dass ein ausgeführtes Skript gröÿeren Schaden in der Benutzerumgebung anrichtet. Andere Funktionen von JavaScript, wie beispielsweise das Verschieben von Browserfenstern oder das Manipulieren des Textes in der Statusleiste, können je 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 sorgen.

Die Same Origin-Richtlinie

Die Same Origin-Richtlinie ist dabei die Standardeinstellung. Diese Richtlinie besagt, dass Skripte nur auf die Eigenschaften und Methoden von Dokumenten mit derselben Herkunft zugreifen dürfen. Das bedeutet, dass Domain, Server, Protokoll und Port des ausgeführten Skripts und 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 anderes Fenster 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 Domain stammen als das Dokument, in das es eingebettet wurde. Damit kann das Skript schlieÿlich auf Dokumente zugreifen, die aus einer anderen Domain stammen.

Ein Problem entsteht auÿerdem, wenn eine Domain mehrere Unterverzeichnisse, beispielsweise für unterschiedliche Benutzer, bereithält. Ein JavaScript das aus einem der Unterverzeichnisse stammt 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). Damit wä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 einer anderen Domain zu ändern.

Die Signed Script-Richtlinie

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

(4)

Sicherheit in Rich Internet Applications Grundlagen

er diesem mehr Rechte zugestehen, als es die Sandbox eigentlich zulassen würde und so beispielsweise den Zugang zum Dateisystem gewähren. Signed Script wird jedoch nur von Mozilla und Netscape, 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 Zertizierungs- stelle ausgestelltes digitales Zertikat. Mit Hilfe des SignTools von Netscape wird die HTML- Seite mit allen enthaltenen JavaScripten in einer JAR-Datei zusammengefasst und anschlieÿend signiert. 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 zu herkö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 ausgelieferten DHTML-Dokument vor.

Um die eigentlich statischen HTML-Seiten dynamisch ändern zu können, ist eine Skriptsprache notwendig. Hierzu wird meist JavaScript verwendet. Auÿerdem wurde vom W3-Konsortium mit dem Document Object Model, kurz DOM, eine API deniert, die den Zugri auf die einzelne- ne Elemente eines HTML- (und auch XML-)Dokuments vereinheitlicht. Dieses Modell wird von JavaScript 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-Browser des 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 teilweise zu deaktivieren. Das Sicherheitsmodell des Internet-Browsers schränkt also die Fähigkeiten der verwendeten Skriptsprache und damit des DHTML-Dokuments ein.

1.3 SSL und HTTPS

TCP/IP Protokoll-Stack SSL, Secure Sockets Layer, ist ein Protokoll das entwickelt wurde, um eine

verschlüsselte Datenübertragung im Internet zu ermöglichen. Im TCP/IP- Referenzmodell ndet sich SSL zwischen Transportschicht (meist TCP oder UDP) und Anwendungsschicht (zum Beispiel HTTP oder FTP) wieder.

Damit kann jedes Protokoll der Anwendungsschicht mit SSL-Unterstützung implementiert werden und so diesen Mechanismen nutzen. SSL stellt dann die Authentizität des Servers sowie die Vertraulichkeit und Integrität, das bedeutet die Unverfälschtheit, der übetragenen Daten sicher.

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

Mit allen in dieser Arbeit besprochenen Rich Internet Applications ist es möglich SSL zu nutzen. So können die Webanwendungen dem Benutzer per

HTTPS zugänglich gemacht werden und auch ein späterer Datenaustausch zwischen Client und Server kann über eine sichere SSL-Verbindung geschehen.

(5)

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 neu geladen und/oder dargestellt werden.

HTML dient dabei als Grundlage für den Transport und die Darstellung der Inhalte. DOM wird verwendet, 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 Client und Server ausgetauscht werden, können unterschiedliche Formate wie XML, HTML, JSON oder Plaintext genutzt werden. Mittels des JavaScript-Objekts XMLHttpRequest können Client und Server Daten im vereinbarten Format austauschen ohne dass ein Neuladen der Seite nötig wird. Als Transportgrundlage hierfür dient das HTTP-Protokoll, jedoch können die Anfragen asynchron abgearbeitet werden, wodurch die Webseite auch während der Kommunikation mit dem Server benutzbar bleibt. Auÿerdem ist es durch den XMLHttpRequest möglich, nur Teile der 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 JavaScript verwendet. JavaScript verarbeitet die Benutzereingaben, stellt die dynamischen Inhalte dar und organisiert die Kommunikation mit dem Server, der die Webseite und deren dynamische Inhalte zur Verfügung stellt. Um die asynchrone Kommunikation zu ermöglichen, stellt JavaScript das bereits 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, um gemeinsam eine Aufgabe zu erledigen. Einzelne Komponenten des Mashups sind dabei selbst- ständige kleine Ajax-Anwendungen. Ajax stellt wiederum die Techniken für die Kommunikation zwischen 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 Sicherheitsmodells von Ajax aus. Die Hauptbestandteile hierbei sind die bereits in Abschnitt 1.1 erläuterte Same Origin-Richtlinie und das Sandbox-Modell von JavaScript. Da mit Ajax die Programmlogik der Webseite 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 Vorsicht walten lassen. Zugriskontrollen für Webseiten oder Dienste dürfen keinesfalls nur beim Client implementiert 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, kann diese nur in begrenztem Umfang für mehr Sicherheit sorgen, da das Umgehen dieser Richtlinie auf

(6)

Sicherheit in Rich Internet Applications Ajax und Mashups

unterschiedlichen Wegen möglich ist. Wird ein Tag dynamisch durch JavaScript in eine Webseite eingefügt, so wird auf die im src-Attribut angegebene URL, die auch auf eine andere Domain verweisen kann, zugegrien. Dadurch wird es möglich, Daten an einen anderen Server zu senden und anschlieÿend von diesem eine Antwort zu erhalten, sofern dieser Daten in einem zu JavaScript kompatiblen Format wie JSON zurückliefert. Darüber hinaus können Ajax Proxy-Server, die HTTP-Anfragen und -Antworten zwischen Client und Server weiterleiten, den Webanwendungen erlauben, die Same Origin-Richtlinie zu umgehen. Dazu kommunizieren die Proxy-Server mittels XMLHttpRequests mit einem Server aus einer dritten Domain. Viele Internet-Browser besitzen auÿ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 Angrie 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 document.write()-Funktion Benutzereingaben in eine Webseite einbaut ohne spezielle und potenziell gefä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 ungeltertem Pro- grammcode mit der eval()-Funktion. Der eingeschleuste Programmcode wird dann im Kontext des Dokumentes, in das er eingefügt wurde, ausgeführt und besitzt entsprechend alle Rechte des Dokumentes. Über diese Wege können bösartige Skripte, die beispielsweise den Benutzer auf eine Phishing-Seite weiterleiten oder Cookies auslesen, in eine Webseite eingebaut oder direkt ausgeführt werden.

Denial of Service-Angrie (DoS)

Im Internet-Browser ausgeführte Skripte können dazu führen, dass der Browser oder, in seltenen Fä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ällen zumindest das aktuelle Browserfenster oder die Netzwerkverbindung unbrauchbar. Ein solcher Angri 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 zu einem 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 Benutzer selbst beabsichtigt war. Um dieses Verhalten des Internet-Browsers auszunutzen, genügt es, wenn der bei einer Webanwendung authentisierte Benutzer eine Webseite mit bösartigem JavaScript- Programmcode besucht. Dieser Programmcode kann dann beliebige HTTP-Requests im Namen des authentisierten Nutzers an die Webandwendung schicken, da der Internet-Browser selbst- ständig die zur Authentisierung nötigen Informationen anfügt.

(7)

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 der Anfragen erst an den Webserver versendet werden, wenn der Benutzer dies mit einem Klick auf einen entsprechenden Button veranlasst. Mit XMLHttpRequests und der asynchronen Abarbei- tung der Anfragen hat eine Ajax-Anwendung dagegen die Möglichkeit, Daten an einen Server zu versenden ohne dass die Webseite erneut geladen wird oder der Benutzer auf andere Weise davon erfährt. Eine Phishing-Seite könnte mit dem regelmäÿigen Versenden von XMLHttpRequests an Benutzereingaben gelangen, selbst wenn sich der Benutzer später entscheidet die Eingaben nicht abzusenden.

Zusätzliche Bedrohungen bei Mashups

Auf Grund der Tatsache, dass Mashups aus mehreren Ajax-Anwendungen bestehen, sind auch Mashups von oben genannten Angrien bedroht. Mashups bieten jedoch noch zusätzliche An- grisziele: 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ösartigen Seite mit entsprechenden JavaScript-Anweisungen möglich, sowohl den Benutzer als auch die das Mashup 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 herausgeltert oder maskiert werden.

Desweiteren sollte nach Möglichkeit kein automatisch generierter, oder von unsicheren externen Quellen eingebunder, Programmcode ausgeführt werden. Um CSRF-Angrie zu erschweren, kann der Referrer-Header, der angibt von welcher Seite ein Request abgeschickt wurde, des HTTP- Requests validiert werden. Weitere Möglichkeiten CSRF-Angrie zu erschweren, bestehen darin, die Authentisierung mit Hilfe eines versteckten Feldes auf jedem Formular zu vollziehen oder ein weiteres, vom Server generiertes, Geheimnis einzuführen, das bei weiteren Requests des Benutzers mitgeschickt 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 und zum anderen aus ausführbarem Programmcode. Der Client muss den Flash-Player installiert haben und kann damit nach dem Download der SWF-Dateien deren Inhalte anzeigen aund ausführen. Der Flash-Player stellt dann die Laufzeitumgebung für die SWF-Applikationen dar und kontrolliert damit die Zugrie auf die Systemressourcen.

(8)

Sicherheit in Rich Internet Applications Adobe Flash-Player 3.2 ActionScript

ActionScript ist die Programmiersprache für die Flash-Player-Laufzeitumgebung und basiert auf dem ECMAScript-Standard. ActionScript-Code liegt in SWF-Dateien im Bytecode-Format vor und wird von der ActionScript Virtual Machine, die Teil des Flash-Players ist, ausgeführt.

Vor der Ausführung wird der Bytecode von veriziert und auf Vollständigkeit überprüft, so dass 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 komplexe Anwendungen 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 speziell dafür vorgesehenen, und mit pseudo-zufälligen Zeichen versehenen, Verzeichnis wird unter strenger Aufsicht der Laufzeitumgebung gestattet. Diese stellen einer SWF-Datei einen persistenten Speicher, vergleichbar mit Cookies, zur Verfügung und werden mit einer bestimmten SWF-Datei assoziiert. Weiterhin limitiert der Flash-Player die Gröÿe eines Shared Objects standardmäÿig auf 100KB, um Denial of Service-Angrie die auf dem Belegen von Speicherplatz basieren, zu erschweren.

Fehler im Programmablauf wie Puerüberläufe oder Endlosschleifen können von der Laufzeit- umgebung erkannt und verhindert oder abgebrochen werden. Dazu überwacht der Flash-Player die 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ÿerdem sorgt die Laufzeitumgebung für die Verwaltung und Zuteilung des Arbeitsspeichers an einzelne SWF-Anwendungen und die zugehörige Speicherbereinigung (Garbage Collection).

3.4 Sicherheitseinstellungen und Zugriskontrolle

Hierarchie der Zugriskontrolle Die Laufzeitumgebung unterscheidet zwischen vier unterschiedlichen Perso-

nengruppen: dem Administrator des Client-Computers, dem Benutzer des Client-Computers, dem Besitzer der Webseite, von dem die SWF-Datei stammt, und dem Autor der SWF-Datei. Jede dieser vier Personengrup- pen stellt Ressourcen bereit, für welche sie jeweils die Sicherheitseinstel- lungen und Zugrisberechtigungen vornehmen können. Diese Sicherheits- einstellungen und Zugrisberechtigungen 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. Die Sicherheitseinstellungen des Autors der SWF-Datei haben schlieÿlich die geringste Priorität. Schränkt beispielsweise der ausführende Benutzer den Zugri auf die von ihm bereitgestellten Ressourcen ein, so können weder die Sicherheitseinstellungen der Webseite noch die des Autors diese Sperre umgehen. Selbstverständlich kann eine SWF-Datei überhaupt nur dann auf andere Ressourcen zugreifen, wenn diese die gewünschten Zugrie erlauben.

Der eine SWF-Datei ausführende Benutzer ist in der Lage den Zugri der ausgeführten Datei auf eine zweite Ressource einzuschränken oder zu verbieten. Jede der erwähnten Gruppen hat auÿerdem die Möglichkeit, die Sicherheitseinstellungen für die von ihr bereitgestellten Ressourcen zu delegieren.

(9)

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 dabei eine Art logischer Container der Ressourcen beinhaltet. Jede SWF-Datei wird einer solchen Sandbox zugeordnet. Eine Sandbox legt sämtliche Zugrisrechte auf Ressourcen, basierend auf den Sicherheitseinstellungen der jeweiligen Ressourceninhaber, fest. Dazu gehören Zugrie auf Dateien und andere genutzte Ressourcen wie Video oder Audio. Jede dieser Sandboxen ist vom Betriebssystem, dem Dateisystem, anderen Anwendungen und den anderen Sandboxen isoliert.

Eine Sandbox pro Domain

Alle SWF-Dateien die derselben Sandbox zugeordnet werden, können vollkommen ungehindert untereinander Daten austauschen und auf Daten innerhalb der Sandbox zugreifen. Diese Zu- ordnung wird auf Grund der Domain, aus der die SWF-Datei stammt, getroen. Eine Sandbox reprä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 es ihr 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-Datei stammt, auisten. Zwei SWF-Dateien aus unterschiedlichen Sandboxen können ebenfalls nur interagieren, 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 jedoch asynchron statt, daher hat 'A' durch diese Einstellungen weiterhin keinen Zugri auf 'B'. An dieser Stelle greifen auÿerdem die Sicherheitseinstellungen und zugehörigen Prioritäten der vier oben beschriebenen Personengruppen. Die Einhaltung dieser zugestandenen Rechte wird von der Laufzeitumgebung strengstens überwacht. Das Senden von Daten über Sandboxen hinweg wird bei SWF-Dateien aus der Netzwerkdomäne in der Regel nicht von der Laufzeitumgebung kontrolliert es wird davon ausgegangen, dass die Daten beim Empfänger sicher weiterverarbeitet werden.

Die Zuordnung zur Sandbox trit der Flash-Player auf Grund der Informationen die von dem darunterliegenden Protokoll bereitgestellt werden. Daher kann beispielsweise beim Transport von SWF-Dateien mittels HTTP nicht davon ausgegangen werden, dass diese Informationen korrekt sind, da es durch einen Angri möglich wäre, die Zuordnung zwischen URL und zugehöriger IP-Adresse zu fälschen. Bei SWF-Dateien die mit HTTPS transportiert wurden, kann dagegen die Domaininformation veriziert werden. In der Standardeinstellung können daher mit HTTP transportierte Inhalte nicht auf Inhalte zugreifen, die mit HTTPS transportiert wurden, auch wenn 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 bisher 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

(10)

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 auf das lokale Dateisystem und den Zugri auf jede andere SWF-Datei. Um die Kommunikation mit den gewünschten Ressourcen zu ermöglichen, müssen diese wiederum die gewünschten Zu- grie 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 dieser Einschränkungen wird ausgeschlossen, dass zwei kooperierende SWF-Dateien, von denen je eine aus der local-with-lesystem- und der local-with-networking-Sandbox stammt, Daten aus dem lokalen Dateisystem über das Netzwerk versenden. Daten können daher nur mit Hilfe einer local-trusted-SWF-Datei von dem lokalen Dateisystem in das Netzwerk gelangen. Selbst Administratoren 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 jedoch 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-Sandbox in 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 Zugrie gewähren. Ohne die erwähnte Angabe beim Kompilieren ordnet der Flash-Player eine lokale SWF-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 bestehen entweder aus kompiliertem Bytecode (Flash/ActionScript) oder interpretiertem Skript

(11)

(DHTML/JavaScript) und werden wie herkömmliche Programme mit den jeweiligen Privilegien des Benutzers ausgeführt. Dadurch erhalten die Anwendungen Zugri auf viele Funktionen des Betriebssystems, die browserbasierten Anwendungen nicht zur Verfügung stünden. Dazu gehören beispielsweise Zugrie auf das Dateisystem und die Netzwerkkommunikation entsprechend den Rechten 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 Zertikat unterschrieben werden. Auf diese Weise kann vor der Installation die Integrität der Anwendung und die Iden- tität des Unterzeichners veriziert werden. AIR nutzt dann die Public-Key-Infrastruktur und den Zertikatsspeicher des Betriebssystems, um festzustellen ob dem Zertikat vertraut werden kann. Dazu muss der Benutzer entweder direkt dem zu prüfenden Zertikat vertrauen oder er vertraut einer Kette von Zertikaten. Hierbei ist jedes Zertikat der Kette vom darauolgenden Zertikat unterschrieben und das zu prüfende Zertikat wird so auf eine der Zertizierungsstellen Verisign oder Thawte zurückgeführt. Nur wenn eine dieser beiden Bedingungen erfüllt ist, kann der Unterzeichner und die Integrität der Installationsdatei veriziert werden.

Installation von AIR-Anwendungen

Die Installation von AIR-Anwendungen läuft unter strenger Kontrolle der Laufzeitumgebung und vollkommen unabhängig von einem Internet-Browser oder anderen Anwendungen ab. Eine Installation von AIR-Anwendungen auÿerhalb dieser Laufzeitumgebung ist nicht möglich. Durch diese vereinheitlichte Installationsprozedur kann sichergestellt werden, dass der Installationsvor- gang für alle Anwendungen sicher und konsistent verläuft. Dem Benutzer wird angezeigt, ob die Verikation der Signatur erfolgreich und die Integrität der Installationsdatei gegeben war.

Konnte die Signatur erfolgreich verziert werden, wird dem Benutzer der Name des Unterzeich- ners angezeigt. Andernfalls wird ihm deutlich gemacht, dass die Verkation nicht möglich war.

Auÿerdem wird dem Benutzer mitgeteilt, welche Rechte die Anwendung nach der Installation haben wird. Mit Hilfe der nun vorliegenden Informationen kann der Benutzer entscheiden, ob er fortfahren 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 in Abschnitt 3.5 erklärt, existieren dort domain-spezische Sandboxen und solche für lokale Dateien mit Zugri auf das Dateisystem oder das Netzwerk.

Zusätzliche application-Sandbox

AIR erweitert das Modell des Flash-Players um eine zusätzliche application-Sandbox. Dateien die nicht dieser application-Sandbox zugeordnet werden, erhalten dieselben Einschränkungen wie beim Flash-Player-Modell. Dateien die sich innerhalb dieser neu eingeführten Sandbox benden, erhalten dagegen von der Laufzeitumgebung alle Rechte die für AIR-Anwendungen verfügbar sind und vollen Zugri auf die AIR-APIs. Wie auch beim Sandbox-Modell des Flash-Players sind die Sandboxen voneinander isoliert und haben keinen Zugri auf Dateien und Daten aus einer anderen Sandbox.

(12)

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 zugeordnet werden. Der Zugri auf besondere AIR-APIs, die beispielsweise den Zugri auf das lokale Dateisystem 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 dem eigenen Dateisystem oder aus dem Netzwerk, zu laden. Diese aus anderen Quellen geladenen Dateien werden einer Sandbox entsprechend des Flash-Player-Modells zugeordnet. Inhalte die nicht 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, muss gewä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 nicht möglich, fremde Inhalte in die application-Sandbox zu laden oder Programmcode dynamisch zu erzeugen.

Sichere Kommunikation zwischen Sandboxen

An manchen Stellen ist es wünschenswert, dass Inhalte unterschiedlicher Sandbox miteinander kommunizieren 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-Sandbox eingerichtet wird, können Dateien von auÿerhalb der application-Sandbox die zur Verfügung gestellten Funktionen nutzen. Eine Brücke stellt damit ein Gateway zwischen den Inhalten aus unterschiedlichen 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, bereitstellen.

4.3 AIR-Anwendungen auf Basis von HTML

AIR-Anwendungen können ausschlieÿlich mit HTML und JavaScript erstellt werden. Dazu stellt AIR 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-API Gebrauch machen. Auÿerdem führt AIR zwei neue Attribute für die HTML-Elemente Frame und IFrame ein, die es ermöglichen Teile einer HTML-AIR-Anwendung so zu behandeln als wü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 Frame enthält dann die Hauptobjekte der Webanwendung und diese bleiben dort bestehen, solange dieses Frame nicht auf eine andere Seite navigiert wird. In weiteren untergeordneten Frames werden die 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 diese Inhalte 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-Sandbox stammender Programmcode mit den Rechten der application-Sandbox ausgeführt wird.

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

(13)

Sicherheit in Rich Internet Applications Microsoft Silverlight

die nicht aus der application-Sandbox stammen aber vorenthalten. Eine Brücke zwischen den untergeordneten Frames und der application-Sandbox ermöglicht eine sichere Kommunikation zwischen 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 bereitstellen kann, hängen die beim ausführenden Benutzer greifenden Sicherheitsmechanismen vom ausgelieferten Format ab.

Wurde die OpenLaszlo-Anwendung vom Server in eine SWF-Datei kompiliert, so wird diese 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 als DHTML-Datei vor, ist der Internet-Browser für die Ausführung und Anzeige verantwortlich.

Das Sicherheitsmodell der OpenLaszlo-Anwendung entspricht dann dem Sicherheitsmodell des ausführenden Internet-Browsers, insbesondere in Bezug auf das in der DHTML-Seite enthaltene JavaScript (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 CoreCLR genannt 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 von dem .NET Framework unterstützen Programmiersprache (u.a. C#, J#, VB.NET), in einer dynamischen 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 Benutzers ausgeführt, wobei jeweils die restriktiveren Rechte ausschlaggebend sind. Im Gegensatz zum

(14)

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 einzelne Methoden ausschlieÿlich transparent oder kritisch sein können.

Beim CoreCLR-Sicherheitsmodell muss sämtlicher von Benutzern ausgeführter Programmcode transparent sein, während der sogenannte Plattform-Code, also von der Silverlight-Plattform bereitgestellte Assemblies, sowohl transparente als auch kritische Methoden enthalten dürfen.

Daher dürfen Silverlight-Anwendungen ausschlieÿlich aus transparentem Programmcode bestehen.

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

Safe-critical Programmcode

Erlaubte Aufrufe Viele für Anwendungen wünschenswerte Funktionen, beispielsweise

der Zugri auf das Dateisystem, müssen jedoch als kritisch markiert und implementiert werden, da es nur kritischem Programmcode erlaubt 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 kritischen Programmcode eingezogen. Dieser als safe-critical bezeichnete Pro- grammcode stellt Methoden zur Verfügung, die als API zum kritischen Programmcode 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 kritische Methode weitergeben. Über den Umweg der safe-critical Methoden haben die Silverlight-Anwendungen so überwachten Zugri auf kritische Methoden und deren sehr viel weiter reichende Funktionalitäten.

Während Silverlight-Anwendungen ausschlieÿlich aus transparentem Programmcode bestehen dürfen, kann Plattform-Code auch aus safe- critical oder kritischem Programmcode bestehen. Die Entscheidung

ob eine Assembly safe-critical oder kritsche Methoden enthalten darf, trit die CoreCLR auf Grund des Verzeichnisses aus dem die Assembly geladen wurde und durch die Überprüfung der Signatur. Nur Assemblies die aus dem Silverlight-Installationsverzeichnis geladen und mit dem Microsoft-eigenen Schlüssel signiert wurden, werden dem Plattform-Code zugeordnet. Nicht von Microsoft stammende Assemblies können nicht mit diesem Schlüssel signiert sein und werden daher 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 auch Methoden versehen werden können. Ist eine Klasse mit einem dieser Attribute versehen, so gilt dieses für alle in der Klasse enthaltenen Methoden. Das Schlüsselwort SecurityCriticalAttribute markiert 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

(15)

Sicherheit in Rich Internet Applications Mozilla Prism

oder Klassen die nicht mit einem dieser Attribute versehen wurden, sind standardmäÿig transparent. Werden Methoden einer Silverlight-Anwendung mit einem der Attribute versehen, so hat dies keine Auswirkungen, da Anwendungen nur aus transparentem Programmcode bestehen dürfen.

Zusätzlich existieren auch die herkömmlichen Schlüsselwörter public, private, protected und internal, die bei der Frage nach der Rechtmäÿigkeit von Methodenaufrufen ebenfalls ausgewertet werden 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 markiert wurde.

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 kann nur von solchen Klassen erben, die auf derselben oder einer höheren Ebene angesiedelt sind, wobei der transparente Programmcode die höchste Ebene darstellt. So dürfen safe-critical Klassen von anderen safe-critical Klassen und transparenten Klassen, nicht aber von kritischen Klas- sen, erben. Da Silverlight-Anwendungen nur transparenten Programmcode enthalten, können die Klassen einer Anwendung nur von anderen Anwendungs-Klassen oder von transparenten Klassen des Plattform-Codes erben. Damit das Erben von einer bestimmten Klasse tatsächlich möglich ist, muss dies auch von der Oberklasse gestattet werden.

Ist es einer Klasse gestattet von einer anderen Klasse zu erben, dann können auch die geerbten virtuellen Methoden überschreiben werden. Transparente Klassen, und damit auch alle Klassen aus 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 von Interfaces. 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 zu lassen und sie auf ähnliche Weise zu verwenden. Die Webanwendungen werden nicht mehr in einem 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 beispielsweise 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 reduzierte Version des Internet-Browsers Firefox handelt, entspricht das Sicherheitsmodell von Prism dem des Firefox-Browsers.

Enthält eine Webanwendung Flash- oder Silverlightanwendungen und ist ein entsprechendes Plugin 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, dann kö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.

(16)

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 und JavaFX Mobile, ein Betriebssystem für mobile Geräte (Mobiltelefone u.ä.) mit integrierter Java- Laufzeitumgebung. Mit JavaFX erstellte Anwendungen können sowohl mit JavaFX Mobile, als auch 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 Spezikation, die eine Standard-API für Script-Engines deniert und 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-Klassen verwenden. 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 von JavaFX Script und JavaFX-Anwendungen. Auf diese Weise greifen für JavaFX-Anwendungen die Sicherheitsmechanismen der Java SE 6.

8.2 Sicherheitsmodell von Java SE 6

Sandbox durch Verier, ClassLoader und SecurityManager

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

Vor der Ausführung von Java-Code in der Java Virtual Machine (JVM), wird der Bytecode von einem Verier darauf hin überprüft, ob er konform zur Java-Spezikation ist. Der Verier überprüft dazu das Format des Bytecodes und stellt unter anderem sicher, dass Zeiger nicht ver- fälscht, Zugrisbeschränkungen nicht verletzt und Typen nicht auf unerlaubte Weise konvertiert werden. Zusätzlich wird durch den Verier gewährleistet, dass kein Überlauf des Aufrufstacks stattnden kann. Das Ausführen fremden Programmcodes durch Manipulieren einer Rücksprun- gadresse ist somit ausgeschlossen. Ist eine Klassendatei nicht verizierbar, wird eine Exception geworfen und der enthaltene Programmcode nicht ausgeführt.

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

Die JVM überwacht alle Zugrie auf kritische Systemressourcen und überläÿt die Entschei- dung der Rechtmäÿigkeit eines Zugries dem SecurityManager. Nur lokale, mit dem Befehl java ausgeführte, Anwendungen können auch ohne SecurityManager, und damit ohne dessen Zugris- kontrollmechanismen, gestartet werden. Entscheidungen über die Rechtmäÿigkeit eines Zugris delegiert 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 Speicher durch den Programmierer nicht mehr nötig ist. Diese Arbeiten werden zuverlässig von der JVM erledigt.

(17)

Sicherheit in Rich Internet Applications Sun JavaFX

Gemeinsam realisieren Verier, ClassLoader und SecurityManager das Java-Sandbox-Modell.

Durch das Zusammenspiel dieser Komponenten wird ausgeschlossen, dass eine Anwendung auf Systemressourcen 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 alle Anwendungen 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 auch vom Benutzer oder dessen Administrator festgelegt werden. So kann der Zugri auf einzelne Klassen teilweise oder vollständig erlaubt werden. Da mit Java 1.1 die Möglichkeit eingeführt wurde, Java-Archiv-Dateien (JAR) mit einem digitalen Zertikat zu signieren, können die Si- cherheitsrichtlinien auf Basis dreier unterschiedlicher Merkmale vorgenommen werden: Codebase vergibt 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 nur für bestimmte Benutzer zu vergeben.

(18)

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 Teil erweitern. Als Grundlage für viele RIAs dient Adobes Flash-Player, der in den meisten Fällen als Browser-Plugin installiert wird und den Adobe für die eigene Integrated Runtime um eine neue Sandbox erweitert hat. Auch OpenLaszlo kann die Quelldateien neben dem DHTML-Format in das Flash-Format kompilieren. Das Sicherheitsmodell von Microsofts Silverlight baut auf dem Transparenzmodell des .NET-Frameworks auf, das mit dem Konzept der CoreCLR gleichzeitig vereinfacht wird. Suns JavaFX nutzt dagegen die vorhandenen und weitreichenden Sicherheits- mechanismen der Java-Plattform. Mozillas Prism stellt unter den RIAs eine Ausnahme dar, da es 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 auch Sicherheitsmechanismen an, jedoch bieten die weitreichenden Funktionalitäten von JavaScript und die Komfort-Funktionen des Internet-Browsers eine vergleichsweise groÿe Angrisäche.

Im Moment benden sich RIAs noch am Anfang ihrer Entwicklung, so dass sicher auch im Be- reich der Sicherheitsmechanismen, insbesondere bei AIR und Silverlight, noch einige Änderungen anstehen 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 weiteren Verbreitung zeigen, auch wenn die bisherigen Konzepte durchaus schlüssig und vielversprechend sind.

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

(19)

Sicherheit in Rich Internet Applications Quellenangaben

10 Quellenangaben

JavaScript

JavaScript Security

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

JavaScript Security in Mozilla

http://www.mozilla.org/projects/security/components/jssec.html JavaScript/JScript Sicherheitsmodell

http://www.bsi.de/fachthem/sinet/gefahr/aktiveinhalte/denitionen/javascriptsichmodell.htm DHTML

Einführung in JavaScript und DOM http://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 SSL

http://www.repges.net/SSL/ssl.htm Was ist https? Was ist SSL?

http://www.mela.de/Unix/FAQ/#26 Ajax

Ajax and Mashup Security

http://www.openajax.org/whitepapers/Ajax%20and%20Mashup%20Security.html The XMLHttpRequest Object

http://www.w3schools.com/xml/xml_http.asp Ajax security A reality check

http://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 AJAX

http://ajax.sys-con.com/read/430930.htm A JavaScript DOS Attack

http://www.guyrutenberg.com/2007/11/23/a-javascript-dos-attack/

(20)

Sicherheit in Rich Internet Applications Quellenangaben Adobe Flash-Player

Adobe Flash Player 9 Security

http://www.adobe.com/devnet/ashplayer/articles/ash_player_9_security.pdf Adobe Flash Security and Adobe Enterprise Solutions

http://www.adobe.com/devnet/ashplayer/articles/ashsecurity.pdf Programming ActionScript 3.0, Chapter 17: FlashPlayer Security

http://download.macromedia.com/pub/documentation/en/ex/2/prog_actionscript30.pdf Creating more secure SWF web applications

http://www.adobe.com/devnet/ashplayer/articles/secure_swf_apps.html Adobe Integrated Runtime (AIR)

AIR Security

http://livedocs.adobe.com/labs/air/1/devappshtml/help.html?content=security_1.html Digitally signing an AIR le

http://livedocs.adobe.com/labs/air/1/devappshtml/

help.html?content=distributing_apps_13.html Adobe AIR Security

http://download.macromedia.com/pub/labs/air/air_security.pdf Adobe AIR HTML Security

http://download.macromedia.com/pub/labs/air/air_htmlsecurity.pdf OpenLaszlo

OpenLaszlo Architecture

http://www.openlaszlo.org/lps4/docs/deployers/deployers.architecture.html Laszlo Systems: Technology White Paper

http://www.openlaszlo.org/whitepaper/LaszloWhitePaper.pdf Mozilla Prism

Mozilla Labs: Prism

http://labs.mozilla.com/2007/10/prism/

Microsoft Silverlight

The Silverlight Security Model

http://blogs.msdn.com/shawnfa/archive/2007/05/09/the-silverlight-security-model.aspx Silverlight Security II: What Makes a Method Critical

http://blogs.msdn.com/shawnfa/archive/2007/05/10/

silverlight-security-ii-what-makes-a-method-critical.aspx Silverlight Security III: Inheritance

http://blogs.msdn.com/shawnfa/archive/2007/05/11/silverlight-security-iii-inheritance.aspx

(21)

Sicherheit in Rich Internet Applications Quellenangaben

Transparency as Least Privilege

http://blogs.msdn.com/shawnfa/archive/2007/10/30/transparency-as-least-privilege.aspx Silverlight Security Model Primer

http://devduck.spaces.live.com/blog/cns!15D0C43F1C8E7753!365.entry When the Opposite of Transparent isn't Opaque

http://blogs.msdn.com/shawnfa/archive/2005/08/31/458641.aspx Introducing Microsoft Silverlight 1.1 Alpha

http://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 Framework

http://msdn2.microsoft.com/en-us/library/bb404700.aspx Sun JavaFX

What Is JavaFX? Here's The Answer

http://www.psynixis.com/blog/2007/05/08/what-is-javafx-heres-the-answer/

Sun Radically Simplies Content Authoring - Previews JavaFX Script http://www.sun.com/aboutsun/pr/2007-05/sunash.20070508.2.xml Scripting for the Java Platform

http://java.sun.com/developer/technicalArticles/J2SE/Desktop/scripting/

JSR 223 and Scripting Java

http://www.judoscript.com/articles/jsr223.html JavaFX != JavaFX Script

http://weblogs.java.net/blog/joshy/archive/2007/09/javafx_javafx_s.html Java Scripting: JavaFX Script

http://developers.sun.com/events/techdays/presentations/locations-2007/

shanghai/java_track2/td_sha_javafx_lee.pdf Securing Java

http://www.securingjava.com

JDK 6 Security-related APIs & Developer Guides

http://java.sun.com/javase/6/docs/technotes/guides/security/