ASP.NET 上的 oracle padding 攻击是如何修复的？答案

【问题标题】：How was the oracle padding attack on ASP.NET Fixed?ASP.NET 上的 oracle padding 攻击是如何修复的？
【发布时间】：2014-09-24 17:14:02
【问题描述】：

微软昨天在 ASP.NET 中发布了他们的out of band release to fix the security flaw。

Microsoft 使用了哪些方法来终止这种载体的生存能力？

【问题讨论】：

迟早会有人使用 NDepend 或 Reflector 比较 System.Web.Extensions.dll 的两个版本。
@Mauricio，AES 实现是非托管代码，所以我认为 Reflector 或 NDepend 不会有太大帮助 :-) 如果它是纯托管修复，则不会有每个可以想象的补丁版本Windows 版本、CPU 类型、...
@Darin：这仅列出 System.Web.Extensions.dll support.microsoft.com/kb/2416473
@Mauricio，是的，这确实是正确的，但是这个程序集在我的计算机上是 1.75MB，而补丁是 7.42MB。这可能是安装程序位。
刚刚看了补丁内容：System.Web 和 System.Web.Extensions 程序集受到影响。

【解决方案1】：

不要泄露异常信息 - 这可以防止漏洞利用看到什么被破坏。
不要在填充检查上短路（填充正确的时间与填充损坏的时间相同）- 这样可以防止漏洞利用看到错误填充的时间差异。
不要对 IHttpHandler.ProcessRequest 中的异常捕获过于挑剔 - 这可以防止漏洞利用看到您捕获了一种异常 (CryptographicException) 而不是所有异常。
从基于哈希的初始化向量切换到随机 IV - 这可以防止漏洞利用数据和哈希之间的关系更快地解密。
允许向后兼容 - 如果这会破坏某些内容，请允许部分还原新行为。
在通过代码审查时，进行更改以表明您已经考虑了新选项。

【讨论】：

【解决方案2】：

主要：对发送到浏览器的任何加密数据进行签名。这可以防止像攻击那样弄乱值以获取有关有效与无效填充的信息，即因为签名在所有这些情况下都不匹配。

需要注意的是，webresource and scriptresource 中允许文件检索的漏洞不应该发生。单独的简单加密并不意味着防篡改。换句话说，这不是对像填充预言攻击的其余部分那样的高级场景的疏忽（它仍然依赖于相同的事实，将修改后的加密数据发送回应用程序，而服务器上没有防篡改保护）。

除了上面的主要修复之外，预期会尝试隐藏更多加密侧通道并确保它不会破坏依赖于相同加密调用的其他功能（如 asp.net 成员资格）。

【讨论】：

【解决方案3】：

该漏洞与 CBC Padding 引入的缺陷有关。攻击背后的完整理论可以在here 找到。但是，您必须先阅读block cipher modes of operation。

【讨论】：