Gzip plug and plug contrib

Your Libraries & OS Mentoring Libraries
, ,
1

Hi Guys,
I had to build a Gzip plug for one of my projects as I needed only a subset of pages to be Gzipped (https://hexdocs.pm/plug_contrib/PlugContrib.Gzip.html). I’d love to hear any ideas to add to this plug_contrib package. Rack has a nice list of Middlewares listed at https://github.com/rack/rack-contrib . Many of these are already present in Phoenix/Plug. I’d love to hear ideas on what people would like to have in this project. I’d love for this project to collect non core plugs which web apps may need from time to time :slight_smile:

1 Like
2

Btw, Cowboy also supports gzipping. You only need to pass compress: true to the server configuration (on Phoenix this means under the :http/:https keys in your configuration):

config :my_app, MyApp.Endpoint,
  http: [compress: true, ...],
  https: [compress: true, ...]

The Plug can still be handy in many situations, for example, if you cannot compress all routes, the Plug gives you flexibility where the Cowboy configuration cannot.

3 Likes
3

Thanks, I did come across this. Like you said it compressed all the traffic. Our scenario required compression of just a subset of the routes :slight_smile:

1 Like
4

Note that compression + SSL/TLS can open you to http://breachattack.com/. After some investigation, I think we’ll just do without gzip on our API responses, which are served over HTTPS. :frowning2:

1 Like
5

Plug.CSRFProtection uses a masked token which does not make it vulnerable to breach (although you need to be careful to not introduce something similar).

2 Likes
6

Good to know. Our API users request API tokens (with credentials) and send them back in requests. I’m not sure whether that makes us vulnerable (I don’t thoroughly understand BREACH), so at the moment I’m thinking we won’t use compression.

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