傳統(tǒng)保護技術眾所周知，Web本質上是一種不安全的媒介。當用戶訪問Web應用或者打開Web頁面時，所有客戶端的代碼(HTML，JavaScript源文件以及CSS樣式)一般都要下載到客戶端緩沖區(qū)。用戶只需點擊一下“查看源文件”就可以查看、分析和復制這些代碼。
客戶端JavaScript代碼保護方法主要可以分成如下幾類：
a)Microsoft的方法：Microsoft通過發(fā)布Windows Script Engine Version 5.0來解決客戶端源代碼保護問題。源代碼通過一個ActiveX層編碼(不是加密)。這種方法的缺點是經(jīng)過編碼的代碼只有IE 5.0+才能解碼，而且他們坦率承認編碼過程并非簡單易行。如果你使用的是其他瀏覽器(包括IE瀏覽器的早期版本)，你就不能通過瀏覽器訪問腳本代碼。
b)模糊代碼(Code Obfuscation)：一些共享軟件，比如Jammer以及JMyth，企圖通過讓代碼變得難于閱讀、讓變量名字變得雜亂去防止有人偷竊JavaScript代碼。這種方法的缺點在于，任何有決心的程序員都能夠用全局搜索和替換工具輕松地打破這種保護，因為這只需把那些含義模糊的變量名字改成含義明確的變量名字即可。
c)加密：有許多方案、工具能夠有效地加密JavaScript代碼。加密客戶端JavaScript代碼最主要的問題在于用來解密的腳本代碼往往很容易取得，導致對代碼實施反向工程非常容易。顯然，這種方法不能阻止任何認真的程序員獲取源代碼。雖然我們可以用Java作為加密和解密過程的中間工具，但遺憾的是，Applet會給Web頁面增加不必要的額外負荷，而且它會因為瀏覽器所用Java虛擬機版本的不同而無法正常運行。相對而言，DHTML卻意味著快速、小巧、通用和可移植。
在基于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 >
......
可以看到，我們首先發(fā)送了一個WML頭，使得無線瀏覽器認為該ASP頁面實際上是一個WML頁面。這種技術同樣可以用來保護JavaScript源文件(.js文件)。
Netscape隨著JavaScript 1.2的發(fā)布引入了對JavaScript源文件的支持。大多數(shù)支持該版本JavaScript的瀏覽器都支持JavaScript源文件(Internet Explorer 3.0+，Netscape 3.0+以及Opera 5.0)。動態(tài)HTML(DHTML)由JavaScript和CSS混合構成。CSS樣式使得開發(fā)者能夠自由地在瀏覽器窗口中表現(xiàn)各種頁面元素，而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系統(tǒng)變量來驗證發(fā)出請求的頁面，這個變量可以通過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函數(shù)的輸出.'); } < %ELSE% > < !--這些代碼受版權保護。所有權利保留-- > < %END IF% > |
下面我們來分析一下js.asp如何進行驗證以及發(fā)送JavaScript代碼。程序首先檢查會話變量auth，看看請求的起源是否合法。如是，則關閉瀏覽器緩存，重新設置會話變量，然后向瀏覽器發(fā)送JavaScript代碼。如果對js.asp的請求不是來自可靠的起源，會話變量auth是false，程序只發(fā)送一個帶有版權聲明的空白頁面。
其結果是，如果用戶企圖下載JavaScript源文件或者在另一個網(wǎng)站上使用JavaScript源文件，他得到的只是一個空白頁面。這樣，我們也就實現(xiàn)了對誰可以訪問DHTML源文件的控制。
如果要在Web頁面中保護頁面實際內容的HTML代碼，你可以在js.asp文件中創(chuàng)建一個函數(shù)，如下所示：
以下是引用片段：
function html(){
document.write('< html >< body >頁面內容< \/body >< \/html > ');
}
然后，主頁面只需簡單地調用一下html()即可構造出Web頁面。這種頁面只有在用戶啟用了瀏覽器的JavaScript支持之后才會顯示。如果用戶查看這種頁面的源代碼，他看到的只有一個函數(shù)調用，而不會看到函數(shù)調用所返回的源代碼。
這種表現(xiàn)出兩種(或更多)不同類型文件特征的ASP可以稱為“混合ASP”。下面是JavaScript/ASP混合文件的一些特點：
JavaScript源文件直接發(fā)向瀏覽器，未經(jīng)緩存。
文件經(jīng)過必要的驗證，防止了用戶下載源代碼。
最終用戶不能直接訪問源代碼。
會話變量：
在上面的例子中，我們使用會話變量驗證JavaScript源文件調用的起源。如果網(wǎng)站的訪問量非常高，這可能不是進行驗證的最好方法。
每次用戶訪問Web頁面或Web應用時都要創(chuàng)建一個會話變量。服務器保持會話唯一標識符的默認時間是20分鐘。如果服務器同時要為大量訪問者維持狀態(tài)信息，你可以想象出服務器的負載會有多高。
解決這個問題主要有兩種方法：
在服務器上把會話超時時間設置得盡量小。此外，當代碼已經(jīng)發(fā)送給瀏覽器之后，調用Session.Abandon釋放會話狀態(tài)信息。這種方法適用于中小流量的網(wǎng)站。
對于高流量的網(wǎng)站，建議通過GUID/數(shù)據(jù)庫結合維持會話狀態(tài)的方法進行驗證。
內存分配：
大多數(shù)基于Mozilla的瀏覽器都用Spidermonkey JavaScript引擎解釋執(zhí)行JavaScript。這個引擎的優(yōu)點包括：以解釋方式執(zhí)行代碼(與編譯方式相對應)，動態(tài)垃圾收集機制(換句話說，自動釋放內存空間避免內存漏洞吞噬計算機資源)。
試試下面這個操作：運行上面的例子。函數(shù)執(zhí)行之后，進入URL地址欄，選中URL并敲Enter，你可以看到此時函數(shù)并不執(zhí)行，瀏覽器顯示了一個JavaScript錯誤。然而，如果你點擊瀏覽器的刷新按鈕，函數(shù)將正常執(zhí)行。
下面是產生這種情況的原因：JavaScript函數(shù)執(zhí)行之后，由于瀏覽器假定需要時這些代碼仍舊可以從緩存獲得，于是它就釋放了為JavaScript保留的內存。然而，ASP代碼禁止了瀏覽器緩存JavaScript代碼。由于瀏覽器不能再引用內存中的函數(shù)，也不能再從緩存中獲取函數(shù)代碼，所以你就在按Enter鍵時看到了一個錯誤。
點擊瀏覽器的刷新按鈕時，瀏覽器將重新從服務器下載函數(shù)代碼并執(zhí)行。如果代碼不再引用函數(shù)，則JavaScript引擎將釋放函數(shù)。但有一種方法可以強制瀏覽器在內存中保留函數(shù)，即在程序執(zhí)行期間始終激活對函數(shù)的引用。
早期的/不兼容的瀏覽器：
毫無疑問，本文所介紹的方法不適合JavaScript版本早于1.2的瀏覽器。解決辦法是編寫一個預先進行檢查的程序，由該程序檢查用戶瀏覽器是否和你的Web應用兼容。
包截取：
理論上，只要企圖竊取代碼的人具有足夠的決心，他可以在代碼向瀏覽器發(fā)送時通過竊取數(shù)據(jù)包竊取代碼。然而，這項工作所要耗費的時間和精力使得它幾乎成為不可能的事情。而且，如果你想要獲得百分之百安全的傳輸，還可以使用SSL。使用SSL唯一的缺點在于應用只能在支持SSL的瀏覽器上運行。
小結：
“混合ASP”技術的應用當然不會局限于ASP和JavaScript源文件。在理論上，它可以在許多服務器端腳本語言環(huán)境中應用，比如CGI或者PHP。此外，這種技術理論上還可以用于保護其他文件，如圖形、聲音和文檔。例如，“混合ASP”文件完全可以起到圖形文件的作用，具體方法是先驗證請求的起源，向瀏覽器發(fā)送正確的內容類型標識，然后從SQL數(shù)據(jù)庫提取并發(fā)送BLOB字段的圖形文件。它在這方面的應用可以說是沒有止境的。
在未來的許多年里，JavaScript和DHTML仍將繼續(xù)發(fā)展，并繼續(xù)作為一種重要的Web開發(fā)工具而存在。W3C有望認可客戶端編程工具的價值和重要性，并為了保護它而制定一個標準。
您發(fā)布的評論即表示同意遵守以下條款:
一、不得利用本站危害國家安全、泄露國家秘密,不得侵犯國家、社會、集體和公民的合法權益;
二、不得發(fā)布國家法律、法規(guī)明令禁止的內容;互相尊重,對自己在本站的言論和行為負責;
三、本站對您所發(fā)布內容擁有處置權。
蘇公網(wǎng)安備 32070502010230號