Dhtml| source code skillfully use ASP technology to protect DHTML source code
2001-8-18 Network pioneer
DHTML enables us to develop powerful Web application clients that are cross-browser compatible, interoperable, and portable. Its disadvantage is that the user can
Enough to view JavaScript code directly. This article describes how to use ASP technology to protect DHTML code to prevent someone from stealing your DHTML code.
Traditional protection Technology
As we all know, the web is inherently an insecure medium. When a user accesses a Web application or opens a Web page, all client code (HTML,
JavaScript source files and CSS styles are typically downloaded to the client buffer. Users can view, analyze, and duplicate the "view source" with just a click
Make the code.
MSDN extracts some of the Wrox "Instant JavaScript" book, which points out several ways to protect JavaScript code, specifically, see this
In
The client JavaScript code protection methods can be divided into the following categories:
A Microsoft approach: Microsoft solves client source code protection issues by publishing Windows Script Engine Version 5.0来. Source Code Pass
An ActiveX layer encoding (not encryption) is passed. See script Encoding with the Microsoft script Engine Version 5.0.
The disadvantage of this approach is that the encoded code only can be decoded by IE 5.0+, and they frankly acknowledge that the coding process is not straightforward. If you are using the other
Browsers (including earlier versions of IE), you can't access script code through the browser.
b) Fuzzy codes (code obfuscation): Some shareware, such as Jammer and Jmyth, attempt to make the code difficult to read, let the variable name
Become cluttered to prevent someone from stealing JavaScript code. The disadvantage of this approach is that any determined programmer can use a global search and replace tool to easily
To break this protection, because it simply changes the name of the variable whose meaning is ambiguous to a variable name with a definite meaning. For more information on Jammer, see
Over here.
c) Encryption: There are many scenarios and tools that can effectively encrypt JavaScript code. The main problem with encrypting client JavaScript code is the foot used to decrypt it.
This code is often easy to obtain, resulting in reverse engineering of the code is very easy. Obviously, this approach does not prevent any serious programmer from getting the source code. Although
However, we can use Java as an intermediary tool for the encryption and decryption process, but unfortunately, the applet will add unnecessary extra load to the Web page, and it will be
The Java Virtual machine version used by the browser does not work correctly. In contrast, DHTML means fast, compact, generic, and portable.
A new method
When experimenting with WML (Wireless Markup Language), I thought of a new way to protect client source code. In an ASP-based WML page, the server
The end code will have the following contents:
<% 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 >
......
As you can see, we first send a WML header so that the Wireless browser thinks that the ASP page is actually a WML page. This technique can also be used to protect
JavaScript source file (. js file).
Netscape has introduced support for JavaScript source files with the release of JavaScript 1.2. Most browsers that support this version of JavaScript support
JavaScript source files (Internet Explorer 3.0+,netscape 3.0+ and Opera 5.0). Dynamic HTML (DHTML) consists of JavaScript and CSS
Mix composition. CSS styles allow developers to freely display various page elements in a browser window, while JavaScript provides the necessary to control the browser itself
to function. JavaScript is a key component of DHTML.
Here's an example to illustrate this new DHTML source code protection method. This example involves three files: index.asp,js.asp and Global.asa.
Global.asa defines a AUTH session variable that is used to verify that the page origin of the request JavaScript source file is legitimate. Here you choose to use session change
The reason is that it is more convenient to use.
Global.asa
Sub Session_OnStart
Session ("auth") = False
End Sub
I have tried using Http_referer system variables to verify that the originating page originated from the request, and later found that the variable could be forged by Telnet, and
Some browsers failed to display the Http_referer variable correctly at run time.
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 Page </title >
< script language= "Javascript" type= "Text/javascript" src= "js.asp" ></script >
< BODY >
< script language= "Javascript" >test ();</script >
< br >
< a href= "index.asp" >reload</A >
</body >
Now let's analyze the index.asp. First, the program sets the AUTH session variable to "True", which indicates that the page of the request. js file should be trusted.
The next few response calls prevent browsers from caching index.asp pages.
Generally, the syntax for calling JavaScript source files in an HTML file is as follows:
< script language= "Javascript" src= "yourscript.js" ></script >
But in this case, we're calling an ASP page instead of a JavaScript source file:
< script language= "Javascript" type= "Text/javascript" src= "js.asp" ></script >
If you want to obscure the fact that the application is requesting an ASP page, you can rename the js.asp to index.asp (or default.asp), and then place the file in the
In a separate directory, such as "/js/," This line of code is changed to read:
< script language= "Javascript" type= "Text/javascript" src= "/js/" ></script >
This can almost confuse anyone who attempts to acquire JavaScript source files. However, please do not forget to set the default paging file correctly in the IIS server configuration.
Name.
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 the output of JavaScript functions ');
}
<%else% >
<!--The code is protected by copyright. All rights reserved-->
<%end if% >
Let's analyze how js.asp validates and sends JavaScript code. The program first checks the session variable AUTH to see if the origin of the request fits
Method. If so, close the browser cache, reset the session variables, and then browse to
