© Excellent backgrounds/Shutterstock.com
Java Magazin
JavaScript-Zugriff auf alle Computerressourcen ohne Browser-Plug-ins

JavaScript-Vollzugriff mit JSFS

Webentwickler sind auf der Clientseite in der Sandbox des Browsers gefangen und erhalten auch mit den Neuerungen von HTML5 nur eingeschränkten Zugriff auf die Hardware oder das Dateisystem. Wer mehr Rechte benötigt, beispielsweise, um einen USB-Kartenleser abzufragen, kann sich mit einem Applet, Flash-Plug-in oder ActiveX helfen. Nur ist der Einsatz dieser Techniken im Unternehmensrahmen oft unerwünscht. JSFS unterstützt Webanwendungen durch eine browserunabhängige, clientseitige Komponente, die speziell auf die Anforderungen zugeschnitten werden kann. Die Kommunikation zwischen Browser und JSFS-Komponenten erfolgt über HTTP(S). Auf diese Weise wird der Zugriff auf Computerressourcen ermöglicht, ohne dass Browsereinstellungen geändert werden müssen.

Wolfgang Imig


Im Folgenden wird die Architektur von JSFS (JavaScript File System Access [1]) vorgestellt und anhand eines einfachen Beispiels gezeigt, wie der Inhalt des Ordners Dokumente eines Windows-Anwenders aufgelistet werden kann. Anschließend folgen Sicherheitsüberlegungen mit möglichen Angriffsszenarien. Von zentraler Bedeutung ist die Kommunikationsschicht BYPS (Binary Portable Object Serialization [2]), die Browser, Webanwendung und JSFS-Komponenten miteinander verbindet. Ihre Möglichkeiten werden dargelegt, und Unterschiede zu REST [3] werden aufgezeigt. Abschließend wird JSFS mit der ähnlichen Lösung „Gibraltar“ [4] verglichen.

Architektur

Abbildung 1 zeigt den prinzipiellen Aufbau von JSFS. Auf dem Client läuft ein gewöhnlicher Webbrowser, der die Seiten der Webanwendung „Your Web Application“ anzeigt (Abb. 1, Web Request). Diese Anwendung benötigt Computerressourcen des Clients, die über HTML/JavaScript nicht erreichbar sind. Der Zugriff darauf erfolgt mithilfe des JSFS Agents, der als Hintergrundanwendung auf dem Client unter dem Anwenderkonto aktiv ist und über eine Long-Poll-Verbindung auf Anfragen wartet. Endpunkt der Verbindung ist der JSFS Dispatcher, eine Webanwendung, deren Aufgabe es ist, Browser und JSFS Agent zu verbinden.

Wenn der JavaScript-Code im Browser eine Ressource des Clients verwenden will, sendet er eine Anfrage (Abb. 1, Resource Request) an den JSFS Dispatcher. Der gibt sie an den JSFS Agent weiter, indem er auf dessen Long-Poll antwortet. Der JSFS Agent führt die Anfrage aus und übermittelt die Antwort im nächsten Long-Poll an den JSFS Dispatcher, der seinerseits die Anfrage des Browsers beantwortet. Die Kommunikation kann auch in der umgekehrten Richtung erfolgen, sodass der JSFS Agent eine Aktion im Browser auslöst. Dafür gibt es auch vom Browser eine Long-Poll-Verbindung zum JSFS Dispatcher, die der Übersichtlichkeit halber nicht eingezeichnet ist.

Man könnte den JSFS Dispatcher auch auf dem Client betreiben, was aber eine aufwändigere Installation zur Folge hätte und erzwingen würde, eine Java-Runtime mit Servlet Engine auf dem Client bereitzustellen – der JSFS Agent kann auch in C++ oder C# entwickelt werden. Außerdem könnten Angriffe auf den JSFS Dispatcher nicht vom Administrator erkannt werden (s. Abschnitt „Alternative zu JSFS: Gibraltar“).

Vorteilhaft wäre eine Verschmelzung von „Your Web Application“ und „JSFS Dispatcher“. Dies würde die Authentifizierungsprozedur vereinfachen. Allerdings müsste dafür erstere ebenfalls BYP...

