隨著Web2.0的發展以及Ajax框架的普及，富客戶端Web應用(Rich Internet Applications，RIA)日益增多，越來越多的邏輯已經開始從服務器端轉移至客戶端，這些邏輯通常都是使用JavaScript語言所編寫。但遺憾的是，目前開發人員普遍不太關注JavaScript代碼的安全性。據IBMX-Force2011年中期趨勢報告揭示，世界五百強的網站及常見知名網站中有40%存在JavaScript安全漏洞。本文將結合代碼向讀者展示常見Java Script安全漏洞，旨在幫助讀者能夠在日常編碼工作中規避這些安全漏洞。此外，客戶端Java Script安全漏洞與服務器端安全漏洞原理略為不同，自動化檢測JavsScript安全漏洞目前存在較大的技術難題，本文將結合案例跟讀者分享如何利用IBM Rational AppScan Standard Edition V8.0新特性(JavaScript Security Analyzer，JSA)技術自動化檢測JavaScript安全漏洞。

JavaScript常見安全漏洞

2010年12月份，IBM發布了關于Web應用中客戶端JavaScript安全漏洞的白皮書，其中介紹了IBM安全研究機構曾做過的JavaScript安全狀況調查。樣本數據包括了675家網站，其中有財富500強公司的網站和另外175家著名網站，包括IT公司、Web應用安全服務公司、社交網站等。為了不影響這些網站的正常運行，研究人員使用了非侵入式爬蟲，僅掃描了無需登錄即可訪問的部分頁面，每個站點不超過200個頁面。這些頁面都被保存下來，研究人員采用IBM的JavaScript安全分析技術離線分析了這些頁面，集中分析了基于DOM的跨站點腳本編制及重定向兩種漏洞。

測試結果令人驚嘆，這些知名網站中有14%存在嚴峻的JavaScript安全問題，黑客可以利用這些漏洞進行植入流氓軟件，植入釣魚站點，以及劫持用戶會話等。更令人驚嘆不已的是，隨著IBM的JavaScript安全分析技術的成熟發展，2011年中期X-Force報告顯示，IBM重新測試了上述這些知名網站并發現了更多的安全漏洞，大約有40%的網站存在JavaScript安全漏洞。

下文本文將結合代碼向讀者展示常見這些JavaScript安全漏洞，以便讀者在實際編碼過程中注意到這些安全問題，及早規避這些風險。

1、基于DOM的跨站點腳本編制

我們都聽說過XSS(Cross Site Script，跨站點腳本編制，也稱為跨站腳本攻擊)，指的是攻擊者向合法的Web頁面中插入惡意腳本代碼(通常是HTML代碼和JavaScript代碼)然后提交請求給服務器，隨即服務器響應頁面即被植入了攻擊者的惡意腳本代碼，攻擊者可以利用這些惡意腳本代碼進行會話劫持等攻擊。跨站點腳本編制通常分為反射型和持久型：當請求數據在服務器響應頁面中呈現為未編碼和未過濾時，即為反射型跨站點腳本編制;持久型指的是包含惡意代碼的請求數據被保存在Web應用的服務器上，每次用戶訪問某個頁面的時候，惡意代碼都會被自動執行，這種攻擊對于Web2.0類型的社交網站來說尤為常見，威脅也更大。應對跨站點腳本編制的主要方法有兩點：一是不要信任用戶的任何輸入，盡量采用白名單技術來驗證輸入參數;二是輸出的時候對用戶提供的內容進行轉義處理。

但鮮為人知的是還有第三種跨站點腳本編制漏洞。2005年AmitKlein發表了白皮書《基于DOM的跨站點腳本編制—第三類跨站點腳本編制形式》("DOM Based Cross Site Scripting or XSS of theThird Kind")，它揭示了基于DOM的跨站點腳本編制不需要依賴于服務器端響應的內容，如果某些HTML頁面使用了document.location、document.URL或者document.referer等DOM元素的屬性，攻擊者可以利用這些屬性植入惡意腳本實施基于DOM的跨站點腳本編制攻擊。

下面我們將通過一個很簡單的HTML頁面來演示基于DOM的跨站點腳本編制原理。假設有這么一個靜態HTML頁面(如清單1所示)，用來展示歡迎用戶成功登錄的信息。

清單1.存在DOM based XSS的HTML代碼

按照該頁面JavaScript代碼邏輯，它會接受URL中傳入的name參數并展示歡迎信息，如清單2所示：

清單2.正常情況下的訪問URL

但如果惡意攻擊者輸入類似如下的腳本，見清單3，該頁面則會執行被注入的JavaScript腳本。

清單3.訪問URL中注入腳本

很明顯，受害者的瀏覽器訪問以上URL的時候，服務器端會跟正常情況下一樣返回清單1中所示HTML頁面，然后瀏覽器會繼續將這個HTML解析成DOM，DOM中包含的document對象的URL屬性將包含清單3中注入的腳本內容，當瀏覽器解析到JavaScript的時候會執行這段被注入的腳本，跨站點腳本編制攻擊即成功實現。

