15

I'm hoping someone will be able to help my understanding of this issue and whether or not I need to take any extra steps to protect my application.

Reading up on this particular vulnerability, it seems to impact servers that match the following criteria:

  • Be served from a server that uses HTTP-level compression
  • Reflect user-input in HTTP response bodies
  • Reflect a secret (such as a CSRF token) in HTTP response bodies

It also seems that mitigation steps, in order of effectiveness are:

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

In the view of my page, I'm calling the helper method @Html.AntiForgeryToken which creates the corresponding input and cookie when I visit the form. From looking over what this helper method does, it seems to create a new, unique token each time the page is loaded, which seems to meet point 3 in the mitigation steps and the act of using a CSRF token in the first place meets point 5.

Disabling HTTP compression seems to be widely regarded as 'not good for performance' and from some other resources I've been reading, length hiding could possibly cause issues for functionality like file upload (which this page uses)

So, after all that, the only thing that I can really thing to look at now is separating secrets from user input. I thought about maybe trying to put the CSRF token value into the session.....or am I completely over-thinking this and is the current implementation of '@Html.AntiForgeryToken` good enough to protect us?

Jak Hammond
  • 1,460
  • 3
  • 11
  • 24
  • Disable HTTP compression for dynamic pages and decide whether it impacts performance for you. (It probably won’t.) – Ry- May 19 '15 at 16:25
  • @minitech The current IIS server I'm hosting this app on, doesn't even have the dynamic content module installed – Jak Hammond May 19 '15 at 16:30
  • I don’t know what that is. “Dynamic pages” refers to “things that are not static resources” in that comment. – Ry- May 19 '15 at 16:31
  • I have this exact same issue, would love to find any answer to this. The AntiForgeryToken() helper does indeed sound like it should be changing the response every time, which I thought is supposed to fix the issue. Also, it's happening on a page that doesn't even have a secret like a password; on a page that has nothing but a plaintext user input field. – GendoIkari Mar 21 '18 at 13:50
  • I don't understand what you want to do really. what's your final purpose (e.g whats the main problem?) – Amirhossein Mehrvarzi Mar 22 '18 at 08:39
  • Can't speak for the OP, but in our case, a security scanner is flagging the website as being vulnerable to BREACH; I want to remove this vulnerability. – GendoIkari Mar 22 '18 at 19:04
  • @GendoIkari maybe you should post another question with details (of this specific page scanner thinks is vulnerable) and add a link to this question here. Maybe it's just false positive and you don't need to do anything. – Evk Mar 23 '18 at 05:50
  • "(...) put the CSRF token value into the session", just a general comment on this particular thought - don't. read up just a little bit on the attack itself, and you will hopefully realize that putting it anywhere not in your form will completely defeat it's purpose. – Tewr Mar 27 '18 at 12:50

2 Answers2

1

Isn't Anti-Forgery/CSRF Token enough for this? IN MVC you can use Html.AntiForgeryToken(). I used it before on my MVC applications and it does mitigate the breach.

asteriskdothmg
  • 86
  • 6
0

Yes if the CSRF token is random, then it mitigates the attack. As long as you aren't sending any other secrets with user input forms you should be okay.

Alternatively,

Disable compression for on pages that have user input is a possibility as well. Checkout this answer Can gzip compression be selectively disabled in ASP.NET/IIS 7?

jbtule
  • 31,383
  • 12
  • 95
  • 128