此文為Infoq中文站QSecurity專欄供稿

2011年12月28日，由Google贊助成立的安全漏洞研究組織oCERT（Open source Computer Emergency Response Team — 開源軟件應急響應團隊）公開了一份安全漏洞報告。這份報告是幾個月前由德國安全研究公司nrun.com所提供的，其核心內容是：目前絕大多數的web應用，都存在著一個叫做哈希碰撞式拒絕服務攻擊的漏洞（Hash Collision DoS）。這份報告的公布，使得2011年剩下的幾天里，各互聯網公司的技術團隊集體忙于對網站進行針對此漏洞的防護工作。硝煙散盡之后，讓我們一起從攻擊者的角度重新審視一下這個漏洞及其利用手法。

如果你熟悉幾種常用語言下的哈希表（HashTable）實現，你大概會清楚以下的一些關于哈希表的基本概念：

哈希表通過一個哈希函數對鍵值（key）進行散列操作，并且最終根據散列結果將鍵值對（key-value-pair）儲存到數組的某個節(jié)點（一般通過對數組長度取余實現）。哈希表的數組長度會根據元素的實際數量動態(tài)進行擴容，以保證有足夠空間并降低取余后的結果出現重復的可能性。不同的實現，其初始默認長度、擴容條件及擴容算法均可能有所區(qū)別。

極端情況下，哈希表將會退化成鏈表。根據上面的基礎知識，我們知道這里的極端情況包括兩種：所有元素的哈希值相等；或者所有元素的哈希值針對哈希表數組長度取余的結果相等。而退化為鏈表則會導致哈希表性能的急劇下降。實際測試中，針對8萬條級別的數據，原本只需要數毫秒即可完成的插入或者查詢操作，在退化為鏈表后則需要長達30秒以上的時間才能完成。

那么對攻擊者來說，利用這一原理對某個web站點發(fā)起拒絕服務攻擊只需要考慮以下兩個問題：

問題一、如何構造一個可使哈希表完全退化成鏈表的鍵值集合。問題二、如何使用該集合引導目標服務器建立一個哈希表數據結構。

針對問題一，具體的思路很簡單，就是要找到一個字符串集合，使得該集合的每個元素要么滿足哈希值相等；要么使得其哈希值針對哈希表數組長度取余的結果相等。構造大量的哈希沖突是一個比較困難的問題。但是對攻擊者來說，非常幸運的是目前常見的哈希表的哈希函數實現，都是基于著名的DJBX33哈希算法或者其變形算法。比如，PHP5使用的是DJBX33A；ASP.NET和Python使用的是DJBX33X；Java使用的是一個做了兩個常數變形的變種DJBX33A。針對這些哈希算法，攻擊者已經可以有很多方法做針對性的哈希碰撞生成了。最常用的方法有“相等子串法”和“中間相遇法”等。以“相等子串法”為例，由于DJBX33A系列哈希算法滿足一個很有意思的特性：如果hash(“string1”) = hash(“string2”)，那么在相同位置包含此2個子串的父串哈希結果將會產生碰撞，既：hash(“prefix_string1_postfix”) = hash(“prefix_string2_postfix”)。根據這一特性，攻擊者如果能找到最簡單的兩個碰撞字符串，那么就可以很快通過反復組合，生成2的n次方個長度為2n的碰撞字符串。“中間相遇法”事實上是一種暴力破解辦法。只不過通過巧妙刪選縮小了結果集的甄別范圍，然后在可能產生碰撞的結果集中遍歷尋找碰撞集合。除此之外，針對較為復雜的哈希算法的碰撞，如MD5等算法，我國的王小云教授的“模差分法”是一種比較實用的碰撞分析方法。

如果通過算法構造哈希結果完全一致的字符串集合有難度，那么也可以退而求其次，只要滿足哈希值對哈希表數組長度取余的最終結果相等就可以了。網上目前有很多針對PHP的示例攻擊代碼，就是根據這個原理實現的。利用這種方式，需要對該語言下哈希表數組經過反復擴容后的最終長度如何產生有一個清楚的了解。例如在PHP的實現中，所有哈希表數組的長度一定是2的n次方。根據元素總個數和加載因子（一個哈希表實現中滿足擴容條件的臨界值），就可以計算出最終生成的哈希表的數組長度。剩下的事情就只需要保證待選鍵值的哈希結果對這個長度取余的結果相等，這樣即可達到制造大量哈希沖突字符串的目的。

在成功構造好一個可以使哈希表完全退化成鏈表的鍵值集合后，攻擊者需要來解決第二個問題：如何使用該集合在服務器端建立一個哈希表數據結構。

這個問題事實上已經再簡單不過了：在所有的web應用中，為了方便程序對web請求的各項參數進行快速讀操作，HTTP Request中的Header, Form以及QueryString，都使用了哈希表進行存儲。那么剩下的工作很簡單：就是以我們精心構造好的鍵值列表作為一次HTTP請求的Header，Form或者QueryString就可以了。實際攻擊中，由于大量Form表單的Post構造更加簡單，甚至可以使用瀏覽器完成，所以也會通常成為進行攻擊的首選突破口。通過在單機上重復構造大量的HTTP Post請求，向Web服務器發(fā)送大量表單數據，會使得目標服務器的CPU迅速被占滿而失去服務能力，達到攻擊目的。

如果對方的服務器數量比較多，或者防火墻敏銳地發(fā)現了攻擊者短時間內向服務器Post大量數據的行為，并進行了阻截，那么有可能還是達不到讓對方“拒絕服務”的目的。這種情況下，攻擊者會傾向于使用一定數量的“僵尸網絡”對目標發(fā)起攻擊。由于這個攻擊非常簡單，只需要構造一個HTTP請求即可實現，那么你可以去自己創(chuàng)建一個內容非常吸引人的頁面，或者利用一個訪問量較大但是存在跨站腳本漏洞（XSS）的頁面，在頁面中加入一小段對最終用戶不可見，但是會自動發(fā)送一個Post請求到目標站點的JavaScript腳本，你的拒絕服務攻擊（DoS）就成功升級為分布式拒絕服務攻擊（DDoS）了。而訪問這些頁面的普通用戶，則會在不知情的情況下成為幫助你繼續(xù)攻擊的“僵尸”群。

文章的最后，還是想補充一下關于針對這類攻擊的防護工作。目前絕大部分的補丁都是針對HTTP請求中表單項的數量加以限制。這個方法確實有效。測試數據顯示，1000個元素的鏈表操作對性能的影響還是可以接受的。但是如果你的Web應用在服務端需要接收某個表單項，并通過字符處理（不管是XML還是JSON）將用戶輸入的表單值轉換成哈希表的話，那么很遺憾，目前這些補丁都幫不了你，你的應用將依然存在被拒絕服務攻擊的可能。只不過攻擊的方式從構造HTTP Request中的哈希表，變成了構造實際業(yè)務處理代碼中的哈希表。對這一問題的完美解決方案，應該是如Perl在n年前做的那樣：在哈希算法中引入隨機鹽使得構造哈希沖突變?yōu)椴豢赡堋?/p>