模糊
測試（fuzz testing）是一類
安全性測試的方法。說起安全性測試，大部分人頭腦中浮現出的可能是一個標準的“黑客”場景：某個不修邊幅、臉色蒼白的年輕人，坐在黑暗的房間中，正在熟練地使用各種工具嘗試進入某個系統。這種由安全人員“模擬黑客進入系統”的測試方法的確是安全性測試中的一種有效測試手段，名叫“滲透測試”。滲透測試方法完全依靠測試執行者的能力，能力強的“白客”能夠發現有價值的安全性漏洞，而不具備很強的攻擊能力的測試者就無法有效發現系統中的安全性漏洞。必須承認，滲透測試是一種有效的安全性測試手段，當然，前提是你要能夠找到足夠好的測試執行者。
滲透測試是一種有效的測試方法，但由于它對執行者的能力要求太高，因此很難被大規模應用。站在測試的角度，我們是否能夠用“
自動化測試”這個強有力的武器幫助降低安全性測試的門檻呢？一個容易想到的“錄制/回放”方法是：將滲透測試的執行者們的操作錄制下來，形成腳本，期望這些腳本可以在不加修改或是稍加修改時應用在對其他應用的安全性測試中。但由于滲透測試的過程并不具有可重復的特點（測試執行主要依賴執行者的經驗，類似調試），這種想法在真實的安全性測試環境下完全不可行。完全自動化的工具通常只能發現那些可被用標準化方式發現的特定安全漏洞（如簡單的
SQL注入漏洞）。
模糊測試是一種介于完全的手工滲透測試與完全的自動化測試之間的安全性測試類型。它充分利用了機器的能力：隨機生成和發送數據；同時，也嘗試將安全專家在安全性方面的經驗引入進來。從執行過程來說，模糊測試的執行過程非常簡單：
測試工具通過隨機或是半隨機的方式生成大量數據；
測試工具將生成的數據發送給被測試的系統（輸入）；
測試工具檢測被測系統的狀態（如是否能夠響應，響應是否正確等）；
根據被測系統的狀態判斷是否存在潛在的安全漏洞。
顯然，模糊測試的整個執行過程是依靠工具進行的自動化測試。但是，看起來它完全是一個類似MonkeyTest工具的隨機數據生成器嘛，這怎么能和安全專家的經驗結合起來呢？別著急，我們用一個例子來演示一下。
為了簡單起見，假定我們要測試的應用是一個C/S應用的服務端程序。這個程序運行在Unix平臺上，名字叫做TgServer。我們唯一知道的信息就是客戶端和TgServer之間使用基于TCP/IP的自定義協議進行通訊。這種情況下，我們該如何嘗試找到應用系統中可能的漏洞？
方法1：
如果我們手頭上有TgServer的源代碼，通過代碼審查顯然可以找到可能的漏洞。就算沒有源代碼，通過逆向工程方式，用代碼審查的方式也可以達到找到漏洞的目的。當然，這必然要求審查者具有足夠好的技能，而且，被測應用規模越大，需要付出的成本也就越高。
方法2：
嘗試抓取到客戶端和服務器之間的通信數據，根據這些數據分析出客戶端與服務器之間的通信協議，然后根據協議的定義，自行編造數據發起攻擊，嘗試找到可能的漏洞。
方法2在成本上比方法1要低，而且由于方法2關注的是協議層面的攻擊，效率會更高。但是，稍微想一下，方法2還是存在一些問題：
完整的協議分析難度很大；
人工編造數據的成本很高；
在方法2的基礎上，我們嘗試引入模糊測試的概念，由于機器生成和發送數據的能力足夠強，因此我們完全可以把生成數據的任務交給機器去完成。當然，協議的分析主要還是依賴人工來進行，模糊測試領域內有一些自動化的協議分析手段（《模糊測試》一書中有專門的章節描述），但從效率和效果上來說，在面對復雜協議的時候，人工分析的方式更為有效。
假如根據抓取到的數據包，我們發現被測應用使用的協議如下（|僅表示字段間的分割，不是實際的數據內容）：
|00 01| GET | 11 | user:dennis
2字節的包頭（00 01）
10字節定長的命令（GET）
一個1字節的數據，表示命令參數的長度
不定長的命令參數
根據這些信息，使用模糊測試方法，我們就可以借助通用的模糊測試工具（如Spike），用模板方式將協議描述出來，并讓模糊測試工具自動填充可變字段的內容，生成大量的測試用例并發送給TgServer。同時，通過模糊測試工具提供的功能監視TgServer，一旦TgServer出現可被識別的問題（如性能下降，不再響應，或是返回異常數據等），我們就可以停止模糊測試，并通過日志找到導致問題的請求，進而確認問題。
簡單的說，模糊測試嘗試降低安全性測試的門檻，通過半隨機方式的數據發送來找出被測系統的漏洞。顯然，測試這對被測應用越了解，模糊測試的生成就能越準確。但與滲透測試或是代碼審查相比，模糊測試顯然更加易于進行。而且，通過自動化工具，模糊測試可以把安全方面的經驗積累到工具中，為組織持續的安全性測試提供幫助。
這是本系列的第一篇，后續還將寫兩篇來介紹不同類型應用的模糊測試，以及常用的模糊測試工具。
《模糊測試——強制發掘安全漏洞的利器》這本書全面覆蓋了模糊測試這一技術。