1、漏洞描述：
Padding Oracle攻击指应用在解密客户端提交的加密数据时，泄露了解密数据的分段填充是否合法的信息。攻击者利用Padding Oracle可以在不知道加密程序所使用的密钥的情况下，解密数据或者加密任意数据。即使应用程序确认加密数据的完整性，仍会导致该程序仍有敏感数据泄露和越权漏洞的风险。
密文在被解密时，会被分成若干个数据块，每个数据块有固定的长度，常见的加密算法大多为8字节或16字节。当数据不满足指定长度时，程序会通过指定的方式进行填充，以方便在解密时能剥除这些这些填充数据。常见的填充标准有PKCS#7。当填充内容与标准要求的语法不一致时，会生成一个错误。如果应用在解析客户端提交的加密信息时泄露了这个填充出错的状态信息，就形成了Padding Oracle。
2、检测条件：
被测网站使用了ASP.NET、被测网站有未自定义统一错误页面的漏洞。
3、检测方法
首先需要确认Padding Oracle的“注入点”。通常可能有以下两种情形：
1、数据已加密。理想的加密数据应该是一串随机值。
2、密文已被分组。如分组为16或8位的倍数。
加密数据时，应用需要对密文的每一位进行确认。
解码字符串，翻转第b-1组字符的最后一个字节，重新编码并发送。然后解码原数据，翻转b-2组字符串的最后一个字节，重新编码并发送。如此尝试即此就能得到需要的结果。
在解密后至少会产生以下3种不同的结果：
1、密文被解密，输出结果是正确的。
2、密文被解密，输出结果不正确，会产生异常或引发应用逻辑错误。
3、由于Padding错误造成解密失败。
当Padding不正确时，产生异常或响应信息。则说明该应用有Padding Oracle风险。
4、修复方案
1、由于Padding Oracle攻击只需判断两种状态便可以进行攻击，可采取两种方法来避免这种攻击，第一种是在应用环境中当站点出现404或500时都返回同一状态码。第二种方法就是隐藏网页的错误信息。
2、避免在ViewState和Cookie中存放敏感数据。
3、不要过度依赖Machine Key。
4、在认证cookie里保存的不只是用户名，而是外界无法得知的ID，或是同时保存checksum等额外的验证信息。
5、为ScriptResource.axd写一个Wrapper，只让它输出扩展名为js的内容。