Protecting Your DHTML Using ASP

答案：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, 易做图yze 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: Shareware programs such as Jammer and JMyth attempt to dissuade the user from stealing javascript code by 易做图 the source code illegible and scrambling the variable names. The problem with these techniques is that any determined programmer could easily circumvent this protection by using global search and replace tools. It's simply a matter of changing the cryptic variable names into something more coherent. 

http://rzr.online.fr/jammer.htm 

c) Encryption: javascript can be encrypted with an impressive array of powerful encryption schemes. The fundamental problem with encrypting client side javascript is that the decryptor script is usually accessible and can be reverse engineered. This method will definitely not dissuade any serious programmer from uncovering your source code. Java can be used as an intermediary to the javascript encryption and decryption process. However, the applet will add unnecessary weight to the page and may not run properly depending on what version of the Java Virtual Machine the browser is using. Besides, DHTML is meant to be a quick, light, versatile and portable.

A new approach:
While experimenting with WML (Wireless Markup Language), I came upon a new way of protecting client source code. When you create an ASP driven WML page, the server-based code will look something like this:

<% Response.ContentType = "text/vnd.wap.wml" %>
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" "http://www.wapforum.org/DTD/wml_1.1.xml">
<wml>
etc.

Notice that we are initially sending a WML header to fool the wireless browser into thinking that the ASP page is actually a WML page. I opted to try out this technique using javascript Source files ( .JS ).

Netscape introduced the addition of javascript Source files with the release of javascript 1.2. Most browsers that support this version of javascript should support the javascript Source Files. (Internet Explorer 3.0+, Netscape 3.0+ and Opera 5.0).

Dynamic HTML (DHTML) is comprised of a mixture of javascript and Cascading Style Sheets. The style sheet gives the developer the freedom to precisely position anything in the browser window whereas the javascript code adds to the program the functionality necessary to control the browser itself. The javascript component is the crucial element in DHTML.

My technique requires three components: index.asp , js.asp and global.asa . The global.asa defines a session variable called " auth " which will be used to authenticate the origin of the document requesting the javascript Source file. I chose a session variable because of its ease of use. 

global.asa
Sub Session_OnStart
Session("auth") = False
End Sub

I also experimented with the use the HTTP_REFERER system variable as an alternate means of authenticating the origin of the requesting document. I subsequently found out through my research that this variable can be spoofed via telnet and certain browsers will not correctly di

上一个：一个奇怪的错误，大家要当心呀（花了我大半天的时间）！
下一个：加密QueryString数据