2010/9/18，由Scott Guthrie在blog上發表的一篇Important: ASP.NET Security Vulnerability的文章，點燃了ASP.NET應用程式的安全防護戰爭，因為受影響的範圍遍及ASP.NET 1.0-4.0所有的應用程式，讓使用ASP.NET開發應用程式的開發人員無一不陷入資訊安全的恐懼之中，在9/18日起的幾天內，許多與ASP.NET技術有關的blog都發出了這個安全性警告，因為這個漏洞在公布的同時，攻擊程式就已經在網路上出現了，這是資安所稱的零時差攻擊（Zero-Attack），零時差攻擊最大的特色就是在系統被修補之前，就有很高的機率被攻擊程式所攻擊（甚至攻陷），因此這個漏洞會在這麼短的時間內受到關注，是有其原因的。
** 2010/9/29 UPDATE: 這個問題微軟已釋出安全修補程式，可參考：http://weblogs.asp.net/scottgu/archive/2010/09/28/asp-net-security-update-now-available.aspx **
2010/9/18，由Scott Guthrie在blog上發表的一篇Important: ASP.NET Security Vulnerability的文章，點燃了ASP.NET應用程式的安全防護戰爭，因為受影響的範圍遍及ASP.NET 1.0-4.0所有的應用程式，讓使用ASP.NET開發應用程式的開發人員無一不陷入資訊安全的恐懼之中，在9/18日起的幾天內，許多與ASP.NET技術有關的blog都發出了這個安全性警告，因為這個漏洞在公布的同時，攻擊程式就已經在網路上出現了，這是資安所稱的零時差攻擊（Zero-Attack），零時差攻擊最大的特色就是在系統被修補之前，就有很高的機率被攻擊程式所攻擊（甚至攻陷），因此這個漏洞會在這麼短的時間內受到關注，是有其原因的。
攻擊原理
這次的零時差攻擊的漏洞是來自在ASP.NET內的加密核心機制，核心內使用的是對稱式加密演算法（Symmetric Algorithm），有學過資訊安全或密碼學的人應該知道，對稱式加密演算法是依靠一組固定的密鑰（Key）進行的加密程序，所有的加密與解密程序都要使用這一組密鑰來處理，包含DES、3DES、AES等演算法都是對稱型演算法。而這些演算法為了要強化密鑰的安全性，還會在密鑰的程序中加入一組初始向量值（Initialization Vector; IV），透過密文區塊串鍊（Cipher-Block Chain; CBC）的方式進行加密，解密時則是反向處理。
在ASP.NET中，很多與用戶端互動的功能都會用到加密功能，最典型的就是ViewState，或是Forms Authentication（表單驗證）的驗證用票證（ticket），而這些資訊通常都會儲存了高機密性的資訊，尤其是表單驗證中的票證，它會保存一些由開發人員所登錄的資訊（例如使用者識別碼），這些資訊一旦被破解出來，可以想像攻擊者會如何入侵系統而不被發覺。
而9/18的零時差攻擊漏洞，問題正是出現在加密這些資訊的演算法上，而攻擊的手法稱為Padding Oracle，這是一種透過由密文經過資料填補或位移的方式，推算出加密金鑰與初始向量的一種攻擊手法，在2002年時就被提出（當時被稱為Side-Channel攻擊法），但Padding Oracle被用於攻擊CBC加密模型，最早是由Kenneth G. Paterson與Arnold Yau於2004年所發表的Padding Oracle Attacks on the ISO CBC Mode Encryption Standard論文所揭露，當時它已經可以做到使用t + log2 n（t 是加密的金鑰位元數）的時間內，推算出加密用的金鑰（但不一定是正確的），而在2010年2月，由Juliano Rizzo與Thai Duongy發表的Practical Padding Oracle Attacks論文中，就已經將Padding Oracle攻擊手法應用在攻擊Java Server Face（JSF）的網站上，JSF的View State也是使用對稱金鑰加密法來實作的，而Juliano與Thai成功的開發出破解JSF View State的工具程式，稱為POET（Padding Oracle Exploit Tool），並且在他們的網站上釋出這些執行檔（有Linux, Mac, Windows等），對所有使用對稱加密演算法的Web Application Framework造成可能的威脅。ASP.NET本身也是使用對稱演算法進行加密的Framework，也受到這個漏洞的影響，他們已經用這個工具成功破解了由ASP.NET所開發的CMS應用程式套件－DotNetNuke－的加密金鑰，並將破解的過程錄影放在Youtube上，這也是為什麼這個漏洞會是零時差攻擊的主因。
NOTE: 目前已知使用CBC模式的對稱加密演算法，像DES, 3DES與AES等，都會受到這個漏洞的攻擊。
不過POET基本上不會入侵應用程式所在的主機，而是透過在Web Application Framework中所顯露的密文（Cipher Text）進行推算，並且將推算的資訊交給原本的解密程式進行驗證，POET工具假設解密程式一定會回傳有效或無效的訊息給攻擊端，在JSF的攻擊測試中，攻擊程式送出的金鑰如果無效的話，JSF會回傳javax.crypto.BadPaddingException的HTTP 500錯誤狀態給攻擊端，而成功的話會回傳HTTP 200（這在該論文中是以VALID/INVALID來設計），攻擊程式可利用這個方式來判斷這組金鑰是正確或錯誤的。因此若應用程式本身會針對HTTP 500進行與HTTP 200不同的反應的話，就很有可能被這個手法所攻擊。
防護措施
由於POET工具的判斷依據是使用應用程式所產生的密文，利用Padding Oracle的手法產生加密金鑰後，再送回給原加密程式進行驗證，因此要防禦這個攻擊手法，在應用程式端可以做的是：
1. 處理錯誤，並回傳一致的HTTP狀態，例如開啟自訂的錯誤頁，如此一來回傳的HTTP狀態會一致（都是HTTP 200），這是目前防禦POET工具的最好方法。
2. 利用錯誤頁回傳的，可以將回應時間拉長，讓POET工具的HTTP測試程式Timeout（但這無法防禦將Timeout設很大的測試程式）。
因此ASP.NET應用程式目前可以做的，就是在Web.config中加入自訂錯誤的頁面，並設定將custom errors的機制開放，作法可以參考Scott Guthrie的blog，有提供ASP.NET不同版本的方式：
<!-- for ASP.NET 1.0-3.5 (non SP1) -->
<configuration>
<system.web>
<customErrors mode="On" defaultRedirect="~/error.html" />
</system.web>
</configuration>
<!-- for ASP.NET 3.5 SP1 and 4.0 -->
<configuration>
<system.web>
<customErrors mode="On" redirectMode="ResponseRewrite" defaultRedirect="~/error.aspx" />
</system.web>
</configuration>
NOTE: 如果設為RemoteOnly基本上應也可行，因為它是針對遠端的電腦進行的。
若您的應用程式有自行處理Global.asax內的Application_Error事件來捕捉HTTP錯誤時，請記得所有錯誤都回傳相同的HTTP狀態，以避免攻擊程式依此來判斷金鑰的有效性。另外，微軟也提供了一個VBScript指令碼，可偵測在電腦內的ASP.NET Web應用程式是否有被攻擊的風險，這個指令碼可以在http://www.asp.net/media/782788/detectcustomerrorsdisabledv30.zip取得，執行方式如下：
[command prompt]
cscript DetectCustomErrors.vbs
NOTE: 不論您的應用程式是否有處理Global.asax的Application_Error事件，都請設定Web.config以加強防禦。
結語
POET是以加密的核心為目標進行攻擊的手法，屬於暴力攻擊的一種，透過Web應用程式對錯誤狀態處理的不一致性來驗證推算的金鑰是否正確，目前能夠根本解決這個問題的方式就是改用不同的加密演算法，以解決因為CBC加密模型而暴露的安全漏洞問題，但應用程式本身的安全設定也是重點，因為POET的驗證階段是利用原加密程式進行的，如果加密程式可以防堵驗證階段，POET工具的攻擊基本上就很難成功，因此平時對應用程式的安全控制也是非常重要的，它會在你不經意的時候發揮作用，以保護應用程式的安全。