dhtml|原始碼 巧用ASP技術保護DHTML原始碼
2001-8-18 動網先鋒
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();< /script >
< br >
< a href="index.asp" >reload< /a >
< /body >
< /html >
下面我們來分析一下index.asp。首先，程式把auth會話變數設定成了“true”，它表示請求.js檔案的頁面應該被信任。
接下來的幾個Response調用防止瀏覽器緩衝index.asp頁面。
一般地，在HTML檔案中調用JavaScript源檔案的文法如下：
< script language="Javascript" src="yourscript.js" >< /script >
但在本例中，我們調用的卻是一個ASP頁面而不是JavaScript源檔案：
< script language="Javascript" type="text/javascript" SRC="js.asp" >< /script >
如果要遮掩應用正在請求ASP頁面這一事實，你可以把js.asp改名為index.asp（或者default.asp），然後把這個檔案放到
單獨的目錄之中，比如“/js/”，此時上面這行代碼就改為：
< script language="Javascript" type="text/javascript" SRC="/js/" >< /script >
這幾乎能夠迷惑任何企圖擷取JavaScript源檔案的人了。不過，請不要忘記在IIS伺服器配置中正確地設定預設分頁檔的
名字。
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('這是javascript函數的輸出.');
}
< %ELSE% >
< !--這些代碼受著作權保護。所有權利保留-- >
< %END IF% >
下面我們來分析一下js.asp如何進行驗證以及發送JavaScript代碼。程式首先檢查會話變數auth，看看請求的起源是否合
法。如是，則關閉瀏覽器緩衝，重新設定會話變數，然後向瀏覽
