我希望有人能够帮助我理解这个问题，以及我是否需要采取任何额外步骤来保护我的应用程序。
阅读此特定漏洞，它似乎会影响符合以下条件的服务器:
- 从使用 HTTP 级压缩的服务器提供服务
- 在 HTTP 响应主体中反射(reflect)用户输入
- 在 HTTP 响应主体中反射(reflect)一个 secret (例如 CSRF token )
似乎缓解措施的有效性顺序是:
- 禁用 HTTP 压缩
- 将 secret 与用户输入分开
- 根据请求随机分配 secret
- 隐藏 secret (通过 XORing 与每个请求的随机 secret 有效地随机化)
- 使用 CSRF 保护易受攻击的页面
- 长度隐藏(通过向响应添加随机字节数)
- 限制请求的速率
在我的页面 View 中，我正在调用辅助方法 @Html.AntiForgeryToken，它会在我访问表单时创建相应的输入和 cookie。通过查看此辅助方法的作用，它似乎在每次加载页面时都创建了一个新的唯一 token ，这似乎符合缓解步骤中的第 3 点，并且首先使用 CSRF token 的行为符合第 5 点.
禁用 HTTP 压缩似乎被广泛认为“不利于性能”，从我阅读的其他一些资源来看，长度隐藏可能会导致文件上传(此页面使用)等功能出现问题
所以，毕竟，我现在唯一真正能看的就是将 secret 与用户输入分开。我考虑过可能会尝试将 CSRF token 值放入 session 中......或者我是否完全过度思考了这一点，并且“@Html.AntiForgeryToken”的当前实现是否足以保护我们？
最佳答案
Anti-Forgery/CSRF Token 还不够吗？在 MVC 中，您可以使用 Html.AntiForgeryToken()。我之前在我的 MVC 应用程序中使用过它，它确实减轻了违规行为。
关于c# - MVC 5 - 缓解 BREACH 漏洞，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/30331105/