原文发布时间为：2010-09-20 —— 来源于本人的百度文章 [由搬家工具导入]
原文：http://weblogs.asp.net/scottgu/archive/2010/09/18/important-asp-net-security-vulnerability.aspx
微软在9月17号中午正式对外公布了ASP.NET平台下的安全漏洞，即Microsoft Security Advisory (2416728)。
SecurityFocus上已将此漏洞定义成了"Design Error"，那么微软一开始的设计就是错误的，为什么这么说呢？且待我们慢慢来分析。
上午在园友辰的一篇博文：对ASP.NET的最新安全漏洞进一步跟进说明中也看到了对此问题的详细追踪，但上午也只是粗粗浏览，下午细看时总觉文中有些地方略显含糊，所以晚上也就顺带查了些资料，略有所得，不敢独享，遂成此文！
微软的态度查看了许多微软官方的说明文档，总觉得这位大姑娘犯了错后总是显得扭扭捏捏，遮遮掩掩，当然对于这个比较大的安全漏洞，不管是出于商业角度的考虑还是对现有.NET架构网站的保护，我们都暂且不去谈论它，但我想攻防该有的一条策略就是：知己知彼，百战不殆！
首先，比较长的一篇文章就是ScottGu的这篇：Important: ASP.NET Security Vulnerability。
在这篇文章中，其主要谈及了此漏洞的影响，简单提及了一下此漏洞产生的原因，下面就是微软教科书式的解决方案了。
这个解决方案有两个注意点：
1：
If you are using ASP.NET 3.5 SP1 or ASP.NET 4.0 then you should follow the below steps to enable <customErrors> and map all errors to a single error page:
1) Edit your ASP.NET Application’s root Web.Config file. If the file doesn’t exist, then create one in the root directory of the application.
2) Create or modify the <customErrors> section of the web.config file to have the below settings. Note the use of redirectMode=”ResponseRewrite” with .NET 3.5 SP1 and .NET 4.0:
<configuration> <system.web> <customErrors mode="On" redirectMode="ResponseRewrite" defaultRedirect="~/error.aspx" /> </system.web></configuration>
3) You can then add an Error.aspx to your application that contains an appropriate error page of your choosing (containing whatever content you like). This file will be displayed anytime an error occurs within the web application.
4) We recommend adding the below code to the Page_Load() server event handler within the Error.aspx file to add a random, small sleep delay. This will help to further obfuscate errors.
2：在错误页面中添加的一段代码，我先贴出来，看了下面的分析，我想你就该理解那段代码什么意思了。
<%@ Page Language="C#" AutoEventWireup="true" %>
<%@ Import Namespace="System.Security.Cryptography" %>
<%@ Import Namespace="System.Threading" %>
<script runat="server">
void Page_Load() {
byte[] delay = new byte[1];
RandomNumberGenerator prng = new RNGCryptoServiceProvider();
prng.GetBytes(delay);
Thread.Sleep((int)delay[0]);
IDisposable disposable = prng as IDisposable;
if (disposable != null) { disposable.Dispose(); }
}
</script>
<html>
<head runat="server">
<title>Error</title>
</head>
<body>
<div>
An error occurred while processing your request.
</div>
</body>
</html>
当然，在这里你还可以看到一些类官方的讨论。
什么叫Padding Oracle在ScottGu的文章中也提到了Padding Oracle，"......, there is a vulnerability in ASP.NET which acts as a padding oracle"。
首先得承认，padding和Oracle的确太迷惑人了，css+数据库，还挺挑战想象力的。
本人也想不出太好的中文翻译，就直译成了"附加断言"(oracle: 神谕、预言)，还望各位指正。
好了，我们来看看Padding Oracle到底是什么。
在ASP.NET中设计ViewState等加密字符串时，在加密算法中，当提交一个文本(ciphertext)去加密后，加密函数将返回是否成功，如返回valid或invalid。
那么攻击者使用不同的值去提交，并捕获返回的值，对每次返回的值进行分析，再纠正，重新提交，就这样解密出原文。那么需要多少次可以解密出到明文呢？答案是：128*N，N是这段密文的字节数，所以也就有了博友辰文章中提到的： 这个过程100%成功而且只需要30分钟。（当然：不会是100%成功的！）
原文是这样的：
The attack works under the assumption that the attackers can intercept padded messages encrypted in CBC mode, and have access to the aforementioned padding oracle. The result is that attackers can recover the plaintext corresponding to any block of ciphertext using an average of 128 * b oracle calls, where b is the number of bytes in a block.
理解有失偏颇的，提醒下。
那么在博友辰的文章中还提到了：这个问题不仅仅存在于asp.net,而且还有java等。
这个背景在于：在隐藏字段（如ViewState），cookies，请求参数中，当加密成BASE64字符串时都涉及到这个漏洞，而在一些Java框架，如JavaServer Face中也设计了ViewState的东西，所以才有了上面的结论。
如何攻击其实此漏洞的利用在2002年的Eurocrypt会议中已经被提及过了，可以去BlackHat网站下载PDF查看，本人上文的许多分析也提炼自此文档。
Then we decode each Base64 string found. If the result looks random, and its length is a multiple of common block cipher sizes, i.e. 8, 16 or 32 bytes, then there’s a good chance that it is a ciphertext. We also look for common separators, i.e. --, | or :, which are often used to separate IV, ciphertext, or MAC. Then we replace a byte in the last block of the ciphertext by a random value, then send it back to the target, and see what changes in the response. If there is an error message, then there’s a high chance that this is a Padding Oracle.
此段英文就比较简单了，也很明了地说明了测试是否可破解的方法。
每次替换掉最后一个字节，并将新拼接的字符串提交加密，再记录返回结果，如果可以，那么再进一步解密出原文。
到这里，我们大概对此漏洞有了一个清晰的认识，欲深入分析请查看上面的PDF文档。
再回过来看ScottGu公布的解决方案，我的猜想是：
添加错误配置节，当攻击者第一次尝试破解时，被配置节强制跳转到错误页面，在错误页面中，如果发现提交过来的构造密码种子(我理解成了种子 :) )为1，那么就将其对象强行Dispose掉，那么攻击者也就没法继续下去了。
小结那么微软将如何去修复此漏洞呢，修改加密机制，还是......，持续关注。
好了，我的分析就到这里，也很晚了，文章中欠妥的地方，欢迎拍砖，一起再讨论下！