© Liashko/Shutterstock.com
Entwickler Magazin
Security mit GWT

Sicherer Webzeugkasten

Wie jede Webapplikation sind natürlich auch solche mit Clients, die auf dem Google Web Toolkit (GWT) basieren, angreifbar. JavaScript-Applikationen stellen in mancher Hinsicht speziellere Ansprüche an die Absicherung. GWT unterstützt den Entwickler in vielen Bereichen bei der Einhaltung von Sicherheitsrichtlinien, dennoch bleiben ein paar Angriffsvektoren übrig, die man nicht außer Acht lassen sollte.

Christian Proinger


GWT ermöglicht es Entwicklern, sich beim Entwickeln von Rich Internet Applications (RIA) auf die Wünsche und Anforderungen ihrer Nutzer zu konzentrieren, statt sich mit JavaScript- und Browser-Eigenheiten beschäftigen zu müssen. Dennoch ist es gerade bei der Sicherheit wichtig, dass man die Basics versteht. Wie ein Browser arbeitet und was JavaScript-Code darf und was nicht, sollte man zumindest grob im Hinterkopf haben. Zweier grundlegender Sicherheitskonzepte muss man sich beim Entwickeln bewusst sein, wenn man den Gedankenschritt von Anwendungen, die auf statischem HTML basieren, hin zu JavaScript-basierten, macht: der Same-Origin Policy und dem dynamischen Hinzufügen von HTML-Elementen.

Die Same-Origin Policy besagt im Prinzip, dass Code, der von Seite A geladen wurde, auf keine Ressourcen von Seite B zugreifen darf. Durch diese Restriktion kann man zum Beispiel nicht ohne Weiteres [1] einen XMLHTTPRequest an eine andere Seite stellen. Das Ziel dabei ist es, zu verhindern, dass bösartiger Code, der von einer kompromittierten Seite A heruntergeladen wird, Daten, die mir z. B. gerade im Browser angezeigt werden, stiehlt und sie an Seite B weiterleitet.

Manchmal ist diese Einschränkung allerdings hinderlich, weshalb es mehrere Möglichkeiten gibt, diese Restriktion zu umgehen:

document.domain Property [2]: Diese Technik kann verwendet werden, wenn JavaScript-Code zweier Frames von verschiedenen Sub-Domains zusammenarbeiten soll. Ein Zugriff auf eine gänzlich andere Domain ist aber nicht möglich.Cross-Document Messaging [3]: Wenn JavaScript-Code von verschiedenen Domains miteinander interagieren soll, kann das mittels Message-Passing (document.postMessage(data)) erreicht werden. Dabei werden nicht Eigenschaften anderer Frames gelesen und geschrieben, sondern nur Nachrichten ausgetauscht.Cross-Origin Resource Sharing [4]: Durch die Angabe diverser Access-Control-HTTP-Response-Header können Requests an bestimmte andere Hosts erlaubt werden. Dies wird zum Beispiel verwendet, um Requests auf andere Sub-Domains zu erlauben (z. B. Seite wird geladen von www.static.mycompany.com und greift zu auf www.service.mycompany.com).JSONP [5]: Bei dieser Technik werden HTML-script-Elemente dynamisch zur Seite hinzugefügt. Der URL-parameterabhängig erzeugte JavaScript-Code, auf den das script-src-Attribut verweist, enthält einen Methodenaufruf.

Die letzte der angeführten Techniken zur Same-Origin-Policy-Umgehung deutet schon auf einen potenziellen Gefahrenherd hin. Mit JavaSc...

Entwickler Magazin
Security mit GWT

Sicherer Webzeugkasten

Wie jede Webapplikation sind natürlich auch solche mit Clients, die auf dem Google Web Toolkit (GWT) basieren, angreifbar. JavaScript-Applikationen stellen in mancher Hinsicht speziellere Ansprüche an die Absicherung. GWT unterstützt den Entwickler in vielen Bereichen bei der Einhaltung von Sicherheitsrichtlinien, dennoch bleiben ein paar Angriffsvektoren übrig, die man nicht außer Acht lassen sollte.

Christian Proinger


GWT ermöglicht es Entwicklern, sich beim Entwickeln von Rich Internet Applications (RIA) auf die Wünsche und Anforderungen ihrer Nutzer zu konzentrieren, statt sich mit JavaScript- und Browser-Eigenheiten beschäftigen zu müssen. Dennoch ist es gerade bei der Sicherheit wichtig, dass man die Basics versteht. Wie ein Browser arbeitet und was JavaScript-Code darf und was nicht, sollte man zumindest grob im Hinterkopf haben. Zweier grundlegender Sicherheitskonzepte muss man sich beim Entwickeln bewusst sein, wenn man den Gedankenschritt von Anwendungen, die auf statischem HTML basieren, hin zu JavaScript-basierten, macht: der Same-Origin Policy und dem dynamischen Hinzufügen von HTML-Elementen.

Die Same-Origin Policy besagt im Prinzip, dass Code, der von Seite A geladen wurde, auf keine Ressourcen von Seite B zugreifen darf. Durch diese Restriktion kann man zum Beispiel nicht ohne Weiteres [1] einen XMLHTTPRequest an eine andere Seite stellen. Das Ziel dabei ist es, zu verhindern, dass bösartiger Code, der von einer kompromittierten Seite A heruntergeladen wird, Daten, die mir z. B. gerade im Browser angezeigt werden, stiehlt und sie an Seite B weiterleitet.

Manchmal ist diese Einschränkung allerdings hinderlich, weshalb es mehrere Möglichkeiten gibt, diese Restriktion zu umgehen:

document.domain Property [2]: Diese Technik kann verwendet werden, wenn JavaScript-Code zweier Frames von verschiedenen Sub-Domains zusammenarbeiten soll. Ein Zugriff auf eine gänzlich andere Domain ist aber nicht möglich.Cross-Document Messaging [3]: Wenn JavaScript-Code von verschiedenen Domains miteinander interagieren soll, kann das mittels Message-Passing (document.postMessage(data)) erreicht werden. Dabei werden nicht Eigenschaften anderer Frames gelesen und geschrieben, sondern nur Nachrichten ausgetauscht.Cross-Origin Resource Sharing [4]: Durch die Angabe diverser Access-Control-HTTP-Response-Header können Requests an bestimmte andere Hosts erlaubt werden. Dies wird zum Beispiel verwendet, um Requests auf andere Sub-Domains zu erlauben (z. B. Seite wird geladen von www.static.mycompany.com und greift zu auf www.service.mycompany.com).JSONP [5]: Bei dieser Technik werden HTML-script-Elemente dynamisch zur Seite hinzugefügt. Der URL-parameterabhängig erzeugte JavaScript-Code, auf den das script-src-Attribut verweist, enthält einen Methodenaufruf.

Die letzte der angeführten Techniken zur Same-Origin-Policy-Umgehung deutet schon auf einen potenziellen Gefahrenherd hin. Mit JavaSc...

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