本文簡要介紹了流行的三個瀏覽器動態Fuzz工具cross_fuzz、grinder、X-Fuzzer的原理及其優缺點，並提供了一種透過動靜結合的方式兼顧可重現性、通用性、高效性、自動化程度高的瀏覽器fuzz方法。

0x00 引言

---

Fuzz（模糊測試）是一種側重於發現軟體安全漏洞的方法。典型地模糊測試過程是透過自動的或半自動的方法，反覆驅動目標軟體執行，併為其提供”精心”構造的輸入資料，同時監控軟體執行的異常，進而根據異常結果及輸入資料查詢軟體的安全漏洞。隨著Smart Fuzz的發展，RCE（逆向程式碼工程）需求的增加，其特徵更符合一種灰盒測試。其簡要流程圖如下：

Web瀏覽器是網路應用中使用最廣泛的軟體之一，IE、FireFox、Chrome等三款主流瀏覽器佔據了Web瀏覽器市場的大部分份額，其自身的安全性備受關注、影響廣泛。本文介紹的瀏覽器fuzz則是以上述三款瀏覽器作為fuzz的主要目標，以內容（css、html、js）隨機的html頁面作為被測瀏覽器的輸入，並監控瀏覽器執行的異常情況，查詢其安全漏洞。

瀏覽器fuzz是查詢瀏覽器漏洞的一個常用且有效的方法，公開的動態瀏覽器fuzz工具有cross_fuzz、grinder、X-Fuzzer等，這些工具基本都透過javascript指令碼進行fuzz操作，同時透過hook函式、localStorage本地儲存等技術手段動態記錄fuzz操作日誌，捕獲到異常後再根據記錄日誌進行還原。

現有瀏覽器fuzz工具動態記錄日誌方式可能會影響被測瀏覽器的執行環境進而導致有時不能夠重現異常；且其在記錄日誌方法上通用性（如IE的ActiveXObject）、穩定性（grinder hook函式）欠佳。

很多瀏覽器fuzz工具每執行一個測試用例都會重啟待測瀏覽器程式，因為瀏覽器重啟在執行一個測試用例過程中耗時佔比較大，進而導致fuzz效率不高。

有的瀏覽器fuzz工具（如經典的cross_fuzz）在遇到crash時會停止fuzz，自動化程度不夠。

本文在總結了現有動態瀏覽器fuzz工具優缺點的同時，提供了一種透過動靜結合的方式兼顧可重現性、通用性、高效性、自動化程度高的瀏覽器fuzz方法及其工具NBFuzz（New Browser Fuzz）。

0x01 corss_fuzz 簡介

---

cross_fuzz由google的安全研究人員Michal Zalewski開發，支援多個瀏覽器fuzz，並專門針對IE瀏覽器作了最佳化。這個工具及在其基礎上衍生的瀏覽器fuzz工具發現了大量的瀏覽器安全漏洞，其設計思想對瀏覽器漏洞挖掘產生了深遠的影響。

cross_fuzz主要闡述了瀏覽器fuzz的設計思想，只是個演示性的功能模組，還不是一個完整的瀏覽器自動化fuzz工具，如關鍵的操作日誌記錄、異常監控等還需要使用者自己來實現。

介面

流程圖

0x02 X-Fuzzer 簡介

---

X-Fuzzer是由安全研究人員Vinay Katoch開發的一款輕量級的動態瀏覽器fuzz工具，其日誌記錄採用了主流瀏覽器通用localStorage本地儲存、document.cookie，即使瀏覽器異常崩潰時日誌也能夠儲存。此工具dom元素fuzz操作、日誌記錄都很簡單，還需自行完善；而且此工具沒有異常監控模組，不能實現自動化fuzz。

介面

功能模組圖

0x03 grinder 簡介

---

grinder是一個自動化瀏覽器fuzz框架，客戶端node主要採用ruby語言編寫。

