Aufbauend auf dem Artikel GWT: Evolution der Internet-Anwendung, in dem wir beschrieben haben, wie sich der Aufbau einer Internet-Anwendung durch den Einsatz von GWT ändert, betrachten wir in diesem und im folgenden Beitrag Sicherheitsaspekte, die bei der Erstellung einer GWT-Anwendung zu berücksichtigen sind.

Dabei sollen weniger die Angriffsformen wie Cross-Site Scripting, Forging Requests usw., sondern vielmehr die Daten und Logik, die der Entwickler durch die Verwendung von GWT potenziell nach außen freigibt, im Mittelpunkt stehen. Es ist nämclich wichtig, gründlich darüber nachzudenken, was an welcher Stelle in der Anwendung verwendet werden sollte und was nicht.

Wie im vorangehenden Artikel beschrieben, verlagert GWT einen Teil der Anwendungslogik und der Daten in den Client. Diese werden in den Web-Browser des Anwenders geladen und dort verwendet bzw. ausgeführt. Das bedeutet jedoch, dass der Nutzer prinzipiell vollen Zugriff auf die Daten hat: Da JavaScript nicht kompiliert, sondern im Quelltext in den Web-Browser geladen wird, ist es möglich, sowohl die Anwendungslogik als auch die Daten einzusehen und zu manipulieren.

Anwendungslogik

Der GWT-Compiler übersetzt den vom Entwickler geschriebenen Java-Code in JavaScript-Code. Nun ist es mit den integrierten Browser-Funktionen möglich, den JavaScript-Quellcode direkt im Browser aufzurufen. Das Ergebnis kann man sich im Screenshot ansehen:

Wir stellen fest, dass der Quelltext nicht einfach zu lesen ist. Die Funktionen beginnen mit dem Schlüsselwort function, ein allgemeines JavaScript-Keyword. Diesem folgt der Funktionsname. GWT benennt die Funktionen einfach nach den Buchstaben des Alphabets. Eine Funktion, die ursprünglich etwa create_user hieß, ist nun z.B. mit X bezeichnet.

Der einzige Schutz vor nicht autorisierten Blicken ist der sog. Obfuscated Code. Der Programmcode ist also so schlecht lesbar, dass es sehr schwierig ist, seine Logik nachzuverfolgen ("Security through Obscurity"). Das bedeutet jedoch keinesfalls, dass dies unmöglich ist. Es ist nur entsprechend aufwändiger. Mithilfe entsprechend spezialisierter Tools können diese Daten wieder in lesbaren Code überführt werden.

Für den Entwickler ergibt sich daraus die folgende Maxime:

„Code, der geheim bleiben sollte, darf nie im GWT-Teil der Anwendung landen.“

Der Entwickler muss sich also stets fragen, ob der gerade in der Entwicklung befindliche Code dazu geeignet ist, dass jemand, der Zugriff auf die Anwendung hat, ihn einsehen kann.

Zur Entscheidungsfindung sollte sich der Entwickler bezüglich des Codes die folgenden Fragen stellen:

Sind Geschäftslogiken enthalten, die das Unternehmen nicht verlassen sollten?

• Beispiele: Preisberechnungslogik einer Versicherung, Bewertungssysteme, Ranking in Suchmaschinen, usw.
• Risiko: Geschäftslogik kann z.B. von Konkurrenten eingesehen und zum Nachteil verwendet werden.

Ist sicherheitsrelevante Logik enthalten?

• Beispiele: Verschlüsselungsalgorithmen, Passwort-Prüfungen, Sicherheitsabfragen, etc.
• Risiko: Sicherheitsrelevante Logiken können eingesehen und damit auch gefälscht werden. Die Anwendung kann auf diese Weise kompromittiert werden.

Ist relevante Anwendungslogik enthalten?

• Beispiele: Validierungen, sonstige Prüfungen
• Risiko: Durch Einsicht in die Anwendungslogik sind Prüfungen umgehbar.

Änderungen an der Logik

Während die ersten beiden Punkte nie in GWT abgebildet werden sollten, ist bei der dritten Frage eine differenzierte Betrachtung nötig. Als zentrale Empfehlung muss hier gelten: Der Entwickler darf sich nicht allein auf die Prüfung, die im Browser-Code durchgeführt wurde, verlassen, sondern muss die gleiche Prüfung nochmals im Backend ausführen. Der im Browser laufende Code kann nämlich nicht nur betrachtet, sondern auch manipuliert werden. Hier beschränken sich die Manipulationsmöglichkeiten auf den eigenen Rechner des Angreifers, er kann also nicht den JavaScript-Code von anderen Nutzern, sondern nur das Verhalten des eigenen Browsers beeinflussen.

Folgendes Szenario ist denkbar: Der Angreifer schaltet beispielsweise die Validierung bei einem Dialog, der aus mehreren Teilschritten besteht, aus. Verlässt sich der Entwickler nun ausschließlich auf die Prüfungen der Daten, die in GWT durchgeführt werden, kann so eine nicht valide Dateneingabe bis zum Ende des Dialogs erzeugt werden. Der Angreifer kann den Dialog bis zum Ende durchlaufen und so Daten abspeichern oder abschicken, die nicht erwünscht oder sogar schädlich sind.

Abhilfe schafft hier eine doppelte Prüfung: einerseits auf Client-Seite durch GWT direkt im Browser, andererseits zusätzlich auf dem Server. Hier kommt der Vorteil einer GWT-Struktur zum Tragen, die bereits im letzten Artikel erwähnt wurde: Der Code, der der Prüfung zugrunde liegt, muss nur einmal geschrieben werden und kann sowohl im Client (GWT) als auch auf dem Server verwendet werden. Auf dem Server ist er manipulationssicher. Dennoch kann man sich im Normalfall die schnellere Reaktionszeit der im Browser laufenden GWT-Anwendung zunutze machen.

Im zweiten Artikel über Sicherheitsaspekte bei der Anwendungsentwicklung mit GWT beschäftigen wir uns mit Fragen der Datensicherheit und gefälschten HTTP-Anfragen.

//SEIBERT/MEDIA entwickelt mit GWT

Derzeit realisiert //SEIBERT/MEDIA zwei große Projekte mit GWT und hat bereits umfassende Erfahrungen gesammelt. Unser aktuelles Projekt TwentyFeet, das Auswertungs-Tool für professionelle Social-Media-Aktivitäten, gibt Ihnen einen kompakten Überblick über die Möglichkeiten des Frameworks.

Planen Sie ein Software-Projekt? Möchten Sie Ihre bestehende Applikation mit neuen Funktionen ausstatten oder optimieren? Die Entwickler von //SEIBERT/MEDIA/TECHNOLOGIES sind Experten in der Anwendungsentwicklung mit Java, GWT, Groovy & Grails und Perl und helfen Ihnen gerne weiter. Bitte sprechen Sie uns unverbindlich an!

Weiterführende Informationen

Security for GWT Applications
Sicherheitsaspekte in GWT-Anwendungen: Datensicherheit und gefälschte HTTP-Requests
GWT: Evolution der Internet-Anwendung
Dynamische Internet-Anwendungen: GWT im Projekteinsatz
Dynamische Internet-Anwendungen: GWT aus Entwicklerperspektive

Mehr über die Creative-Commons-Lizenz erfahren