幾天前從 ScottGu's Blog 得知了一個 ASP.NET 的重大資安弱點，微軟緊急的在最短時間內推出安全性更新，目前已正式發佈至 Windows Update 網站，各位 IT 人員隨時都能透過 Windows Update 套用這次的安全性重大更新，以確保 ASP.NET 網站能夠正常運作。由於這次的安全性更新被歸類為「重大」等級，所以各位還是盡可能早更新、早安心，不要等出事了才反應喔！
本次的重大安全更新主要解決了一個在 ASP.NET 執行環境下可能會被進行阻斷服務攻擊 (DoS；Denial of Service) 的問題，由於這類攻擊手法已於 2011-12-28 在德國的 Chaos Communication Congress 駭客年會中被公開，研究員 Julian Wälde 與 Alexander Klink 在現場展示如何透過一個自訂的表單攻擊目前市面上多個知名的 網站應用程式框架 (Web Application Frameworks)，其中包括 PHP 4, PHP 5, Java / JSP, Apache Tomcat, Jetty, ASP.NET, Python, v8, … 等，他可以利用極少的 HTTP Requests 癱瘓現有的網站伺服器，而且不僅僅是 ASP.NET 可能受害，許多其他 Web 框架依然無法倖免於難！
還好目前微軟已再極短的時間內推出安全性更新，請各位開發人員抽空更新主機。
以下是套用 Windows Update 時會看到與 .NET Framework 相關的安全性更新，不同的作業系統與版本可能會有不同的選項出現，以下只是 Windows 7 SP1 x86 環境下 .NET 3.5.1 的安全性更新示意圖：
請注意：套用之後可能會被要求重開機或強制重開機，安裝此更新時請做好測試或其他因應措施。
技術摘要說明
我們在開發 ASP.NET 網站時通常都會使用 Request.Form 物件來取得透過瀏覽器 POST 過來的資料，而此物件型別為 NameValueCollection 類別，該類別儲存 Key 的方式是透過雜湊運算的方式計算出來的 (hash-table data-structures)，主要目的就是為了用極快的速度找到該 Key 的對應資料，不過此類別自行實做了有別於 .NET Framework 內建的雜湊演算法，它會將所有傳入的 Key 都先轉換為大寫，並使用名為 DJBX33X (Dan Bernstein's times 33, XOR) 的雜湊演算法進行計算，這將導致此演算法有機會遭到 Meet-in-the-middle 攻擊。
駭客能利用這個弱點實做出輕易可達成的 雜湊碰撞攻擊 (Hash collision attacks)，此類攻擊可透過傳入大量的 POST 資料並且夾帶許多特別計算過的 Key 值，讓這些 Key 值在這些 Hash-table 中產生出相同的雜湊值，如此一來在這個 Hash-table 中就會出現許多擁有相同雜湊值的 Key，這便是「雜湊碰撞」的由來。而這類雜湊碰撞的情況正是 DJBX33X 演算法的致命傷，當一個 NameValueCollection 中存在著過多的「雜湊碰撞」就會導致電腦花上許多時間對該 Hash-table 進行運算，所以會讓 ASP.NET 執行緒花上數十分鐘到數小時的時間來操作相對應的 Key 值，如此一來便會耗盡網站伺服器的 CPU 資源，進而達到阻斷服務的目的。
備註：在此 阻斷服務 的意思是指讓網站執行速度變慢或完全無法回應其他人的要求。
如下圖示 0 ~ 5 區塊便是運算出來的「雜湊值」，而 EzEz, EzFY, FYEz, FYFY 等等就是示意傳入的 Key 值，當你要 Hash-table 中進行 插入 (insert)、查找 (lookup)、刪除 (delete) 鍵值(Key) 時，每次都會花上 O(n2) 的複雜度進行運算，當擁有重複雜湊值的 Key 越來越多時，電腦對此 Hash-table 所花費的運算成本也會更高。
研究員提到：由於 IIS 的「關閉時間限制」預設值為 90 秒 (如下圖示)，如果駭客連接到 ASP.NET 網站的網路速度為 30 kbit/s 的情況下，就能讓主機上某一個 Core2 等級的核心異常忙碌，若擁有 1 Gigabit/s 的頻寬便能同時間癱瘓約 30,000 個核心，所以就算你的主機叢集架構多彈性或多堅固，都很有可能只要一台機器就能癱瘓你整個機房的 Web Farm 主機。
這樣的攻擊手法可稱為一個「有效率的阻斷服務攻擊」，因此微軟便將此攻擊視為「重大資安弱點」。
2012/1/2 補充資訊
以下是 Efficient Denial of Service Attacks on Web Application Platforms 這場演講的完整錄影，將近一小時 ( http://www.youtube.com/watch?v=R2Cq3CLI6H8 )，關於 ASP.NET 相關的解說是從 26:55 ～ 31:26 這段時間，可以點選 這個連結 看我剪輯過的版本，或直接看所有的解說（包含攻擊展示）。
註：下載高解析度的版本 http://bit.ly/rKwW58
本次微軟推出的安全性更新主要是讓 ASP.NET 在處理 HTTP POST 要求時最多只能接受 1,000 個參數，一般來說不會有人透過 POST 傳遞表單資料超過 1,000 個欄位 ( 以筆者的經驗來說，傳過最多的一次是 700 個欄位，當時是個問卷系統 )，如果傳數參數超過 1,000 筆的話，就會出現 Operation is not valid due to the current state of the object. (英文) 或 由於該物件目前的狀態，導致作業無效。 (中文) 例外狀況，細部的例外訊息會有 HttpException (0x80004005): The URL-encoded form data is not valid. (英文) 或 HttpException (0x80004005): URL 編碼型式資料無效。 (中文) 等資訊，如下圖示：
若你的 Web 應用程式真的會傳遞超過 1,000 個欄位時，這個預設值也是可以設定的，請修改網站根目錄下的 web.config 檔，並在 <appSettings> 區段加上一組 aspnet:MaxHttpCollectionKeys 設定即可：
<appSettings>
<add key="aspnet:MaxHttpCollectionKeys" value="2500" />
</appSettings>
最後提醒
此問題並不只限於 ASP.NET 平台，其他像是 Java、PHP、JRuby、Python 等知名的 Web Application Framework 都是在受害的範圍內，請適時做出適當的更新與處理。
- 備註：PHP 5.4.0 RC4 新增了一個 max_input_vars 選項可控制輸入的參數的總數，此舉將可有效降低此弱點所帶來的衝擊。
還好我們有微軟當靠山，有這種問題只要 Windows Update 一下就能解決了，各位 ASP.NET 開發人員有沒有覺得很幸福呢！ ^__^
相關連結