Gzip plug and plug contrib

News Announcing
, , ,
7

I think we’re safe from BREACH after all and can use gzip + https.

Essentially, I think the vulnerability is this:

  • Assume an attacker can make their victim make requests to our site. The
    attacker cannot see inside the HTTPS responses, but can see their
    length.
  • The attacker makes the victim make repeated requests to an endpoint that
    returns both an unchanging secret value (like an API token) and a
    value that the attacker can change (eg, a search term that gets echoed
    in the response).
  • The attacker keeps tweaking the search term in successive requests.
    Because gzip works by de-duplication, the closer the attacker gets to
    guessing the API token, the smaller the response gets. Eventually, they
    can guess it exactly, and can then impersonate their victim to
    our site.

I think we’re safe because:

  • We don’t have any endpoints which return both and API token and
    some value sent in the request.
  • In any case, we never send the same API token twice because the value
    we send is timestamped and signed; we use Phoenix.Token.sign/3. This
    should make guesing the value as describe above impossible.

If anybody knows otherwise, please chime in. I’ve also asked about it on the Information Security Stackexchange.

1 Like