Include defenses against BREACH and other TLS attacks in Drupal core

http://drupal.og/project/cacheable_csrf does #2 to an extent. The token isn't included in the HTML markup, but is injected via JavaScript based on the value of a cookie. So there's no reflection which a quick read of that doc suggests is what this attack relies on. Obviously the cookie is there, and the server still has to set it when it's not available.

Here are the possible resolutions as I see it. Since I somehow managed to reach opposite conclusions from the current issue summary, I'll leave this chart in a comment until we are closer to consensus.

countermeasure	feasibility	effectiveness	notes
Disabling HTTP compression	high	high	Easy, and effective. It's unfortunate to give up the bandwidth savings, but it's been known since at least 2002 that encryption and compression don't mix well. Drupal core does not gzip authenticated pages anyway, so we could almost mark this "works as designed". We may be able to prevent downstream intermediaries from gzipping by using the Cache-control: no-transform header. Honoring no-transform is a MUST in the HTTP RFC, but it's real-world effectiveness needs more research. Sadly, the first program checked (Apache httpd/mod_deflate) fails.
Separating secrets from user input	no	n/a	Core cannot know, in advance, what data is secret. There are a few universal secrets like e-mail address and CSRF tokens, but in principle any part of the HTML document may contain confidential information. As a result, the solution most protect the entire HTTP body.
Randomizing secrets per request	no	n/a	same as "separating secrets"
Masking secrets (effectively randomizing by XORing with a random secret per request)	no	n/a	same as "separating secrets"
Protecting vulnerable pages with CSRF	no	n/a	Even simple GET requests would require CSRF protection. This suggestion from breachattack.com is not the same as protecting forms and actions from CSRF. The requirement for this solution to be viable is to prevent all forged requests that reflect user input. Simple example: HTTP GET https://victim.com/user/1/edit?chosen-plaintext=aaaa@gmail.com Repeated requests to this URL (forged via <img> tag on 3rd-party site) would result in the attacker stealing the admin's e-mail address. Clearly we cannot require CSRF tokens on simple GET requests as this would break basic hyperlinking on a the web.
Length hiding (by adding random number of bytes to the responses)	high	low	Can delay, but not prevent an attack, because even random padding will reveal a statistical bias.
Rate-limiting the requests	low	low	hard to choose a limit high "enough for anybody", yet low enough to be effective. Proxies and CDNs can cause false positives. Fundamentally a task better suited for WAFs.

Attached is a patch for the first option with no-transform.

