dhtml
Protecting Your DHTML Using ASP
by Jean - Luc David
CATEGORIES: Site Design, Scripting
ARTICLE TYPE: Tutorial Reader Comments
ABSTRACT
Article Rating
Useful
Innovative
Informative
100 responses
Dynamic HTML allows developers an opportunity to create powerful client web applications that are cross-browser compliant, interactive and portable. Unfortunately, when you publish to the web your JavaScript code is insecure. Your hard work can be viewed, downloaded and copied. This article will describe an experimental innovative method of securing your DHTML code using server authentication and "data streams". The method in question will prevent the end user from directly accessing the source code.
Article Discussion Rate this article Related Links Index Entries
ARTICLE
Abstract:
Dynamic HTML allows developers an opportunity to create powerful client web applications that are cross-browser compliant, interactive and portable. Unfortunately, when you publish to the web your JavaScript code is insecure. Your hard work can be viewed, downloaded and copied. If you are developing e-commerce applications, your business rules and practices may be exposed to prying eyes.
Traditional means of protecting JavaScript usually involve scrambling or obfuscating the code. These methods are highly ineffectual against any determined code-hacker.
This article will describe an experimental innovative method of securing your DHTML code using server authentication and "data streams". The method in question will prevent the end user from directly accessing the source code.
Introduction:
DHTML is fast becoming the de facto tool for creating powerful, cross-browser applications on the web. Microsoft has rallied behind the development of the DOM (Document Object Model) and Netscape has pushed forward with its support for the language with the release of the Netscape 6 browser. The power of DHTML is based in part by its ability to programmatically control any fourth generation browser without the need for additional plugins or executables.
As we all know, the web is fundamentally an insecure medium. All client based development code (HTML, JavaScript Source Files and Style Sheets) typically downloads into the user's cache when they access your web applications or web pages. The end user can simply click on "View Source" to view, analyze or copy your code. This is a basic limitation that we have all have to live with. Or do we?
I strongly feel that web developers should be given the choice whether or not to share their client based code. As your web applications become more powerful and versatile, so does the need to protect your intellectual property. Especially if your application is business oriented or you've spent months working on a unique or groundbreaking DHTML application.
Traditional protection techniques:
MSDN has published an excerpt of Wrox's Instant JavaScript book on their site that outlines a few options for protecting your JavaScript.
http://msdn.microsoft.com/library/partbook/instantj/privacyforscriptwriters.htm
The principal client JavaScript code protection schemes can be divided into the following categories:
a) The Microsoft Approach: Microsoft has tackled the challenge of protecting client source code with the release of the Microsoft Windows Script Engine Version 5.0. The source code is encoded (not encrypted) and filtered through an ActiveX layer.
http://msdn.microsoft.com/library/periodic/period99/scriptengine.htm
The disadvantage of this approach is that the encoding can only be deciphered with Microsoft's Internet Explorer 5.0+. They readily admit that the encoding process is not entirely foolproof. If you are using any other browser (including earlier releases of Internet Explorer), you will not be able to access the script through the browser.
b) Code Obfuscation: S