其日誌記錄透過向被測瀏覽器程式注入grinder_logger.dll ，進而hook javascript函式parseFloat在jscript9.dll、mozjs.dll等指令碼引擎中的實現函式，這樣需要記錄日誌時只需呼叫parseFloat函式，日誌記錄功能由grinder_logger.dll中相應的hook回撥函式完成。需要注意的是下載相應dll符號檔案後才能完成hook操作，且最近版本的Firefox已不包含mozjs.dll導致hook函式失敗。此日誌記錄方法穩定性、通用性欠佳。

監控模組（ dbghelp.dll 、 symsrv.dll ）負責啟動、監控被測瀏覽器，記錄其異常資訊，完成fuzz自動化 。

重現模組（ testcase.rb ）根據日誌重現POC。

具體fuzz操作需要使用者自行完善。

介面

0x04 NBFuzz

---

NBFuzz 日誌記錄方法總結

• ActiveXObject只適用於IE。
• cookie、html5的localStorage適合IE、Firefox、Chrome等主流瀏覽器，但儲存大小有限制（cookie 4K、localStorage 5M），且需要設定瀏覽器支援cookie、記錄歷史。IE本地開啟html檔案時不支援localStorage。
• html5本地資料庫indexDB、SQLite的通用性不足（IE不支援或部分支援）且使用較複雜。
• XMLHttpRequest通用性較好，但每一步fuzz操作都需要實時記錄，通訊總耗時較長，影響fuzz效率。
• XMLHttpRequest改進：fuzz操作localStorage本地實時儲存；每個測試用例開始時localStorage設定異常標誌，沒有異常在測試用例結束時置空異常標誌；下一個測試用例透過XMLHttpRequest將產生異常的fuzz記錄上傳伺服器。這樣就解決了C/S實時記錄fuzz操作日誌的通訊瓶頸且localStorage 大小能夠滿足要求。
• 拋棄fuzz操作日誌：動態記錄日誌可能影響重現性（如indexDB 、 localStorage 等操作），通用性、穩定性（如grinder hook函式）欠佳；NBFuzz直接生成測試用例，不記錄fuzz操作日誌，且生成的測試用例不存在隨機操作，保證了可重現性、通用性。

NBFuzz模組圖

透過測試用例生成程式生成大量指定瀏覽器的fuzz測試用例，將生成的測試用例和排程頁面一併置於web服務端，監控模組開啟待測瀏覽器訪問排程頁面，排程頁面透過內嵌iframe頁面順序呼叫測試用例；監控模組記錄被測瀏覽器異常或者超時重啟被測瀏覽器程式，保障瀏覽器fuzz的自動化；最後分析監控模組記錄的異常資訊，找出可疑crash，根據其異常時間查詢web服務端log檔案中修改時間與之相匹配的檔案，獲取排程頁面發來的導致異常的測試用例名稱，進而重現crash，進一步判斷漏洞的可利用性。

測試用例生成

• 介面

  

  根據選定的瀏覽器型別生成大量包含其特性（不同的屬性、函式、垃圾回收機制等）的測試用例，由於使用了IE特有的ActiveXObject進行本地檔案操作所以要求使用IE執行此程式，使用js寫包含js的測試用例。

• 流程圖

  

測試用例載入（排程模組）

為解決每一個測試用例重啟瀏覽器程式瀏覽器啟動耗時佔比大的問題，NBFuzz的排程模組透過內嵌iframe開啟測試用例，一個測試用例完成後排程頁面reload操作執行下一個測試用例，為防止頁面不響應異常監控模組在超時後重啟待測瀏覽器；同時為了防止web服務端記錄log檔案過多加入了不夠精確的異常判斷機制，因為超時重啟將導致異常標誌不能正常置false，產生誤報，儘管如此也會大大減少log日誌。

排程模組流程圖如下：

0x05 瀏覽器Fuzz總結

---

隨著瀏覽器的安全機制（如IE的延遲釋放、隔離堆等）不斷加強，其安全漏洞井噴之勢已經得到遏制；而目前仍應用廣泛的flash由於其安全機制的不健全逐漸成為安全研究的熱點，安全漏洞亦呈現爆發的態勢，可以預見不久的將來若其仍固步自封，必將步java的後塵，逐漸被使用者所”拋棄”。

flash fuzz框架只需在NBFuzz框架的基礎上進行些許的改變即可，如需增加as3測試用例編譯成swf的過程。