7

I am looking to enable text compression in Django. The performance docs reference GZip Middleware as the current solution for text compression. However, it comes with a stern warning:

GZipMiddleware

Compresses responses for all modern browsers, saving bandwidth and transfer time. Note that GZipMiddleware is currently considered a security risk, and is vulnerable to attacks that nullify the protection provided by TLS/SSL. See the warning in GZipMiddleware for more information.

A couple of questions:

  • Are there any text compression alternatives I can use with Django that are not subject to security risks?
  • If I use CSRF tokens when using POST and I have CSRF Middleware enabled am I safe?

Again, via the docs:

Changed in Django 1.10: In older versions, Django’s CSRF protection mechanism was vulnerable to BREACH attacks when compression was used. This is no longer the case, but you should still take care not to compromise your own secrets this way.

Community
  • 1
  • 1
Scott Skiles
  • 3,647
  • 6
  • 40
  • 64

1 Answers1

12

I definitely suggest looking at the BREACH paper, which is short and quite clear.

As noted there:

In order for the attack to be successful, several things are required. To be vulnerable to this side-channel, a web app must:

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

So, if you aren't reflecting user information and secrets in the response body, you aren't vulnerable.

If you are, it's unlikely that any text compression scheme will work. The attack takes advantage of the fundamental nature of text compression: that repeated text should take up less space. It's possible that there is a compression scheme that wouldn't be vulnerable, but you would definitely need to see some assurance of that.

Because this attack is based on specific application features, rather than being a framework vulnerability, it's not possible for Django to to ensure that applications are "safe". What Django can do is protect the primary secret that is vulnerable to BREACH that it supplies support for: the CSRF token. Since version 1.10, Django has used one of the mitigations suggested in the paper (see section 3.4) to protect it from this attack:

In order to protect against BREACH attacks, the token is not simply the secret; a random salt is prepended to the secret and used to scramble it.

To summarize: if the only secret you need to protect is Django's CSRF token, and you're using Django 1.10 or greater, it's reasonable to conclude that you can use gzip and still be safe from BREACH.

Kevin Christopher Henry
  • 46,175
  • 7
  • 116
  • 102