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 aclearcase/" target="_blank" >ccessing 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: Shareware programs such as Jammer and JMyth attempt to dissuade the user from stealing JavaScript code by making 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 display the HTTP_REFERER variable at runtime.

index.asp
<% Session("auth") = True
Response.Expires = 0
Response.Expiresabsolute = Now() - 1
Response.AddHeader "pragma","no-cache"
Response.AddHeader "cache-control","private"
Response.CacheControl = "no-cache"
%>
<html>
<head>
<title>Test</title>
<script language="Javascript" type="text/javascript" SRC="js.asp"></script>
</head>
<body>
<script language="Javascript">test();</script>
<br>
<a href="index.asp">reload</a>
</body>
</html>

Now let‘’s examine index.asp . First of all, by setting the session variable to " true ", I am indicating to the application that the originating document requesting the .JS file should be trusted. The Response calls that follow prevent the browser from caching index.asp .

Typically, a JavaScript Source File is called in an html file using the following syntax:

<script language="Javascript" src="yourscript.js"></script>

In our case, we are calling an Active Server Page rather than a JavaScript Source file:

<script language="Javascript" type="text/javascript" SRC="js.asp"></script>

If you want to obscure the fact that your application is accessing an Active Server Page, you can rename js.asp to index.asp (or default.asp ) and place this file in a separate directory (say " /js/ "). The end result will look something like this:

<script language="Javascript" type="text/javascript" SRC="/js/"></script>

This will likely confuse any person trying to retrieve your JavaScript Source file. Be sure that you correctly set the default document in IIS server configuration.

js.asp
<%
IF Session("auth") = True THEN
Response.ContentType = "application/x-javascript"
Response.Expires = 0
Response.Expiresabsolute = Now() - 1
Response.AddHeader "pragma","no-cache"
Response.AddHeader "cache-control","private"
Response.CacheControl = "no-cache"
Session("auth") = False
%>
function test(){
document.write(‘’This is a test of the Emergency Broadcast System.‘’);
}
<%ELSE%>
<!--This code is copyrighted. ©2001 All Rights Reserved-->
<%END IF%>

Here is a breakdown of how js.asp authenticates and delivers your JavaScript code. The application checks the session variable to see if it is requested from a trusted source. If it is, browser caching is disabled and the session variable is reset. Your JavaScript code is then allowed to reach the browser. If the js.asp file is not requested from a trusted source, the session variable " auth " will be false and the server will simply deliver a blank page with a copyright notice.

The end result is that if the user tries to download the JavaScript Source file or use the source file on another website, all they will get is a blank page. You can finally gain some control over who gets to access your DHTML.

If you wanted to protect the actual HTML in your web page, you can create a function in your js.asp file, which looks something like this:

function html(){
document.write(‘’<html><body>Your content goes here.<\/body><\/html> ‘’);
}

In your main page, you simply make a function call to html() to build your web page. The web page will only display if the end user enables JavaScript in their browser options. If they look at the source, they will only get the function call, not the source contained within the function call.

I‘’ve coined the term "Hybrid ASP" to denote an Active Server Page file that exhibits qualities or properties of two (or more) different file types. In this case, the lines have blurred as the ASP file behaves as both a client file and as a server file.

Here are a few characteristics of the JavaScript/Active Server Page Hybrid file:

The JavaScript Source file "streams" the code into browser memory without being cached
The file is authenticated which prevents end users from downloading your source code
The end user does not get direct access to the source code
The above code has been tested on the Windows 98 and Windows NT platforms using the Microsoft Personal Web Server and IIS4. The code worked flawlessly using the following browsers: Netscape 4.7, Internet Explorer 5, Netscape 6 and Opera 5.0.

The Limitations:
As with any technique, there are inherent limitations that need to be accounted for.

Session Variable:

In the example above, I make use of session variables to authenticate the origin of the JavaScript source file call. If your site has high traffic, this may not be the optimal choice for authentication.

Every time an end user accesses your web page or application, a session variable is created. The default period of time that the server will retain this unique identifier is 20 minutes. You can pretty much imagine the load on the server if it has to retain session states for a hundred thousand visitors at a time.

There are essentially two ways to cope with this problem:

Set the session timeout on the server to a very short interval and use Session.Abandon to release the session state on the server once the code has streamed into the browser. This solution may be applicable on low to medium traffic sites.
For high traffic sites, the authentication method I would opt for is a GUID/database solution to maintain session states.
Memory Allocation:

Most Mozilla based browsers interpret JavaScript using the Spidermonkey JavaScript Engine. Some of the advantages of this engine are that it executes the code run-time (as opposed to compiled code) and it dynamically executes garbage collection (in other words, frees up memory space to prevent your code from leaking and taking up all of your computer‘’s resources).

Try this experiment: Run the above example code. Once the function has executed, go to the URL bar, highlight the URL and hit Enter. You‘’ll notice that the function will not execute and a JavaScript error will appear. However, if you hit the Refresh button on the browser, the function will execute normally. Here is the reason why this is happening:

Once the functions have fired, the browser dynamically de-allocates memory reserved for the JavaScript code based on the assumption that the code can be retrieved in the browser cache if needed. However, our ASP code prevents the caching of our Hybrid .JS file. Since the browser no longer has the references to the functions in memory and can no longer retrieve the code from the cache, you get a glaring error.

When you hit the Refresh button on the browser, the page loads the code from the server into the browser memory and re-executes the functions. The JavaScript Engine de-allocates the function if the code no longer makes reference to it. There may be a way to force the browser to retain the function in memory by keeping alive the reference to the functions throughout the execution of your program.

Older/Incompatible Browsers:

It goes without saying that the technique will not work on pre-JavaScript 1.2 browsers. The workaround is to build a pre-detection routine that will redirect the user if their browser is incompatible with the web application you are building.

Packet Interception:

Theoretically, if an individual is determined enough, there may be a way of obtain the code on the packet level as it streams into the browser. The amount of time and effort required in deciphering the code at the bit level makes this highly unlikely scenario. If you wanted an entirely secure stream you could use SSL. The only perceivable drawback is that your application could only run on SSL enabled browsers.

Conclusion:
The Hybrid ASP file is certainly not limited to Active Server Pages or JavaScript Source Files. In theory, it can be used with many server-scripted languages such as CGI or PHP This technique can also theoretically be applied towards protecting other file types such as images, sounds and documents. For example, a Hybrid ASP file can feasibly act as an image file by first authenticating the source, passing the correct header and retrieving a BLOB from a SQL database. The possibilities in this regard are limitless.

JavaScript and DHTML will continue to grow and remain an integral web development tool for many years to come. Hopefully, W3C will recognize the value and importance of client-based code and introduce a standardized means protecting it.

原文转自：http://www.ltesting.net