.ASPX POST 请求 - 侵犯隐私：BREACH

Question

根据网络检查报告，我们的网站属于侵犯隐私权：BREACH。 推荐的修复方法是：

1. 禁用 HTTP 压缩

2. 确保用户输入和密码不包含在相同的响应内容中

3. 随机化秘密

我们从 IIS 应用 #1 禁用 HTTP 压缩 => 压缩 => 未选中静态和动态。这在我们的 DEV 上确实有效，但是当我们在 PRODUCTION 服务器中尝试时，它不起作用。 *响应头仍然显示 content-encoding: gzip。即使 HTTP 压缩已关闭

• 我理解 HTTP 压缩被禁用的方式是检查响应标头并确保没有内容编码。

以下是来自 PROD 服务器的示例响应标头。

Cache-Control   
private
Connection  
Keep-Alive
Content-Encoding    
gzip
Content-Length  
71447
Content-Type    
text/plain; charset=utf-8
Date    
Thu, 24 May 2018 16:57:04 GMT
Server  
Microsoft-IIS/7.5
Strict-Transport-Security   
max-age=31536000; includeSubDomains
Vary    
Accept-Encoding
X-AspNet-Version    
4.0.30319
X-Content-Type-Options  
nosniff
X-Frame-Options 
SAMEORIGIN
X-XSS-Protection    
1; mode=block

--- Request Header

Accept  
*/*
Accept-Encoding 
gzip, deflate, br
Accept-Language 
en-US,en;q=0.5
Cache-Control   
no-cache
Connection  
keep-alive
Content-Length  
92398
Content-Type    
application/x-www-form-urlencoded; charset=utf-8
Cookie  
.ASPXANONYMOUS=fMbt3RErereq1AEkAAA…onId=00y51efaerreuc3pw0erereyehwc2wzxk
Host    
example.org
Pragma  
no-cache
Referer 
https://example.org/dsearch.aspx
User-Agent  
Mozilla/5.0 (Windows NT 6.1; W…) Gecko/20100101 Firefox/60.0
X-MicrosoftAjax 
Delta=true
X-Requested-With    
XMLHttpRequest

另外，如何应用 2 和 3 中的修复。 该报告显示以下问题：

TSM_HiddenField_=ctl00_ContentPlaceHolder1_ToolkitScriptManager1_HiddenField&_TSM_CombinedScripts_=%3b% 3bAjaxControlToolkit%2c+Version%3d3.5.7.123%2c+Culture%3dneutral%2c+PublicKey令牌 和

ctl00_ContentPlaceHolder1_ToolkitScriptManager1_HiddenField=&__EVENTTARGET=&__EVENTARGUMENT=&__LASTFOCUS =PRexdxaxbhgeccgjdchdfcgcdefRP（已在响应正文中修改）

Answer 1

您可以在此处阅读有关 BREACH 攻击的所有信息：http://breachattack.com/

他们讨论缓解措施以及受影响的压缩类型。

他们按效果排列的缓解措施列表是：

1. 禁用 HTTP 压缩
2. 从用户输入中分离秘密
3. 根据请求随机化秘密
4. 屏蔽秘密（有效 通过 XORing 与每个请求的随机密钥进行随机化）
5. 保护 隐藏 CSRF 长度的易受攻击页面（通过添加随机数 字节到响应）
6. 对请求进行速率限制

攻击取决于弄乱压缩，因此禁用可以有效缓解攻击。

如何为 asp.net 禁用压缩的解释：（在 IIS 中禁用它）。

How to prevent BREACH attack in ASP.NET MVC Core?

如果您仍有压缩，则 IIS 可能配置不正确。尝试从 IIS 服务器打开页面，并检查标题。如果此时未启用压缩，则可能是另一个代理或负载平衡器正在另一个跃点重新添加压缩。

如果您无法在您的环境中取消压缩，那么下一步就是将机密与用户输入分开。

看看他们拔出的那条线，对我来说这实际上并不像是秘密。如果它不是秘密（即，如果攻击者发现了该值，他们将无法使用它），那么您实际上不会受到破坏攻击。