巧用ASP技術保護DHTML源代碼
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，看看請求的起源是否合
法。如是，則關閉瀏覽器緩存，重新設置會話變量，然后向瀏覽器發送JavaScript代碼。如果對js.asp的請求不是來自可
靠的起源，會話變量auth是false，程序只發送一個帶有版權聲明的空白頁面。
其結果是，如果用戶企圖下載JavaScript源文件或者在另一個網站上使用JavaScript源文件，他得到的只是一個空白頁
面。這樣，我們也就實現了對誰可以訪問DHTML源文件的控制。
如果要在Web頁面中保護頁面實際內容的HTML代碼，你可以在js.asp文件中創建一個函數，如下所示：
function html(){
document.write('< html >< body >頁面內容< /body >< /html > ');
}
然后，主頁面只需簡單地調用一下html()即可構造出Web頁面。這種頁面只有在用戶啟用了瀏覽器的JavaScript支持之后才
會顯示。如果用戶查看這種頁面的源代碼，他看到的只有一個函數調用，而不會看到函數調用所返回的源代碼。
這種表現出兩種（或更多）不同類型文件特征的ASP可以稱為“混合ASP”。下面是JavaScript/ASP混合文件的一些特
點：
●JavaScript源文件直接發向瀏覽器，未經緩存。
●文件經過必要的驗證，防止了用戶下載源代碼。
●最終用戶不能直接訪問源代碼。
上面的代碼已經在Windows 98、Windows NT平臺的Personal Web Server以及IIS 4上進行了測試，在下列瀏覽器上代碼均
能流暢地運行：Netscape 4.7，Internet Explorer 5，Netscape 6以及Opera 5.0。
局限
和任何其他技術一樣，本文所介紹的技術也有其固有的局限。
▲ 會話變量：
在上面的例子中，我們使用會話變量驗證JavaScript源文件調用的起源。如果網站的訪問量非常高，這可能不是進行驗證
的最好方法。
每次用戶訪問Web頁面或Web應用時都要創建一個會話變量。服務器保持會話唯一標識符的默認時間是20分鐘。如果服務器
同時要為大量訪問者維持狀態信息，你可以想象出服務器的負載會有多高。
解決這個問題主要有兩種方法：
●在服務器上把會話超時時間設置得盡量小。此外，當代碼已經發送給瀏覽器之后，調用Session.Abandon釋放會話狀態信
息。這種方法適用于中小流量的網站。
●對于高流量的網站，建議通過GUID/數據庫結合維持會話狀態的方法進行驗證。
▲ 內存分配：
大多數基于Mozilla的瀏覽器都用Spidermonkey JavaScript引擎解釋執行JavaScript。這個引擎的優點包括：以解釋方式
執行代碼（與編譯方式相對應），動態垃圾收集機制（換句話說，自動釋放內存空間避免內存漏洞吞噬計算機資源）。
試試下面這個操作：運行上面的例子。函數執行之后，進入URL地址欄，選中URL并敲Enter，你可以看到此時函數并不執
行，瀏覽器顯示了一個JavaScript錯誤。然而，如果你點擊瀏覽器的刷新按鈕，函數將正常執行。
下面是產生這種情況的原因：JavaScript函數執行之后，由于瀏覽器假定需要時這些代碼仍舊可以從緩存獲得，于是它就
釋放了為JavaScript保留的內存。然而，ASP代碼禁止了瀏覽器緩存JavaScript代碼。由于瀏覽器不能再引用內存中的函
數，也不能再從緩存中獲取函數代碼，所以你就在按Enter鍵時看到了一個錯誤。
點擊瀏覽器的刷新按鈕時，瀏覽器將重新從服務器下載函數代碼并執行。如果代碼不再引用函數，則JavaScript引擎將釋
放函數。但有一種方法可以強制瀏覽器在內存中保留函數，即在程序執行期間始終激活對函數的引用。
▲ 早期的/不兼容的瀏覽器：
毫無疑問，本文所介紹的方法不適合JavaScript版本早于1.2的瀏覽器。解決辦法是編寫一個預先進行檢查的程序，由該程
序檢查用戶瀏覽器是否和你的Web應用兼容。
▲ 包截取：
理論上，只要企圖竊取代碼的人具有足夠的決心，他可以在代碼向瀏覽器發送時通過竊取數據包竊取代碼。然而，這項工
作所要耗費的時間和精力使得它幾乎成為不可能的事情。而且，如果你想要獲得百分之百安全的傳輸，還可以使用SSL。使
用SSL唯一的缺點在于應用只能在支持SSL的瀏覽器上運行。
■ 小結：
“混合ASP”技術的應用當然不會局限于ASP和JavaScript源文件。在理論上，它可以在許多服務器端腳本語言環境中應
用，比如CGI或者PHP。此外，這種技術理論上還可以用于保護其他文件，如圖形、聲音和文檔。例如，“混合ASP”文件完
全可以起到圖形文件的作用，具體方法是先驗證請求的起源，向瀏覽器發送正確的內容類型標識，然后從SQL數據庫提取并
發送BLOB字段的圖形文件。它在這方面的應用可以說是沒有止境的。
在未來的許多年里，JavaScript和DHTML仍將繼續發展，并繼續作為一種重要的Web開發工具而存在。W3C有望認可客戶端編
程工具的價值和重要性，并為了保護它而制定一個標準。
夠直接查看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，看看請求的起源是否合
法。如是，則關閉瀏覽器緩存，重新設置會話變量，然后向瀏覽器發送JavaScript代碼。如果對js.asp的請求不是來自可
靠的起源，會話變量auth是false，程序只發送一個帶有版權聲明的空白頁面。
其結果是，如果用戶企圖下載JavaScript源文件或者在另一個網站上使用JavaScript源文件，他得到的只是一個空白頁
面。這樣，我們也就實現了對誰可以訪問DHTML源文件的控制。
如果要在Web頁面中保護頁面實際內容的HTML代碼，你可以在js.asp文件中創建一個函數，如下所示：
function html(){
document.write('< html >< body >頁面內容< /body >< /html > ');
}
然后，主頁面只需簡單地調用一下html()即可構造出Web頁面。這種頁面只有在用戶啟用了瀏覽器的JavaScript支持之后才
會顯示。如果用戶查看這種頁面的源代碼，他看到的只有一個函數調用，而不會看到函數調用所返回的源代碼。
這種表現出兩種（或更多）不同類型文件特征的ASP可以稱為“混合ASP”。下面是JavaScript/ASP混合文件的一些特
點：
●JavaScript源文件直接發向瀏覽器，未經緩存。
●文件經過必要的驗證，防止了用戶下載源代碼。
●最終用戶不能直接訪問源代碼。
上面的代碼已經在Windows 98、Windows NT平臺的Personal Web Server以及IIS 4上進行了測試，在下列瀏覽器上代碼均
能流暢地運行：Netscape 4.7，Internet Explorer 5，Netscape 6以及Opera 5.0。
局限
和任何其他技術一樣，本文所介紹的技術也有其固有的局限。
▲ 會話變量：
在上面的例子中，我們使用會話變量驗證JavaScript源文件調用的起源。如果網站的訪問量非常高，這可能不是進行驗證
的最好方法。
每次用戶訪問Web頁面或Web應用時都要創建一個會話變量。服務器保持會話唯一標識符的默認時間是20分鐘。如果服務器
同時要為大量訪問者維持狀態信息，你可以想象出服務器的負載會有多高。
解決這個問題主要有兩種方法：
●在服務器上把會話超時時間設置得盡量小。此外，當代碼已經發送給瀏覽器之后，調用Session.Abandon釋放會話狀態信
息。這種方法適用于中小流量的網站。
●對于高流量的網站，建議通過GUID/數據庫結合維持會話狀態的方法進行驗證。
▲ 內存分配：
大多數基于Mozilla的瀏覽器都用Spidermonkey JavaScript引擎解釋執行JavaScript。這個引擎的優點包括：以解釋方式
執行代碼（與編譯方式相對應），動態垃圾收集機制（換句話說，自動釋放內存空間避免內存漏洞吞噬計算機資源）。
試試下面這個操作：運行上面的例子。函數執行之后，進入URL地址欄，選中URL并敲Enter，你可以看到此時函數并不執
行，瀏覽器顯示了一個JavaScript錯誤。然而，如果你點擊瀏覽器的刷新按鈕，函數將正常執行。
下面是產生這種情況的原因：JavaScript函數執行之后，由于瀏覽器假定需要時這些代碼仍舊可以從緩存獲得，于是它就
釋放了為JavaScript保留的內存。然而，ASP代碼禁止了瀏覽器緩存JavaScript代碼。由于瀏覽器不能再引用內存中的函
數，也不能再從緩存中獲取函數代碼，所以你就在按Enter鍵時看到了一個錯誤。
點擊瀏覽器的刷新按鈕時，瀏覽器將重新從服務器下載函數代碼并執行。如果代碼不再引用函數，則JavaScript引擎將釋
放函數。但有一種方法可以強制瀏覽器在內存中保留函數，即在程序執行期間始終激活對函數的引用。
▲ 早期的/不兼容的瀏覽器：
毫無疑問，本文所介紹的方法不適合JavaScript版本早于1.2的瀏覽器。解決辦法是編寫一個預先進行檢查的程序，由該程
序檢查用戶瀏覽器是否和你的Web應用兼容。
▲ 包截取：
理論上，只要企圖竊取代碼的人具有足夠的決心，他可以在代碼向瀏覽器發送時通過竊取數據包竊取代碼。然而，這項工
作所要耗費的時間和精力使得它幾乎成為不可能的事情。而且，如果你想要獲得百分之百安全的傳輸，還可以使用SSL。使
用SSL唯一的缺點在于應用只能在支持SSL的瀏覽器上運行。
■ 小結：
“混合ASP”技術的應用當然不會局限于ASP和JavaScript源文件。在理論上，它可以在許多服務器端腳本語言環境中應
用，比如CGI或者PHP。此外，這種技術理論上還可以用于保護其他文件，如圖形、聲音和文檔。例如，“混合ASP”文件完
全可以起到圖形文件的作用，具體方法是先驗證請求的起源，向瀏覽器發送正確的內容類型標識，然后從SQL數據庫提取并
發送BLOB字段的圖形文件。它在這方面的應用可以說是沒有止境的。
在未來的許多年里，JavaScript和DHTML仍將繼續發展，并繼續作為一種重要的Web開發工具而存在。W3C有望認可客戶端編
程工具的價值和重要性，并為了保護它而制定一個標準。