年 月 日
模糊測試（Fuzz testing ）是一項對代碼質量有著深遠影響的簡單技術在本文中Elliotte Rusty Harold 故意將隨機的壞數據插入應用程序以觀察發生的結果他也解釋了如何使用如校驗和XML 數據存儲及代碼驗證等防護性編碼技術來加固您的程序以抵制隨機數據他以一個練習進行總結在練習中他以一個代碼破壞者的角度進行思考 —— 這是一種用於防護代碼的至關重要的技術
多年來我驚歎於有如此大量能夠使 Microsoft Word 崩潰的壞文件少數字節錯位會使整個應用程序毀於一旦在舊式的無內存保護的操作系統中整個計算機通常就這樣宕掉了Word 為什麼不能意識到它接收到了壞的數據並發出一條錯誤信息呢？為什麼它會僅僅因為少數字節被損壞就破壞自己的棧堆呢？當然Word 並不是惟一一個面對畸形文件時表現得如此糟糕的程序
本文介紹了一種試圖避免這種災難的技術在模糊測試中用隨機壞數據（也稱做 fuzz）攻擊一個程序然後等著觀察哪裡遭到了破壞模糊測試的技巧在於它是不符合邏輯的自動模糊測試不去猜測哪個數據會導致破壞（就像人工測試員那樣）而是將盡可能多的雜亂數據投入程序中由這個測試驗證過的失敗模式通常對程序員來說是個徹底的震憾因為任何按邏輯思考的人都不會想到這種失敗
模糊測試是一項簡單的技術但它卻能揭示出程序中的重要 bug它能夠驗證出現實世界中的錯誤模式並在您的軟件發貨前對潛在的應當被堵塞的攻擊渠道進行提示
模糊測試如何運行
模糊測試的實現是一個非常簡單的過程
准備一份插入程序中的正確的文件
用隨機數據替換該文件的某些部分
用程序打開文件
觀察破壞了什麼
可以用任意多種方式改變該隨機數據例如可以將整個文件打亂而不是僅替換其中的一部分也可以將該文件限制為 ASCII 文本或非零字節不管用什麼方式進行分割關鍵是將大量隨機數據放入應用程序並觀察出故障的是什麼
測試基於 C 的應用程序
當字符串包含額外的零時
許多用 C 編寫的程序都會出問題 —— 這類問題太過頻繁以至於額外的零能夠徹底隱藏代碼中其他的問題
一旦驗證出程序存在零字節問題
就可以移除它們
從而讓其他的問題浮現出來
可以手動進行初始化測試但要想達到最佳的效果則確實需要采用自動化模糊測試在這種情況下當面臨破壞輸入時首先需要為應用程序定義適當的錯誤行為（如果當輸入數據被破壞時您發現程序正常運行且未定義發生的事件那麼這就是第一個 bug）隨後將隨機數據傳遞到程序中直到找到了一個文件該文件不會觸發適當的錯誤對話框消息異常等等存儲並記錄該文件這樣就能在稍後重現該問題如此重復
盡管模糊測試通常需要一些手動編碼但還有一些工具能提供幫助例如清單 顯示了一個簡單的 Java&#; 類該類隨機更改文件的特定長度我常願意在開始的幾個字節後面啟動模糊測試因為程序似乎更可能注意到早期的錯誤而不是後面的錯誤（您的目的是想找到程序未檢測到的錯誤而不是尋找已經檢測到的）
清單
用隨機數據替換文件部分的類
import javaio*;
import javasecuritySecureRandom;
import javautilRandom;
public class Fuzzer {
private Random random = new SecureRandom();
private int count = ;
public File fuzz(File in int start int length) throws IOException
{
byte[] data = new byte[(int) inlength()];
DataInputStream din = new DataInputStream(new FileInputStream(in));
dinreadFully(data);
fuzz(data start length);
String name = fuzz_ + count + _ + ingetName();
File fout = new File(name);
FileOutputStream out = new FileOutputStream(fout);
outwrite(data);
outclose();
dinclose();
count++;
return fout;
}
// Modifies byte array in place
public void fuzz(byte[] in int start int length) {
byte[] fuzz = new byte[length];
randomnextBytes(fuzz);
Systemarraycopy(fuzz in start fuzzlength);
}
}
關於代碼
我可以用很多種方式優化 清單
中的代碼
例如
有著 java
nio 的內存映射文件是一個相當不錯的選擇
我也能夠改進這個錯誤處理及可配置性
因為不想讓這些細節混淆這裡所要說明的觀點
所以我將代碼保持了原樣
模糊測試文件很簡單將其傳至應用程序通常不那麼困難如 AppleScript 或 Perl 腳本語言通常是編寫模糊測試的最佳選擇對於 GUI 程序最困難的部分是辨認出應用程序是否檢測出正確的故障模式有時最簡單的方法是讓一個人坐在程序前將每一個測試通過或失敗的結果都標記下來一定要將所有生成的隨機測試用例單獨地命名並保存下來這樣就能夠重現這個過程中檢測到的任何故障
防護性編碼
可靠的編碼遵循了這樣的基本原則絕不會讓程序中插入未經過一致性及合理性驗證的外部數據
如果從文件中讀入一個數字並期望其為正數那麼在使用其進行進一步處理前對其先驗證一下如果期望字符串只包含 ASCII 字母請確定它確實是這樣如果認為文件包含一個四字節的整數倍的數據請驗證一下一定不要假設任何外部提供的數據中的字符都會如您所料
最常見的錯誤是做出這樣的假設因為程序將該數據寫出該程序就能不用驗證再一次將該數據讀回去這是很危險的！因為該數據很可能已經被另一個程序在磁盤上復寫過了它也可能已經被一個故障磁盤或壞的網絡傳輸所破壞了或已經被另一個帶 bug 的程序更改過了它甚至可能已經被故意更改過以破壞程序的安全性所以不要假設任何事要進行驗證
當然錯誤處理及驗證十分令人生厭也很不方便並被全世界程序員們所輕視計算機的誕生已進入了六十個年頭我們仍舊沒有檢查基本的東西如成功打開一個文件及內存分配是否成功讓程序員們在閱讀一個文件時測試每一個字節和每一個不變量似乎是無望的 —— 但不這樣做就會使程序易被模糊攻擊幸運的是可以尋求幫助恰當使用現代工具和技術能夠顯著減輕加固應用程序的痛苦特別是如下三種技術更為突出
校驗和
基於語法的格式
如 XML
驗證過的代碼如 Java
用校驗和進行的模糊試驗
能夠保護程序抵御模糊攻擊的最簡單的方法是將一個檢驗和添加到數據中例如可以將文件中所有的字節都累加起來然後取其除以 的余數將得到的值存儲到文件尾部的一個額外字節中然後在輸入數據前先驗證檢驗和是否匹配這項簡單模式將未被發現的意外故障的風險降低到約 /
健壯的校驗和算法如 MD 和 SHA 並不僅僅取其除以 的余數它完成的要多得多在 Java 語言中javasecurityDigestInputStream 和 javasecurityDigestOutputStream 類為將一個校驗和附屬到數據中提供了便捷的方式使用這些校驗和算法中的一種可以將程序遭受意外破壞的機率降低到少於十億分之一（盡管故意攻擊仍有可能）
XML 存儲及驗證
將數據以 XML 形式存儲是一種避免數據損壞的好方法XML 最初即著力於 Web 頁面書籍詩歌文章及相似文檔它幾乎在每個領域都獲取了巨大的成功從金融數據到矢量圖形到序列化對象等等
不切實際的限定
如果真想要破壞一個 XML 解析器
有幾種方法可以試試
例如
大多數 XML 解析器服從於特定的最大尺寸
如果一個元素名長度超過
億字符（Java String 的最大尺寸）
SAX 解析器將會失敗
盡管如此
在實踐中這些極限值如此之高
以至於在達到之前內存就已經耗盡
使 XML 格式抵制模糊攻擊的關鍵特征是一個對輸入不做任何 假設的解析器這就是真正想在一個健壯的文件格式中所獲得的設計 XML 解析器是為了讓任何輸入（格式良好的或無格式的有效的或無效的）都以定義好的形式處理XML 解析器能夠處理任何 字節流如果數據首先通過了 XML 解析器則僅需要准備好接受解析器所能提供的東西例如不需要檢查數據是否包含空字符因為 XML 解析器絕不會傳送一個空值如果 XML 解析器在其輸入中看到一個空字符它就會發出異常並停止處理當然還需要處理這個異常但編寫一個 catch 塊來處理檢測到的錯誤比起編寫代碼來檢測所有可能的錯誤來說要簡單得多
為使程序更加安全可以用 DTD 和/或模式來驗證文檔這不僅檢查了 XML 是否格式良好而且至少與所預期更加接近驗證並不會告知關於文檔所需了解的一切但它卻使編寫大量簡單檢查變得很簡單用 XML很明顯能夠將所接受的文檔嚴格地限定為能夠處理的格式
盡管如此還有多段代碼不能用 DTD 或模式進行驗證例如不能測試發票上商品的價格是否和數據庫中庫存商品的價格一致當從客戶接收到一份包含價格的訂單文檔時不論其是 XML 格式或是其他格式在提交前通常都會檢查一下以確保客戶並未修改價格可以用定制代碼實現這些最後的檢查
基於語法的格式
使 XML 能夠對模糊攻擊具有如此的抵御能力的是其使用巴科斯諾爾范式（BackusNaur FormBNF）語法仔細且標准地定義的格式許多解析器都是使用如 JavaCC 或 Bison 等解析器生成器工具直接從此語法中構建的這種工具的實質是閱讀一個任意的輸入流並確定其是否符合此語法
如果 XML 並不適合於您的文件格式您仍可以從基於解析器的解決方案的健壯性中獲益您必須為文件格式自行編寫語法隨後開發自己的解析器來閱讀它相比使用唾手可得的 XML 解析器開發自己的解析器需要更多的工作然而它是一個更為健壯的解決方案而不是不根據語法正式地進行驗證就將數據簡單地裝載到內存中
Java 代碼驗證
由模糊測試導致的許多故障都是內存分配錯誤及緩沖器溢出的結果用一種安全的垃圾收集語言（在如 Java 或 managed C# 等虛擬機上執行的）來編寫應用程序避免了許多潛在問題即使用 C 或 C++ 來編寫代碼還是需要使用一個可靠的垃圾收集庫在 年台式機程序員或服務器程序員不應該還需要管理內存
Java 運行時對其自身的代碼起到了額外保護層的作用在將一個 class 文件裝載到虛擬機之前該文件要由一個字節符驗證器或一個可選的 SecurityManager 進行驗證Java 並不假設創建 class 文件的編譯器沒有 bug 且運轉正常設計 Java 語言之初就是為了允許在一個安全沙箱中運行不信任的潛在惡意的代碼它甚至不信任其自身編譯過的代碼畢竟也許有人已經用十六進制編輯器手工修改了字節符試圖觸發緩沖器溢出我們大家都應該對我們的程序也有對輸入這樣的偏執
以敵人的角度思考
之前介紹的每項技術都在阻止意外破壞方面造詣頗深將它們綜合起來恰當地實現會將未被發現的非蓄意破壞發生的可能性幾乎減少到零（當然並不會減少到零但其發生的可能性就如同一束偏離軌道的宇宙射線將您 CPU 運算 + 的結果變為 的可能性一樣微乎其微）但不是所有的數據損壞都是非蓄意的如果有人故意引入壞數據來破壞程序的安全性又該如何呢？以一個攻擊者的角度進行思考是防護代碼的下一個步驟
轉回到一個攻擊者的角度進行思考假設要攻擊的應用程序是用 Java 編程語言編寫的使用非本地代碼且將所有額外數據都以 XML（在接受前經過徹底驗證）形式存儲還能成功攻擊嗎？是的能但用隨機改變文件字節的低級方法顯然不行需要一種更為復雜的方法來說明程序自身的錯誤檢測機制及路徑
當測試一個抵御模糊攻擊的應用程序時不可能做純黑盒測試但通過一些明顯的修改基本的想法還是可以應用的例如考慮校驗和如果文件格式包含一個校驗和在將文件傳至應用程序前僅僅修改此校驗和就可以使其同隨機數據相匹配
對於 XML試著模糊單獨的元素內容和屬性值而不是從文檔中挑選一部分隨機的字節進行替換一定要用合法的 XML 字符替換數據而不要用隨機字節因為即使一百字節的隨機數據也一定是畸形的也可以改變元素名稱和屬性名稱只要細心地確保得到的文檔格式仍是正確的就可以了如果該 XML 文檔是由一個限制非常嚴格的模式進行檢查的還需要計算出該模式沒有 檢查什麼以決定在哪裡進行有效的模糊
一個結合了對剩余數據進行代碼級驗證的真正嚴格的模式也許不會留下可操縱的空間這就是作為一個開發人員所需要追求的應用程序應能夠處理所發送的任何有意義的字節流而不會因權利上（ de jure ） 無效而拒絕
結束語
模糊測試能夠說明 bug 在程序中的出現並不證明不存在這樣的 bug而且通過模糊測試會極大地提高您對應用程序的健壯性及抵御意外輸入的安全性的自信心如果您用 小時對程序進行模糊測試而其依然無事那麼隨後同種類型的攻擊就不大可能再危及到它（並不是不可能提醒您只是可能性很小）如果模糊測試揭示出程序中的 bug就應該進行修正而不是當 bug 隨機出現時再對付它們模糊測試通過明智地使用校驗和XML垃圾收集和/或基於語法的文件格式更有效地從根本上加固了文件格式
模糊測試是一項用於驗證程序中真實錯誤的重要工具也是所有意識到安全性問題且著力於程序健壯性的程序員們的工具箱中所必備的工具
關於作者
Elliotte Rusty Harold 來自新奧爾良 現在他還定期回老家喝一碗美味的秋葵湯不過目前他和妻子 Beth 定居在紐約臨近布魯克林的 Prospect Heights同住的還有他的貓咪 Charm（取自誇克）和 Marjorie（取自他岳母的名字）他是 Polytechnic 大學計算機科學的副教授他在該校講授 Java 和面向對象編程他的 Web 站點 Cafe au Lait 已經成為 Internet 上最流行的獨立 Java 站點之一它的姊妹站點 Cafe con Leche 已經成為最流行的 XML 站點之一他的書包括 Effective XML Processing XML with Java Java Network Programming 和 The XML Bible他目前在從事處理 XML 的 XOM APIJaxen XPath 引擎和 Jester 測試覆蓋率工具的開發工作
From:http://tw.wingwit.com/Article/program/Java/JSP/201311/19417.html
