© saicle/Shutterstock.com
PHP Magazin
Mit Obfuscators seinen JavaScript-Code schützen

Getarntes JavaScript

Entweder man liebt sie, oder man hasst sie: Die View-Source-Option ermöglicht Nutzern und Entwicklern die Analyse der hinter einer Webapplikation stehenden Logik. Mit Obfuscators kann man bis zu einem gewissen Grad gegensteuern, um geistiges Eigentum vor neugierigen Konkurrenten zu schützen.

Tam Hanna


Das Feld der Obfuscation von JavaScript ist weit: Es reicht von einfachen Minimierungswerkzeugen bis zu kompletten serverbasierten Lösungen. In diesem Artikel möchte ich Ihnen einige Möglichkeiten konzeptuell vorstellen, damit Sie mehr über die verschiedenen Vorgehensweisen erfahren. Schon an dieser Stelle sei angemerkt, dass Obfuscators keinen Ersatz für eine serverseitige Verifikation darstellen. Ein als Fuzzing bezeichnetes Verfahren erlaubt Angriffe gegen extrem komplizierte Protokolle – der Ratschlag, vom Client eingehende Informationen als toxisch zu betrachten, gilt auch bei Verwendung aller in diesem Artikel besprochenen Methoden.

Mit Brachialgewalt

Wie so oft in der Welt der Informatik gilt auch hier, dass es keine universell sichere Lösung gibt. Die Aufgabe aller besprochenen Verfahren ist, einen Angriff so teuer zu machen, dass er sich für Hacker nicht lohnt. Hat man es mit extrem empfindlichem oder fragwürdigem geistigen Eigentum zu tun, so ist die Nutzung von Obfuscators oft nicht ausreichend. In diesem Fall empfiehlt es sich, auf eine Client-Server-Architektur zu setzen. Ein Beispiel dazu ist in Abbildung 1 zu sehen, bei der ein fiktives Berechnungsprogramm in zwei Komponenten aufgeteilt wird.

Abb. 1: Liegt die Logik am Server, ist der Clientcode weitgehend wertlos

Diese auf den ersten Blick seltsame Vorgehensweise ist in Zeiten von WebSocket und Co. problemlos implementierbar. Überraschenderweise beklagen sich Nutzer in der Praxis nur wenig, wenn ihr Programm ohne Netzwerkverbindung nicht funktioniert. Der Autor testete das unter Firefox OS: Trotz permanenter Verbindung zum Server erhielt der hauseigene wissenschaftliche Taschenrechner beste Bewertungen. In eine ähnliche Kerbe schlägt die Nutzung eines Produkts wie beispielsweise Emscripten. Das von Alon Zakai entwickelte Framework erlaubt die Kompilation von C-Code, der danach in einer virtuellen Maschine zur Ausführung kommt.

Der Code befindet sich zwar auf der Maschine des Klienten, ist aber extrem schwer zu analysieren. Emscripten-Code ist von der Komplexität her mit Qt und Co. vergleichbar. Beschwerden über Disassembler-Attacken auf C++-Programme findet man, anders als in der Welt von Java oder .NET, nur sehr selten.

Eine Frage des Konzepts

Möchten Sie nicht auf Brachialmethoden setzen, so steht eine Vielzahl von Obfuscators zur Verfügung. Sie verhalten sich im Großen und Ganzen so, wie man es aus der Java-Welt kennt. Links kommt lesbarer Code in die Blackbox, die auf der anderen Seite ver...

PHP Magazin
Mit Obfuscators seinen JavaScript-Code schützen

Getarntes JavaScript

Entweder man liebt sie, oder man hasst sie: Die View-Source-Option ermöglicht Nutzern und Entwicklern die Analyse der hinter einer Webapplikation stehenden Logik. Mit Obfuscators kann man bis zu einem gewissen Grad gegensteuern, um geistiges Eigentum vor neugierigen Konkurrenten zu schützen.

Tam Hanna


Das Feld der Obfuscation von JavaScript ist weit: Es reicht von einfachen Minimierungswerkzeugen bis zu kompletten serverbasierten Lösungen. In diesem Artikel möchte ich Ihnen einige Möglichkeiten konzeptuell vorstellen, damit Sie mehr über die verschiedenen Vorgehensweisen erfahren. Schon an dieser Stelle sei angemerkt, dass Obfuscators keinen Ersatz für eine serverseitige Verifikation darstellen. Ein als Fuzzing bezeichnetes Verfahren erlaubt Angriffe gegen extrem komplizierte Protokolle – der Ratschlag, vom Client eingehende Informationen als toxisch zu betrachten, gilt auch bei Verwendung aller in diesem Artikel besprochenen Methoden.

Mit Brachialgewalt

Wie so oft in der Welt der Informatik gilt auch hier, dass es keine universell sichere Lösung gibt. Die Aufgabe aller besprochenen Verfahren ist, einen Angriff so teuer zu machen, dass er sich für Hacker nicht lohnt. Hat man es mit extrem empfindlichem oder fragwürdigem geistigen Eigentum zu tun, so ist die Nutzung von Obfuscators oft nicht ausreichend. In diesem Fall empfiehlt es sich, auf eine Client-Server-Architektur zu setzen. Ein Beispiel dazu ist in Abbildung 1 zu sehen, bei der ein fiktives Berechnungsprogramm in zwei Komponenten aufgeteilt wird.

Abb. 1: Liegt die Logik am Server, ist der Clientcode weitgehend wertlos

Diese auf den ersten Blick seltsame Vorgehensweise ist in Zeiten von WebSocket und Co. problemlos implementierbar. Überraschenderweise beklagen sich Nutzer in der Praxis nur wenig, wenn ihr Programm ohne Netzwerkverbindung nicht funktioniert. Der Autor testete das unter Firefox OS: Trotz permanenter Verbindung zum Server erhielt der hauseigene wissenschaftliche Taschenrechner beste Bewertungen. In eine ähnliche Kerbe schlägt die Nutzung eines Produkts wie beispielsweise Emscripten. Das von Alon Zakai entwickelte Framework erlaubt die Kompilation von C-Code, der danach in einer virtuellen Maschine zur Ausführung kommt.

Der Code befindet sich zwar auf der Maschine des Klienten, ist aber extrem schwer zu analysieren. Emscripten-Code ist von der Komplexität her mit Qt und Co. vergleichbar. Beschwerden über Disassembler-Attacken auf C++-Programme findet man, anders als in der Welt von Java oder .NET, nur sehr selten.

Eine Frage des Konzepts

Möchten Sie nicht auf Brachialmethoden setzen, so steht eine Vielzahl von Obfuscators zur Verfügung. Sie verhalten sich im Großen und Ganzen so, wie man es aus der Java-Welt kennt. Links kommt lesbarer Code in die Blackbox, die auf der anderen Seite ver...

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