值得關注的是，通過以上示例可以看出，惡意代碼不需要嵌入服務器的響應中，基于DOM的跨站點腳本編制攻擊也能成功。可能某些讀者會認為：目前主流瀏覽器會自動轉義URL中的'<'和'>'符號，轉義后的注入腳本就不會被執行了，基于DOM的跨站點腳本編制也就不再有什么威脅了。這句話前半段是對的，但后半段就不準確了。我們要意識到攻擊者可以很輕松地繞過瀏覽器對URL的轉義，譬如攻擊者可以利用錨點'#'來欺騙瀏覽器，如清單4所示。瀏覽器會認為'#'后面的都是片段信息，將不會做任何處理。

清單4.訪問URL中結合錨點注入腳本

 #p#

2、通過URL重定向釣魚

網絡釣魚是一個通稱，代表試圖欺騙用戶交出私人信息，以便電子欺騙身份。通過URL重定向釣魚指的是Web頁面會采用HTTP參數來保存URL值，且Web頁面的腳本會將請求重定向到該保存的URL上，攻擊者可以將HTTP參數里的URL值改為指向惡意站點，從而順利啟用網絡釣魚欺騙當前用戶并竊取用戶憑證。清單5給出了較為常見的含有通過URL重定向釣魚漏洞的代碼片段。

清單5.執行重定向的JavaScript代碼片段

可以看出，這些JavaScript腳本負責執行重定向，新地址是從document.location、document.URL或者document.referer等DOM元素的屬性值中截取出來的，譬如用戶輸入清單6所示。

清單6.執行重定向的URL

顯然用戶一旦執行了清單6所示URL，將被重定向到釣魚網站。這個漏洞的原理很簡單，比服務器端的重定向漏洞更好理解。但通過URL重定向釣魚的情況下，釣魚站點的網址并不會被服務端攔截和過濾，因此，這個漏洞往往比服務器端重定向漏洞更具有隱蔽性。

3、客戶端JavaScript Cookie引用

Cookie通常由Web服務器創建并存儲在客戶端瀏覽器中，用來在客戶端保存用戶的身份標識、Session信息，甚至授權信息等。客戶端JavaScript代碼可以操作Cookie數據。如果在客戶端使用JavaScript創建或修改站點的cookie，那么攻擊者就可以查看到這些代碼，通過閱讀代碼了解其邏輯，甚至根據自己所了解的知識將其用來修改cookie。一旦cookie包含了很重要的信息，譬如包含了權限信息等，攻擊者很容易利用這些漏洞進行特權升級等攻擊。

4、JavaScript劫持

許多Web應用程序都利用JSON作為Ajax的數據傳輸機制，這通常都容易受到JavaScript劫持攻擊，傳統的Web應用程序反而不易受攻擊。JSON實際上就是一段JavaScript，通常是數組格式。攻擊者在其惡意站點的頁面中通過<SCRIPT>標簽調用被攻擊站點的一個JSON動態數據接口，并通過JavaScript Function Hook等技術取得這些JSON數據。如果用戶登錄被攻擊網站后（假定其身份認證信息是基于Session Cookie來保存的），又被攻擊者誘引訪問了惡意站點頁面，那么，由于<SCRIPTsrc=">這種標簽的請求會帶上Cookie信息，惡意站點會發送JSON數據獲取請求至被攻擊站點，被攻擊站點服務器會認為當前請求是合法的，并返回給惡意站點當前用戶的相關JSON數據，從而導致用戶數據泄密。整個過程相當于一個站外類型的跨站點請求偽造CSRF攻擊。

隨著Ajax的進一步推廣，以及HTML5的逐步應用，還有更多的客戶端安全漏洞出現。目前對于JavaScript的安全研究尚不多，新推出的HTML5客戶端存儲、跨域通信等新特型也都跟安全緊密相關，有興趣的讀者可以作進一步閱讀。鑒于筆者知識有限，JavaScript相關安全漏洞暫且分享這么多，下面將談談JavaScript安全漏洞的檢測技術。

自動化檢測JavaScript安全漏洞

正如我們所熟知，檢測代碼安全漏洞一般有白盒檢查和黑盒檢查。白盒檢查側重于對代碼的分析，可以通過手工代碼審查，或者自動代碼分析工具。黑盒檢查主要是模擬黑客攻擊的方式進行滲透測試。通常而言，黑盒檢查的準確度高一些，但代碼覆蓋面比較小，而白盒檢查的代碼覆蓋率較高，但誤報率比較高。兩種方式相結合能夠互相彌補不足，混合檢查方式將會是未來的趨勢。

結合JavaScript代碼而言，出于跨瀏覽器兼容、更好的Ajax特性需求等原因，越來越多的Web應用依賴于第三方的JavaScript代碼庫，譬如Dojo、JQuery等。這些代碼庫為了降低文件大小，往往都進行了代碼壓縮，導致其可讀性極差，因此手工代碼審查幾乎不具備可行性。此外，頁面JavaScript調用入口很多，手工對其進行滲透測試的工作量和難度都非常大。因此，我們需要推薦使用自動化測試工具來檢測JavaScript安全漏洞。

Rational AppScan JSA原理簡述

JSA是RationalAppScanStandardV8.0新推出的一項AppScan擴展，用來進行執行靜態JavaScript分析，以檢測常見客戶端安全漏洞。JSA融合了JavaScript靜態污點分析技術和網站動態爬蟲技術。簡而言之，AppScan會保存爬蟲所探索到的所有URL的完整的HTTP響應，然后JSA對這些響應頁面逐個進行JavaScript代碼分析。JSA在分析每個頁面時應用兩個階段：數據流分析和字符串分析。首先，JSA查找從源(Source)到接收器(Sink)中未經過清除工具(Sanitizer)的軌跡。如果可找到此軌跡(Trace)，那么JSA將在第二步中使用字符串分析的變體——字符串前綴分析(SPA)進行驗證。相比于單純的JavaScript代碼靜態分析技術而言，JSA技術更為先進和準確，因為它是在完全解析好的HTML頁面及DOM環境中進行安全漏洞分析。

如今Web2.0網站及Ajax應用中，HTML頁面往往都需要瀏覽器基于服務器響應里的HTML和JavaScript代碼進行動態解析后才形成完整的HTML和DOM，單純基于服務器響應中的JavaScript代碼進行靜態污點分析存在一個明顯缺陷--其所測JavaScript代碼及執行環境不一定完整，因此它無法保證測試的準確度和全面性。JSA正是克服了以上缺點，融合了白盒檢測和黑盒檢測兩種測試方法的優點，并引入IBM的字符串分析技術，所以JSA有著更好的準確性和全面性。#p#
利用AppScan檢測JavaScript安全漏洞

AltoroMutual是IBM所提供的Web安全漏洞演示網站，下文筆者將向讀者展示如何利用AppScan JSA來檢測該網站所存在的JavaScript安全漏洞。

啟動AppScan，點擊菜單"掃描–掃描配置"打開掃描配置對話框，設置起始URL為"http://demo.testfire.net"。

▲圖1.設置起始URL

在掃描配置對話框左側，點擊"登錄管理"，然后點擊右側的"記錄..."按鈕錄制登錄過程，確保會話中檢測處于活動狀態。

▲圖2.設置登錄方法

在掃描配置對話框左側，點擊"測試策略"，檢查測試策略設置。默認測試策略應該是"缺省"，其已經包含了常見JavaScript測試，可以點擊"已啟用/已禁止"查看當前默認啟用的測試策略。

▲圖3.檢查測試策略

關閉掃描配置對話框，點擊菜單"掃描--僅探索"或單擊快捷按鈕(如圖4所示)啟動探索。本文僅示例如何檢測JavaScript安全漏洞，所以選擇"僅探索"+客戶端JavaScript分析的測試方式。

▲圖4.啟動探索

點擊菜單"工具–擴展名–JavaScript Security Analyzer"或者快捷按鈕(如圖5所示)打開"分析JavaScript"。在彈出的JavaScript Security Analyzer對話框中，單擊"立即分析"。#p#

 ▲圖5.分析JavaScript

JavaScriptSecurityAnalyzer掃描完成后，即在結果列表中列出所發現的客戶端JavaScript安全漏洞。如下圖所示，AltoroMutual站點存在"基于DOM的跨站點腳本編制"及"開放式重定向"漏洞，下文將展示這些漏洞的詳細信息。

▲圖6.查看掃描結果

展開結果列表中的"基于DOM的跨站點腳本編制"，單擊第一個"JavaScript"問題，在下方的問題信息中將會展示其詳細信息。我們可以看出，AppScan保存了對JavaScript問題代碼的分析結果，并用黃色標識定位了源(Source)和接收器(Sink)，利于開發人員快速修復該漏洞。

▲圖7.基于DOM的跨站點腳本編制問題信息

同樣，展開并查看"開放式重定向"問題，在問題信息欄中展示了該漏洞的代碼分析結果。

▲圖8.開放式重定向問題信息

注意：

本文為了快速展示如何檢測JavaScript安全漏洞，所以選擇"僅探索"+客戶端JavaScript分析的測試方式。實際工作中，建議您只需要跟通常一樣進行掃描(即手工探索結合自動探索站點，然后執行測試)，AppScan默認會在測試過程中自動執行JavaScript Security Analyzer。

Rational AppScan Standard能檢測已知常見JavaScript安全漏洞，但AltoroMutual僅展示了基于DOM的跨站腳本編制和重定向漏洞，故本案例的結果列表中僅包含上述兩項安全漏洞。