4

I am in charge of the applicative security of our application and would like to test our exposure to the BREACH attack.

Our django-based web application reflects filtered user-input and serves a CSRF token.

The way I understand it, BREACH exploits the HTTP compression algorithm of the response body (so our session cookie would be safe in the HTTP header) to find other instances of a particular user-input string.

But what if canary="somethingsomething" becomes canary="somethingsomething&quot as user-input? Is the canary part so relevant to the "guessability" of somethingsomething? My guess this removes the canary for automatic detection, but if the rest of the page stays the same, somethingsomething would still be vulnerable, but more difficult to identify, especially if there is more than one token in the page...

Maxime Leblanc
  • 41
  • 2

1 Answers1

1

If the user input is reflected verbatim with each request, your method probably does not protect against BREACH.

The most certain way to defend django is to turn off Gzip compression.

Alternately, you can XOR the token with a different pseudo-random value for each request.

Foo Bar
  • 367
  • 2
  • 11
  • 1
    Note that the xor must be done on all unchanging secrets passed over tls, not just the csrf token. BREACH focused on the csrf token because it's an easy thing that every web app has, not because it's the only secret that can be attacked. – atk Jul 11 '16 at 02:38