Contrib.social

Include defenses against BREACH and other TLS attacks in Drupal core

Open on Drupal.org →
Created on 5 April 2014, about 11 years ago
Updated 30 January 2023, about 2 years ago

Updated: Comment #N

Problem/Motivation

Moving this into a public issue form the security team tracker, since the attack is a general one on web servers, and not specific to Drupal, and the information is already public.

Django made a security announcement regarding the BREACH attack:
https://www.djangoproject.com/weblog/2013/aug/06/breach-and-django/
Their approach of suggesting you turn off gzip/deflate seems infeasible for most people.

There's more information here: http://breachattack.com/

Drupal is less vulnerable than many web applications, since the CSRF token is usually different per form.

However, if a sensitive or administrative form is on the same page with a form without CSRF protection (e.g. a search form that takes values from the query string), it's possible to be vulnerable to this attack. You could also be vulnerable if there is other sensitive data on a page that includes such a form.

Also, this attack is more effective against a stream cipher like rc4, which many people witched to using due to the BEAST attack.

Proposed resolution

Possible suggested BREACH mitigations:

  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
  6. Length hiding (by adding random number of bytes to the responses)
  7. Rate-limiting the requests

#1, #2, and #3 don't seem very feasible.

#4 could be pretty trivially implemented by essentially splitting the form token into 2 parts - a secret that's constant (essentially what we send as the token today), and a XOR mask that varies on every request. The the valid token check would XOR the 2 parts and compare to the expected secret.

#5 We already protect most forms and actions against CSRF, so Drupal start out from a relatively strong position against this attack already.

#6 should be easy to implement as well:
At least for BREACH and possibly for the vulnerabilities described at http://www.isg.rhul.ac.uk/tls/ for rc4, a possible counter-measure would be injecting a random number of random bytes as a header, and also injecting a random number of random bytes into the HTML content (e.g. in the HEAD section)

#7 seems more suitable to a WAF or load balancer outside Drupal.

Remaining tasks

pick 1 or more aproaches and implement

User interface changes

N/A

API changes

Possible changes to token generation/checking, but these could be transparent at the API level

📌 Task
Status

Needs work

Version

10.1 ✨

Component
Base  →

Last updated about 20 hours ago

Created by

🇺🇸United States pwolanin

Live updates comments and jobs are added and updated live.
  • Security

    It is used for security vulnerabilities which do not need a security advisory. For example, security issues in projects which do not have security advisory coverage, or forward-porting a change already disclosed in a security advisory. See Drupal’s security advisory policy for details. Be careful publicly disclosing security vulnerabilities! Use the “Report a security vulnerability” link in the project page’s sidebar. See how to report a security issue for details.

  • Needs backport to D7

    After being applied to the 8.x branch, it should be considered for backport to the 7.x branch. Note: This tag should generally remain even after the backport has been written, approved, and committed.

  • Needs backport to D6

    After being applied to the 7.x branch, it should be considered for backport to the 6.x branch. Note: This tag should generally remain even after the backport has been written, approved, and committed.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment about 2 years ago →
    needs-review-queue-bot

    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.

  • Comment 15 days ago →
    🇫🇷France prudloff Lille

    If I understand how this attack works correctly, I think setting SameSite=Lax or Strict on cookies mitigates BREACH attacks.
    I could not find a lot of information about this but it is mentioned here: https://www.sjoerdlangkemper.nl/2016/11/07/current-state-of-breach-attack/
    Since 📌 Set SameSite on session cookies Fixed , Drupal now uses SameSite=Lax by default so we might not need a specific protection against BREACH anymore.

    Also FWIW, here is what we implemented on our servers: we don't compress responses that have Cache-Control: private.
    The reasoning is that:

    • A response that contains sensitive data should already have Cache-Control: private (because we don't want our reverse proxy to cache it).
    • This basically only disables compression for logged-in users or some very specific uncacheable pages which is an acceptable tradeoff for us.

    But it would not be a good universal solution, for example if most of your users are logged-in.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024