Dhtml| Source code DHTML enables us to develop powerful Web application clients that are cross-browser compatible, interoperable, and portable. Its disadvantage is that users can 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) is typically downloaded to the client buffer. Users can view, analyze, and copy the code simply by clicking the "View Source file".
MSDN extracts some of the Wrox "Instant JavaScript" book, which points out several ways to protect JavaScript code, see here.
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来. The source code is encoded (not encrypted) through an ActiveX layer. 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 a different browser (including an earlier version of IE), you cannot access the script code through the browser.
b Fuzzy codes (code obfuscation): Some shareware, such as Jammer and Jmyth, try to prevent someone from stealing JavaScript code by making it difficult to read and making variable names cluttered. The disadvantage of this approach is that any determined programmer can easily break this protection with a global search and replace tool, because it simply changes the name of the variable whose meaning is ambiguous to a variable name with a definite meaning. For more information about Jammer, see here.
c) Encryption: There are many scenarios and tools that can effectively encrypt JavaScript code. The main problem with encrypting client JavaScript code is that the scripting code used to decrypt it is often easy to get, making it easy to reverse engineer code. Obviously, this approach does not prevent any serious programmer from getting the source code. Although we can use Java as an intermediary tool for the encryption and decryption process, unfortunately, the applet will add unnecessary extra load to the Web page, and it will not function properly because of a different version of the Java Virtual machine used by the browser. 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-side code has 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 files (. js files).
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) is composed of JavaScript and CSS blends. CSS styles allow developers to freely display various page elements in a browser window, while JavaScript provides the necessary functionality to control the browser itself. 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. The reason why you choose to use session variables here is that it's easy 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 a request, and later found that the variable could be forged by Telnet, and that some browsers could not properly display the Http_referer variable 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 a separate directory, such as "/js/", where the line of code will read:
< script language= "Javascript" type= "Text/javascript" src= "/js/" ></script >
This can almost confuse anyone who attempts to acquire JavaScript source files. However, remember to set the name of the default paging file correctly in the 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 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 is legitimate. If so, close the browser cache, reset the session variables, and then send JavaScript code to the browser. If the request for js.asp is not from a reliable origin, the session variable Auth is false, and the program sends only a blank page with a copyright notice.
As a result, if a user attempts to download a JavaScript source file or use a JavaScript source file on another site, he gets only a blank page. In this way, we also implement control over who can access the DHTML source files.
If you want to protect the HTML code of the page's actual content on a Web page, you can create a js.asp file