Both I guess - not useful because CSRF tokens are only a small fraction of the secrets that need protecting. UID 1's e-mail is one example above, another example would be private user profile fields. On top of that prior to #1798296: Integrate CSRF link token directly into routing system we don't even have a central way to protect CSRF tokens. Discussing tokens is a good way to illustrate the BREACH vulnerability (they are nearly universal to all web apps, and secondly it's a very high-value secret).

Also wrong, in the sense that if the transport security is broken, then a fix must address it at that layer, rather than accepting broken transport encryption and masking a single high-value secret.

I admit the no-transform header idea may turn out to be weak, if it's not well-supported by CDNs and load balancers in the wild (this still needs research). Another layer we could add would be a status report check in hook_requirements(), or https://drupal.org/project/security_review (the check would generate a warning if an intermediary was detected gzipping SSL pages).

Compression is a a kind of encoding, yes? (Compressed responses are labeled with Content-Encoding: gzip) And I think the RFC is pretty clear that no-transform prohibits changes to the body, and the Content-Encoding header:

Therefore, if a message includes the no-transform directive, an
intermediate cache or proxy MUST NOT change those headers that are
listed in section 13.5.2 as being subject to the no-transform
directive. This implies that the cache or proxy MUST NOT change
any aspect of the entity-body that is specified by these headers,
including the value of the entity-body itself.

For length-hiding, I'm inclined to agree that the cost / benefit ratio is pretty good. My stats are terribly rusty, so take this with a grain of salt, but here's a estimate of sample size needed given 0-128 of padding bytes, and a 10-byte secret:

n = 2 ((sigma erf^(-1)(c))/M)^2 | sigma = (standard deviation UniformDistribution[{0, 128}]), c = 0.5**(1/10), M = 0.5

18,327 samples are predicted per length observation, assuming 32 observations per byte, and 10 bytes in the secret means almost 6 million observations needed to "breach" the secret. Depending on how fast your Drupal backend is, this could take days or weeks (and proportionally more for longer secrets). This isn't a crypto-scale amount of time, but better than nothing, especially considering the victim needs to have a malicious site open for the duration.

Can padding be confined to the header? Padding an HTML body is pretty safe, but not so with all media types (XML, JSON, etc). I would expect an attacker can only see the overall message size, and not the boundary between header and body, but I'm not sure.

Last, we can document on https://drupal.org/https-information that site operators who want the strongest protection from BREACH should refrain from enabling gzip on SSL pages.

This looks like something we could add to 8.0.1 - is there a particular reason it should block the release?

I agree it should not be a release blocker.

pwolanin: "pushes to move all traffic to https" - to me, this is an argument in favor of disabling compression; as TLS becomes more widely used, it becomes even more important to have strong assurances of it's safety.
Interestingly EFF mentions CRIME, but not BREACH: https://www.eff.org/https-everywhere/deploying-https

Anyway, I would be happy to review a length-hiding patch. To the best of my knowledge, TLS operates 3 layers below HTTP, so it's not even aware of the header / body boundary, which is why I think header padding would have the intended effect, with a lower risk of side-effects.

I think it's OK to rely on \Drupal::request()->isSecure(), proxy users still have to configure this accurately (via X-Forwarded-Proto or otherwise). If this isn't set, the session handler won't function correctly anyway.

We do have modules like https://www.drupal.org/project/prepopulate that allow filling the value attribute. Even without a way to force a value attribute, at that point you're relying on a single quote mark, and the attacker's inability to guess the first three characters of whatever data is being attacked, which seems pretty flimsy. (Lots of private data have predictable prefixes, for example: Social Security Number Prefixes, Area codes, Health insurance account numbers, etc.

I also think focusing on the form tokens is a way to narrow view. In principle any private data on the page could be attacked. (For another example, see my comment in #7 -- the admin's email address could be leaked with e.g. https://victim.com/user/1/edit?chosen-plaintext=aaaa@gmail.com).

Below is a screenshot from a real Drupal site, showing how a little OSINT could be combined with BREACH to steal health insurance information.

Because Drupal core cannot anticipate the nature of the data present on a page, the only effective solution I can see is to disable compression for non-cached/non-public pages over HTTPS. (Which was already the case in core last I checked, though we might be able to take steps to prevent proxies & CDNs from adding compression, or possibly a system status warning if compression is detected).

Hi,

Any thoughts about the same BREACH vulnerability with theme_token on D7?
Disabling HTTP compression will be a performance hit, so this isn't the best solution IMHO.

We ended up removing (unset) theme_token from our default theme, since we have no AJAX requests
with Drupal AJAX APIs.
That token seems a little bit odd to me, why not just checking a permission to the administrative theme / add per theme permission and check that permission instead? Weird solution, isn't it?

Ivan Ristić's book suggests another possible mitigation that I don't think has been considered: conditionally disable compression when the request doesn't have a same-origin Referer. It's similar to the CSRF token idea mentioned in #7, but without the tokens - and the only penalty for not sending a Referer at all is that you get an uncompressed response.

The solution indicated in #33 is also suggested and detailed on https://wiki.crashtest-security.com/prevent-ssl-breach

The attached patch returns a Cache-Control: no-transform header if the request uses HTTPS and does not have a trusted Referer header.

We are using Varnish and this feels like the best compromise between security and performances.

The Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.