CODEWITHSUNDEEP
asp.netsecuritybreach-attack
user3068724
user3068724

Reputation: 15

.ASPX POST Request - Privacy Violation: BREACH

Based on Web Inspection Report our site falls under Privacy Violation: BREACH. The recommend fix are :

  1. Disable HTTP compression

  2. Ensure that user input and secret is not contained within the same response content

  3. Randomize the secret

We applied #1 Disable HTTP compression from IIS => Compression => unchecked both Static and Dynamic. Which does work on our DEV but when we tried in PRODUCTION server, which DO NOT worked. *Response header still shows content-encoding: gzip. Even though HTTP compression is turn OFF

Below is sample response header from PROD server.

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

Also, How to apply fix from 2 and 3. The report shows issue with :

TSM_HiddenField_=ctl00_ContentPlaceHolder1_ToolkitScriptManager1_HiddenField&_TSM_CombinedScripts_=%3b% 3bAjaxControlToolkit%2c+Version%3d3.5.7.123%2c+Culture%3dneutral%2c+PublicKeyToken And

ctl00_ContentPlaceHolder1_ToolkitScriptManager1_HiddenField=&__EVENTTARGET=&__EVENTARGUMENT=&__LASTFOCUS =PRexdxaxbhgeccgjdchdfcgcdefRP ( which was modified in response body)

Upvotes: 0

Views: 984

Answers (1)

Jonathan
Jonathan

Reputation: 5864

You can read all about the BREACH attack here: http://breachattack.com/

They talk through mitigation and what kind of compression is affected.

Their list of mitigations in order of effectiveness are:

  1. Disabling HTTP compression
  2. Separating secrets from user input
  3. Randomizing secrets per request
  4. Masking secrets (effectively randomizing by XORing with a random secret per request)
  5. Protecting vulnerable pages with CSRF Length hiding (by adding random number of bytes to the responses)
  6. Rate-limiting the requests

The attack depends on messing with the compression, so disabling that effectively mitigates against the attack.

Explanation of how to disable compression for asp.net: (disable it in IIS).

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

If you still have compression, IIS might not be configured right. Try opening the page from the IIS server, and check the headers. If compression isn't on at that point, maybe another proxy or load balancer is adding compression back in at another hop.

If you can't get the compression off in your environment, the next step is separating secrets from user input.

Looking at the line they pulled out, it doesn't actually look like a secret to me. If it's not a secret (ie, if an attacker found the value, they wouldn't be able to use it), then you aren't actually subject to the breach attack.

Upvotes: 0

Related Questions