MVC 5 - 缓解 BREACH 漏洞答案

【问题标题】：MVC 5 - Mitigating BREACH VulnerabilityMVC 5 - 缓解 BREACH 漏洞
【发布时间】：2015-05-19 16:23:56
【问题描述】：

我希望有人能够帮助我理解这个问题以及我是否需要采取任何额外的步骤来保护我的应用程序。

阅读此特定漏洞，它似乎会影响符合以下条件的服务器：

似乎缓解步骤，按有效性顺序是：

在我的页面视图中，我正在调用辅助方法@Html.AntiForgeryToken，它在我访问表单时创建相应的输入和cookie。从查看此辅助方法的作用来看，似乎每次加载页面时都会创建一个新的唯一令牌，这似乎符合缓解步骤中的第 3 点，并且首先使用 CSRF 令牌的行为符合第 5 点.

禁用 HTTP 压缩似乎被广泛认为“不利于性能”，从我一直在阅读的其他一些资源来看，长度隐藏可能会导致文件上传（本页面使用）等功能出现问题

所以，毕竟，我现在唯一能真正看到的就是将秘密与用户输入分开。我考虑过可能尝试将 CSRF 令牌值放入会话中......或者我是否完全过度思考这一点，'@Html.AntiForgeryToken` 的当前实现是否足以保护我们？

【问题讨论】：

禁用动态页面的 HTTP 压缩并确定它是否会影响您的性能。（可能不会。）
@minitech 我正在托管此应用程序的当前 IIS 服务器，甚至没有安装动态内容模块
我不知道那是什么。 “动态页面”指的是该评论中的“不是静态资源的东西”。
我有同样的问题，很想找到任何答案。 AntiForgeryToken() 助手听起来确实每次都应该改变响应，我认为这应该可以解决问题。此外，它发生在一个甚至没有像密码这样的秘密的页面上。在一个只有纯文本用户输入字段的页面上。
我不明白你真正想做什么。你的最终目的是什么（例如主要问题是什么？）

【解决方案1】：

Anti-Forgery/CSRF Token 还不够吗？在 MVC 中，您可以使用 Html.AntiForgeryToken()。我之前在我的 MVC 应用程序上使用过它，它确实减轻了违规行为。

【讨论】：

【解决方案2】：

是的，如果 CSRF 令牌是随机的，那么它可以减轻攻击。只要您不使用用户输入表单发送任何其他机密，就可以了。

或者，

也可以在有用户输入的页面上禁用压缩。签出这个答案Can gzip compression be selectively disabled in ASP.NET/IIS 7?

【讨论】：