DHTML使得我们能够开发出功能强大的Web应用客户端，它具有跨浏览器兼容、可交互和可移植等特点。它的缺点是用户能够直接查看javascript代码。本文介绍如何运用ASP技术保护DHTML代码，防止有人窃取你的DHTML代码。
传统保护技术
众所周知，Web本质上是一种不安全的媒介。当用户访问Web应用或者打开Web页面时，所有客户端的代码（HTML，javascript源文件以及CSS样式）一般都要下载到客户端缓冲区。用户只需点击一下“查看源文件”就可以查看、分析和复制这些代码。
MSDN摘录了Wrox《Instant javascript》一书的部分内容，它指出了保护javascript代码的几种方法，具体请参见这里。
客户端javascript代码保护方法主要可以分成如下几类：
a）Microsoft的方法：Microsoft通过发布Windows Script Engine Version 5.0来解决客户端源代码保护问题。源代码通过一个ActiveX层编码（不是加密）。请参见Script Encoding with the Microsoft Script Engine Version 5.0。
这种方法的缺点是经过编码的代码只有IE 5.0+才能解码，而且他们坦率承认编码过程并非简单易行。如果你使用的是其他浏览器（包括IE浏览器的早期版本），你就不能通过浏览器访问脚本代码。
b）模糊代码（Code Obfuscation）：一些共享软件，比如Jammer以及JMyth，企图通过让代码变得难于阅读、让变量名字变得杂乱去防止有人偷窃javascript代码。这种方法的缺点在于，任何有决心的程序员都能够用全局搜索和替换工具轻松地打破这种保护，因为这只需把那些含义模糊的变量名字改成含义明确的变量名字即可。关于JAMMER的更多说明，请参见这里。
c）加密：有许多方案、工具能够有效地加密javascript代码。加密客户端javascript代码最主要的问题在于用来解密的脚本代码往往很容易取得，导致对代码实施反向工程非常容易。显然，这种方法不能阻止任何认真的程序员获取源代码。虽然我们可以用Java作为加密和解密过程的中间工具，但遗憾的是，Applet会给Web页面增加不必要的额外负荷，而且它会因为浏览器所用Java虚拟机版本的不同而无法正常运行。相对而言，DHTML却意味着快速、小巧、通用和可移植。
一种新方法
在试验WML（Wireless Markup Language）时，我想到了一种保护客户端源代码的新方法。在基于ASP的WML页面中，服务器端代码会有如下内容：
< % 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 >
......
可以看到，我们首先发送了一个WML头，使得无线浏览器认为该ASP页面实际上是一个WML页面。这种技术同样可以用来保护javascript源文件（.js文件）。
Netscape随着javascript 1.2的发布引入了对javascript源文件的支持。大多数支持该版本javascript的浏览器都支持javascript源文件（Internet Explorer 3.0+，Netscape 3.0+以及Opera 5.0）。动态HTML（DHTML）由javascript和CSS混合构成。CSS样式使得开发者能够自由地在浏览器窗口中表现各种页面元素，而javascript则提供了控制浏览器本身的必要功能。javascript是DHTML的关键组成部分。
下面我们通过例子来说明这种新的DHTML源代码保护方法。这个例子涉及三个文件：index.asp，js.asp以及global.asa。global.asa定义了一个auth会话变量，该变量用于验证请求javascript源文件的页面起源是否合法。这里选择使用会话变量的原因在于它用起来比较方便。
global.asa
Sub Session_OnStart
Session("auth") = False
End Sub
我曾经试过用HTTP_REFERER系统变量来验证发出请求的页面起源是否合法，后来发现这个变量可以通过telnet伪造，而且某些浏览器未能在运行时正确地显示出HTTP_REFERER变量。
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 >测试页面< /title >
< script language="javascript" type="text/javascript" SRC="js.asp" >< /script >
< /head >
< body >
< script language="javascript" >test();<
传统保护技术
众所周知，Web本质上是一种不安全的媒介。当用户访问Web应用或者打开Web页面时，所有客户端的代码（HTML，javascript源文件以及CSS样式）一般都要下载到客户端缓冲区。用户只需点击一下“查看源文件”就可以查看、分析和复制这些代码。
MSDN摘录了Wrox《Instant javascript》一书的部分内容，它指出了保护javascript代码的几种方法，具体请参见这里。
客户端javascript代码保护方法主要可以分成如下几类：
a）Microsoft的方法：Microsoft通过发布Windows Script Engine Version 5.0来解决客户端源代码保护问题。源代码通过一个ActiveX层编码（不是加密）。请参见Script Encoding with the Microsoft Script Engine Version 5.0。
这种方法的缺点是经过编码的代码只有IE 5.0+才能解码，而且他们坦率承认编码过程并非简单易行。如果你使用的是其他浏览器（包括IE浏览器的早期版本），你就不能通过浏览器访问脚本代码。
b）模糊代码（Code Obfuscation）：一些共享软件，比如Jammer以及JMyth，企图通过让代码变得难于阅读、让变量名字变得杂乱去防止有人偷窃javascript代码。这种方法的缺点在于，任何有决心的程序员都能够用全局搜索和替换工具轻松地打破这种保护，因为这只需把那些含义模糊的变量名字改成含义明确的变量名字即可。关于JAMMER的更多说明，请参见这里。
c）加密：有许多方案、工具能够有效地加密javascript代码。加密客户端javascript代码最主要的问题在于用来解密的脚本代码往往很容易取得，导致对代码实施反向工程非常容易。显然，这种方法不能阻止任何认真的程序员获取源代码。虽然我们可以用Java作为加密和解密过程的中间工具，但遗憾的是，Applet会给Web页面增加不必要的额外负荷，而且它会因为浏览器所用Java虚拟机版本的不同而无法正常运行。相对而言，DHTML却意味着快速、小巧、通用和可移植。
一种新方法
在试验WML（Wireless Markup Language）时，我想到了一种保护客户端源代码的新方法。在基于ASP的WML页面中，服务器端代码会有如下内容：
< % 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 >
......
可以看到，我们首先发送了一个WML头，使得无线浏览器认为该ASP页面实际上是一个WML页面。这种技术同样可以用来保护javascript源文件（.js文件）。
Netscape随着javascript 1.2的发布引入了对javascript源文件的支持。大多数支持该版本javascript的浏览器都支持javascript源文件（Internet Explorer 3.0+，Netscape 3.0+以及Opera 5.0）。动态HTML（DHTML）由javascript和CSS混合构成。CSS样式使得开发者能够自由地在浏览器窗口中表现各种页面元素，而javascript则提供了控制浏览器本身的必要功能。javascript是DHTML的关键组成部分。
下面我们通过例子来说明这种新的DHTML源代码保护方法。这个例子涉及三个文件：index.asp，js.asp以及global.asa。global.asa定义了一个auth会话变量，该变量用于验证请求javascript源文件的页面起源是否合法。这里选择使用会话变量的原因在于它用起来比较方便。
global.asa
Sub Session_OnStart
Session("auth") = False
End Sub
我曾经试过用HTTP_REFERER系统变量来验证发出请求的页面起源是否合法，后来发现这个变量可以通过telnet伪造，而且某些浏览器未能在运行时正确地显示出HTTP_REFERER变量。
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 >测试页面< /title >
< script language="javascript" type="text/javascript" SRC="js.asp" >< /script >
< /head >
< body >
< script language="javascript" >test();<
相关文章
 我来说两句 |
对此文章发表了评论 |
评论列表 （最新 评论仅限网友观点！）
推荐文章
