时间戳

首页 > 解决方案 > .ASPX POST 请求 - 侵犯隐私：BREACH

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

问题描述

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

  1. 禁用 HTTP 压缩

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

  3. 随机化秘密

我们从 IIS 应用 #1 禁用 HTTP 压缩 => 压缩 => 未选中静态和动态。哪个在我们的 DEV 上有效，但是当我们在 PRODUCTION 服务器中尝试时，它不起作用。*响应头仍然显示 c content-encoding: gzip。即使 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（在响应正文中修改）

标签： asp.netsecuritybreach-attack

解决方案

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

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

他们按有效性排序的缓解措施列表是：

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

攻击取决于弄乱压缩，因此禁用它可以有效地减轻攻击。

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

如何防止 ASP.NET MVC Core 中的 BREACH 攻击？

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

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

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

推荐阅读