Java Magazin
JavaScript-Zugriff auf alle Computerressourcen ohne Browser-Plug-ins

JavaScript-Vollzugriff mit JSFS

Webentwickler sind auf der Clientseite in der Sandbox des Browsers gefangen und erhalten auch mit den Neuerungen von HTML5 nur eingeschränkten Zugriff auf die Hardware oder das Dateisystem. Wer mehr Rechte benötigt, beispielsweise, um einen USB-Kartenleser abzufragen, kann sich mit einem Applet, Flash-Plug-in oder ActiveX helfen. Nur ist der Einsatz dieser Techniken im Unternehmensrahmen oft unerwünscht. JSFS unterstützt Webanwendungen durch eine browserunabhängige, clientseitige Komponente, die speziell auf die Anforderungen zugeschnitten werden kann. Die Kommunikation zwischen Browser und JSFS-Komponenten erfolgt über HTTP(S). Auf diese Weise wird der Zugriff auf Computerressourcen ermöglicht, ohne dass Browsereinstellungen geändert werden müssen.

Wolfgang Imig


Im Folgenden wird die Architektur von JSFS (JavaScript File System Access [1]) vorgestellt und anhand eines einfachen Beispiels gezeigt, wie der Inhalt des Ordners Dokumente eines Windows-Anwenders aufgelistet werden kann. Anschließend folgen Sicherheitsüberlegungen mit möglichen Angriffsszenarien. Von zentraler Bedeutung ist die Kommunikationsschicht BYPS (Binary Portable Object Serialization [2]), die Browser, Webanwendung und JSFS-Komponenten miteinander verbindet. Ihre Möglichkeiten werden dargelegt, und Unterschiede zu REST [3] werden aufgezeigt. Abschließend wird JSFS mit der ähnlichen Lösung „Gibraltar“ [4] verglichen.

Architektur

Abbildung 1 zeigt den prinzipiellen Aufbau von JSFS. Auf dem Client läuft ein gewöhnlicher Webbrowser, der die Seiten der Webanwendung „Your Web Application“ anzeigt (Abb. 1, Web Request). Diese Anwendung benötigt Computerressourcen des Clients, die über HTML/JavaScript nicht erreichbar sind. Der Zugriff darauf erfolgt mithilfe des JSFS Agents, der als Hintergrundanwendung auf dem Client unter dem Anwenderkonto aktiv ist und über eine Long-Poll-Verbindung auf Anfragen wartet. Endpunkt der Verbindung ist der JSFS Dispatcher, eine Webanwendung, deren Aufgabe es ist, Browser und JSFS Agent zu verbinden.

Wenn der JavaScript-Code im Browser eine Ressource des Clients verwenden will, sendet er eine Anfrage (Abb. 1, Resource Request) an den JSFS Dispatcher. Der gibt sie an den JSFS Agent weiter, indem er auf dessen Long-Poll antwortet. Der JSFS Agent führt die Anfrage aus und übermittelt die Antwort im nächsten Long-Poll an den JSFS Dispatcher, der seinerseits die Anfrage des Browsers beantwortet. Die Kommunikation kann auch in der umgekehrten Richtung erfolgen, sodass der JSFS Agent eine Aktion im Browser auslöst. Dafür gibt es auch vom Browser eine Long-Poll-Verbindung zum JSFS Dispatcher, die der Übersichtlichkeit halber nicht eingezeichnet ist.

Man könnte den JSFS Dispatcher auch auf dem Client betreiben, was aber eine aufwändigere Installation zur Folge hätte und erzwingen würde, eine Java-Runtime mit Servlet Engine auf dem Client bereitzustellen – der JSFS Agent kann auch in C++ oder C# entwickelt werden. Außerdem könnten Angriffe auf den JSFS Dispatcher nicht vom Administrator erkannt werden (s. Abschnitt „Alternative zu JSFS: Gibraltar“).

Vorteilhaft wäre eine Verschmelzung von „Your Web Application“ und „JSFS Dispatcher“. Dies würde die Authentifizierungsprozedur vereinfachen. Allerdings müsste dafür erstere ebenfalls BYP...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang