JavaScript 常見安全漏洞與自動化偵測技術_javascript技巧
- WBOY原創
- 2016-05-16 15:43:341773瀏覽
前言
隨著Web2.0 的發展以及Ajax 框架的普及，富客戶端Web 應用（Rich Internet Applications，RIA）日益增多，越來越多的邏輯已經開始從伺服器端轉移至客戶端，這些邏輯通常都是使用JavaScript 語言所寫。但遺憾的是，目前開發人員普遍不太關注 JavaScript 程式碼的安全性。根據 IBM X-Force 2011 年中期趨勢報告揭示，全球五百強的網站及常見知名網站中有 40% 有 JavaScript 安全漏洞。本文將結合程式碼向讀者展示常見 JavaScript 安全漏洞，旨在幫助讀者在日常程式設計工作中規避這些安全漏洞。此外，客戶端JavaScript 安全漏洞與伺服器端安全漏洞原理略為不同，自動化偵測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 安全漏洞。
java企業級通用權限安全框架原始碼 SpringMVC mybatis or hibernate ehcache shiro druid bootstrap HTML5
下文本文將結合程式碼向讀者展示常見這些 JavaScript 安全漏洞，以便讀者在實際編碼過程中註意到這些安全問題，及早規避這些風險。
基於 DOM 的跨站點腳本編制
我們都聽說過XSS（Cross Site Script，跨站點腳本編制，也稱為跨站腳本攻擊），指的是攻擊者向合法的Web 頁面中插入惡意腳本代碼（通常是HTML 代碼和JavaScript程式碼）然後提交請求給伺服器，隨即伺服器回應頁面即被植入了攻擊者的惡意腳本程式碼，攻擊者可以利用這些惡意腳本程式碼進行會話劫持等攻擊。跨站點腳本編制通常分為反射型和持久型：當請求資料在伺服器回應頁面中呈現為未編碼和未過濾時，即為反射型跨站點腳本編制；持久型指的是包含惡意程式碼的請求數據被儲存在Web 應用程式的伺服器上，每次使用者造訪某個頁面的時候，惡意程式碼都會被自動執行，這種攻擊對於Web2.0 類型的社群網站來說尤其常見，威脅也更大。應對跨站點腳本編制的主要方法有兩點：一是不要信任用戶的任何輸入，盡量採用白名單技術來驗證輸入參數；二是輸出的時候對用戶提供的內容進行轉義處理。
但鮮為人知的是還有第三種跨站點腳本編制漏洞。 2005 年Amit Klein 發表了白皮書《基於DOM 的跨站點腳本編制—第三類跨站點腳本編制形式》（"DOM Based Cross Site Scripting or XSS of the Third Kind"），它揭示了基於DOM 的跨站點腳本編制不需要依賴伺服器端回應的內容，如果某些HTML 頁面使用了document.location、document.URL 或document.referer 等DOM 元素的屬性，攻擊者可以利用這些屬性植入惡意腳本實作基於DOM 的跨網站腳本編制攻擊。
下面我們將透過一個很簡單的 HTML 頁面來示範基於 DOM 的跨站點腳本編制原理。假設有這麼一個靜態 HTML 頁面（如清單 1 所示），用來展示歡迎使用者成功登入的資訊。
清單 1. 存在 DOM based XSS 的 HTML 程式碼
<HTML>
<TITLE>Welcome!</TITLE>
Hi
<SCRIPT>
var pos=document.URL.indexOf("name=")+5;
document.write(document.URL.substring(pos,document.URL.length));
</SCRIPT>
<BR>
Welcome to our system
…
</HTML>
按照该页面 JavaScript 代码逻辑，它会接受 URL 中传入的 name 参数并展示欢迎信息，如清单 2 所示：
清单 2. 正常情况下的访问 URL
http://www.vulnerable.site/welcome.html?name=Jeremy
但如果恶意攻击者输入类似如下的脚本，见清单 3，该页面则会执行被注入的 JavaScript 脚本。
清单 3. 访问 URL 中注入脚本
很明显，受害者的浏览器访问以上 URL 的时候，服务器端会跟正常情况下一样返回清单 1 中所示 HTML 页面，然后浏览器会继续将这个 HTML 解析成 DOM，DOM 中包含的 document 对象的 URL 属性将包含清单 3 中注入的脚本内容，当浏览器解析到 JavaScript 的时候会执行这段被注入的脚本，跨站点脚本编制攻击即成功实现。
值得关注的是，通过以上示例可以看出，恶意代码不需要嵌入服务器的响应中，基于 DOM 的跨站点脚本编制攻击也能成功。可能某些读者会认为：目前主流浏览器会自动转义 URL 中的 '0b0d3c1d0eac9ad57b06cc87ca4baf9e' 符号，转义后的注入脚本就不会被执行了，基于 DOM 的跨站点脚本编制也就不再有什么威胁了。这句话前半段是对的，但后半段就不准确了。我们要意识到攻击者可以很轻松地绕过浏览器对 URL 的转义，譬如攻击者可以利用锚点 '#' 来欺骗浏览器，如清单 4 所示。浏览器会认为 '#' 后面的都是片段信息，将不会做任何处理。
清单 4. 访问 URL 中结合锚点注入脚本
通过 URL 重定向钓鱼
网络钓鱼是一个通称，代表试图欺骗用户交出私人信息，以便电子欺骗身份。通过 URL 重定向钓鱼指的是 Web 页面会采用 HTTP 参数来保存 URL 值，且 Web 页面的脚本会将请求重定向到该保存的 URL 上，攻击者可以将 HTTP 参数里的 URL 值改为指向恶意站点，从而顺利启用网络钓鱼欺骗当前用户并窃取用户凭证。清单 5 给出了较为常见的含有通过 URL 重定向钓鱼漏洞的代码片段。
清单 5. 执行重定向的 JavaScript 代码片段
<SCRIPT>
…
var sData = document.location.search.substring(1);
var sPos = sData.indexOf("url=") + 4;
var ePos = sData.indexOf("&", sPos);
var newURL;
if (ePos< 0) {
newURL = sData.substring(sPos);
} else {
newURL = sData.substring(sPos, ePos);
}
window.location.href = newURL;
…
</SCRIPT>
可以看出，這些 JavaScript 腳本負責執行重定向，新位址是從 document.location、document.URL 或 document.referer 等 DOM 元素的屬性值中截取出來的，譬如使用者輸入清單 6 所示。
清單 6. 執行重新導向的 URL
http://www.vulnerable.site/redirect.html?url=http://www.phishing.site
顯然使用者一旦執行了清單 6 所示 URL，就會被重新導向到釣魚網站。這個漏洞的原理很簡單，比伺服器端的重定向漏洞更能理解。但透過 URL 重定向釣魚的情況下，釣魚網站的網址並不會被服務端攔截和過濾，因此，這個漏洞往往比伺服器端重定向漏洞更具有隱蔽性。
客戶端 JavaScript Cookie 引用
Cookie 通常由 Web 伺服器建立並儲存在客戶端瀏覽器中，用來在客戶端保存使用者的身分識別識別、Session 訊息，甚至授權資訊等。客戶端 JavaScript 程式碼可以操作 Cookie 資料。如果在客戶端使用 JavaScript 建立或修改網站的 cookie，那麼攻擊者就可以查看到這些程式碼，透過閱讀程式碼來了解其邏輯，甚至根據自己所了解的知識將其用來修改 cookie。一旦 cookie 包含了很重要的訊息，譬如包含了權限資訊等，攻擊者很容易利用這些漏洞進行特權升級等攻擊。
JavaScript 劫持
許多 Web 應用程式都利用 JSON 作為 Ajax 的資料傳輸機制，這通常都容易受到 JavaScript 劫持攻擊，傳統的 Web 應用程式反而不易受攻擊。 JSON 其實就是一段 JavaScript，通常是陣列格式。攻擊者在其惡意網站的頁面中透過 <script> 標籤呼叫被攻擊網站的一個 JSON 動態資料接口，並透過 JavaScript Function Hook 等技術取得這些 JSON 資料。如果使用者登入被攻擊網站後（假定其身分認證資訊是基於Session Cookie 來保存的），又被攻擊者誘引造訪了惡意網站頁面，那麼，由於<SCRIPT src="> 這種標籤的請求會帶上Cookie 訊息，惡意站點會發送JSON 數據獲取請求至被攻擊站點，被攻擊站點伺服器會認為當前請求是合法的，並返回給惡意站點當前用戶的相關JSON 數據，從而導致用戶數據洩密。於一個站外類型的跨站點請求偽造CSRF 攻擊。 </script>
隨著 Ajax 的進一步推廣，以及 HTML5 的逐步應用，還有更多的客戶端安全漏洞出現。目前對於 JavaScript 的安全研究尚不多，新推出的 HTML5 用戶端儲存、跨域通訊等新特型也都跟安全緊密相關，有興趣的讀者可以進一步閱讀。鑑於筆者知識有限，JavaScript 相關安全漏洞暫且分享這麼多，以下將談談 JavaScript 安全漏洞的偵測技術。
自動化偵測 JavaScript 安全漏洞
如我們所熟知，偵測程式碼安全漏洞一般有白盒檢查和黑盒檢查。白盒檢查側重於對程式碼的分析，可以透過手動程式碼審查，或自動程式碼分析工具。黑盒檢查主要是模擬駭客攻擊的方式進行滲透測試。通常而言，黑盒檢查的準確度高一些，但程式碼覆蓋率比較小，而白盒檢查的程式碼覆蓋率較高，但誤報率比較高。兩種方式結合能夠互相彌補不足，混合檢查方式將會是未來的趨勢。結合 JavaScript 程式碼而言，出於跨瀏覽器相容、更好的 Ajax 特性需求等原因，越來越多的 Web 應用依賴第三方的 JavaScript 程式碼庫，譬如 Dojo、JQuery 等。這些程式碼庫為了降低檔案大小，往往都進行了程式碼壓縮，導致其可讀性極差，因此手動程式碼審查幾乎不具備可行性。此外，頁面 JavaScript 呼叫入口很多，手動滲透測試的工作量和難度都非常大。因此，我們需要推薦使用自動化測試工具來偵測 JavaScript 安全漏洞。
Rational AppScan JSA 原理簡述
JSA 是 Rational AppScan Standard V8.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 有著更好的準確性和全面性。
利用 AppScan 偵測 JavaScript 安全漏洞
Altoro Mutual 是 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 對話方塊中，按一下"立即分析"。
圖 5. 分析 JavaScript
JavaScript Security Analyzer 掃描完成後，即在結果清單中列出所發現的客戶端 JavaScript 安全漏洞。如下圖所示，Altoro Mutual 站點存在"基於 DOM 的跨站點腳本編制"及"開放式重定向"漏洞，下文將展示這些漏洞的詳細資訊。
圖 6. 檢視掃描結果
展開結果清單中的"基於 DOM 的跨站點腳本編制"，按一下第一個"JavaScript"問題，在下方的問題資訊中將會顯示其詳細資訊。我們可以看出，AppScan 保存了對 JavaScript 問題程式碼的分析結果，並以黃色識別定位了來源（Source）和接收器（Sink），利於開發人員快速修復漏洞。
圖 7. 基於 DOM 的跨站點腳本編制問題資訊
同樣，展開並查看"開放式重定向"問題，在問題資訊欄中展示了該漏洞的程式碼分析結果。
圖 8. 開放式重新導向問題資訊
注意：
本文為了快速展示如何偵測 JavaScript 安全漏洞，所以選擇"只探索" 客戶端 JavaScript 分析的測試方式。在實際工作中，建議您只需要跟通常一樣進行掃描（即手動探索結合自動探索站點，然後執行測試），AppScan 預設會在測試過程中自動執行 JavaScript Security Analyzer。
Rational AppScan Standard 能偵測已知常見 JavaScript 安全漏洞，但 Altoro Mutual 僅展示了基於 DOM 的跨站腳本編制和重定向漏洞，故本案例的結果清單中僅包含上述兩項安全漏洞。
結論
java企業級通用權限安全框架原始碼 SpringMVC mybatis or hibernate ehcache shiro druid bootstrap HTML5
本文介紹了 JavaScript 常見安全漏洞，分析了手動偵測 JavaScript 程式碼存在較大的技術難度。 IBM Rational AppScan V8.x 新推出了 JSA 擴充元件，在業界率先提供了客戶端 JavaScript 安全偵測方案。本文跟讀者分享了 JSA 的基本原理和技術優勢，並結合案例向讀者示範如何使用 IBM Rational AppScan JSA 測試客戶端 JavaScript 安全性。
本文寫的存在問題局限性，歡迎提出批評，共同學習進步。