1

I have a Single Page Application (SPA) that consists of static resources (HTML, JS, CSS, images fonts ...) that are served from an Apache web server and several API endpoints (serving JSON from a JBoss Backend, proxied through the same Apache that serves the static resources).

Client browsers have access to the SPA only via HTTPS.

Sensitive data is served exclusively from the API endpoints.

I would like to enable gzip compression for all the static resources. gzip compression will not be enabled on the API endpoints.

Is enabling gzip compression on the static resources a security risk because of the BREACH security exploit?

I do not fully understand the BREACH attack:

  • My static resources (which would be compressed) do not reflect any user data
  • The API calls do reflect user data and can contain query parameters, but they are not compressed.

Is the above scenario vulnerable to the BREACH attack or not?

  • Is the SPA authenticated? BREACH affects session cookies as well as page data. – Polynomial Jan 3 '17 at 11:47
  • @Polynomial What is the criteria for the SPA "being authenticated" (forgive my ignorance). The SPA is loaded via static resources. Then the user authenticates with a dedicated API call, which returns a token. The token is only used on subsequent API calls, not on reloading the static resources... – jbandi Jan 3 '17 at 11:58
  • 2
    no, you're not compressing dynamic html, so you are immune. – dandavis Jan 3 '17 at 12:12
  • 2
    @jbandi If no secret information is passed over the compressed channel, in requests or responses, body or headers, then you should not have any problems with BREACH. – Polynomial Jan 3 '17 at 12:36
  • 1
    @jbandi Compressed static resources are fine as long as you're not sending things like session cookies as part of the requests for them - my advice would be to keep them on a secondary domain. – Polynomial Jan 3 '17 at 13:18
2

From your link:

To be vulnerable, a web application must:

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

However, if your resources are static and are the only items compressed then:

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

For your non-compressed dynamic items:

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

Key:

  • Applicable to your situation

  • Not applicable

As no one request satisfies all three requirements, you are not vulnerable to BREACH.

  • The thing that is not completely clear for me is: Must the three points be true for one request, or for the sum of all requests of the application? i.e: Am I vulnerable if I serve static resources with HTTP-level compression and API-Calls/JSON-Data that reflect user-input without HTTP-level compression from the same server? – jbandi Jan 5 '17 at 10:22
  • 1
    The three points must be true for a single request. – SilverlightFox Jan 5 '17 at 10:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.