Protect DHTML Source Codes with ASP Technology

Using ASP code technology to protect the original author DHTML Source: Panasonic customer 01-5-25 01:52:57 PM

DHTML makes us develop a powerful web application client, which has features that cross-browser compatibility, interactive and portable. Its disadvantage is that users can directly view JavaScript code. This article describes how to use ASP technology to protect DHTML code to prevent someone from stealing your DHTML code.

Traditional protection technology

It is well known that the Web is essentially an insecure medium. When the user accesses the web app or open the web page, all client's code (HTML, JavaScript source file, and CSS style) generally download to the client buffer. Users only need to click "View Source File" to view, analyze, and copy these code.

MSDN extracts some of the contents of the Wrox "Instant JavaScript", which points out several ways to protect JavaScript code, please refer to here.

The client JavaScript code protection method can be divided into the following categories:

a) Microsoft method: Microsoft solves the client source code protection issue by issuing Windows Script Engine Version 5.0. The source code is encoded by an ActiveX layer (not encrypted). See Script Encoding With The Microsoft Script Engine Version 5.0.

The disadvantage of this method is that only IE 5.0 encoded is only IE 5.0 , and they frankly admit that the encoding process is not easy. If you are using other browsers (including earlier versions of the IE browser), you cannot access script code through your browser.

b) Code Obfuscation: Some sharing software, such as Jammer, and JMyth, attempting to make the code difficult to read, let the variable name make someone to steal the JavaScript code. The disadvantage of this approach is that any determined programmer can easily break this protection with global search and replacement tools, as this only needs to change the meaning of the implicit variable name to a meaningful variable name. For more description of Jammer, see here.

c) Encryption: There are many scenarios, tools can effectively encrypt JavaScript code. The most important issue of encrypting client JavaScript code is that the script code used to decrypt is often easily achieved, resulting in the implementation of reverse project to the code. Obviously, this approach cannot prevent any serious programmers from get the source code. Although we can use Java as an intermediate tool for encryption and decryption, the applet will add unnecessary additional loads to the web page, and it will not function properly because the browser uses the Java virtual machine version. Relatively speaking, DHTML means fast, small, general and portable.

A new method

When testing WML (Wireless Markup Language), I thought of a new way to protect client source code. On the ASP-based WML page, the server-side code will have the following:



<% Response.contentType = "text / vnd.wap.wml"%>

"http://www.wapforum.org/dtd/wml_1.1.xml">

......



It can be seen that we first sent a WML head to make the wireless browser considered that the ASP page was actually a WML page. This technique can also be used to protect the JavaScript source file (.js file).

Netscape introduces support for JavaScript source files with the release of JavaScript 1.2. Most of the browsers that support this version 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. The CSS style enables developers to freely represent various page elements in the browser window, while JavaScript provides the necessary functions of the browser itself. JavaScript is a key component of DHTML.

Below we will explain this new DHTML source code protection method. This example involves three files: Index.asp, JS.ASP, and Global.asa. Global.asa defines an Auth session variable that is used to verify that the page origin of the request JavaScript source file is legal. The reason for choosing a session variable here is that it is relatively convenient.



Global.asa



SUB session_onstart

Session ("auth") = false

End Sub



I have tried the HTTP_REFERER system variable to verify whether the origin of the requested page is legal, and then discovered that this variable can be faked through Telnet, and some browsers cannot correctly display the http_referer variable when running.



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"

%>