3

I recently noticed that the assets sent to clients aren't gzipped or minified on either my companies intranet or its public facing website.

I brought this to the attention of the networking department (who maintain the server) and asked if they could add the appropriate code to the server config.

My co-worker initially saw no problem and thought it was a good idea, but today he said that after he inquired further, he found out that it was a security concern and that's why they don't do it.

This baffles me.

I asked how it could possibly be a security concern if we compress the assets sitting on our server prior to sending them to the client.

He told me that it made it easier for hacked content to slip through the clients antivirus scanner. We use HTTPS though, so there's no way our code could be tampered with on the way to the client's browser without their browser noticing, right?

Further more, even if we did send the assets in plain text, if they get intercepted, the hacker could just gzip them himself and send that, so I'm really confused now.

Are there any legitimate reasons NOT to gzip/minify content sent to client's computers?

EDIT: The content is static, essentially just a marketing website for the company

Luke
  • 187
  • 5
  • minification is not compression - it's still plaintext. Are you sure you want to combine both in your question? – schroeder Dec 22 '15 at 23:17
  • 2
    If the compression is done actively and includes compression of secrets (e.g., session cookies) there can be active attacks to steal those secrets, for example [CRIME](https://en.wikipedia.org/wiki/CRIME) (where you guess parts of the secret and look for reduction in the compressed content when the guess is correct). That said in serving static resources (with no secret tokens included), there isn't a legitimate reason to not compress the static resource. – dr jimbob Dec 22 '15 at 23:22
  • 2
    I seriously challenge this statement: "slip through the clients antivirus scanner" - it might slip through a http proxy doing inspection on the perimeter, but the end client antivirus?? – schroeder Dec 22 '15 at 23:28

3 Answers3

6

I've been pondering this and I don't think your networking department is justified in this opinion. It does all depend on your threat model, but given the threat model of "hacked content to slip through the clients antivirus scanner", this opinion makes no sense.

First, let's drop minification, because it's in plain text. There is no security reason or threat model that could be addressed by not minifying.

Now, let's look at the "hacked content". Because you are using HTTPS, the malicious content has to come from your server, and not a MitM. This excludes hacked ad networks or 3rd party content, because that's being served from elsewhere. This opinion also suggests that this threat (hacked content being served from your own servers) is credible enough to not gain the operational benefits of compressing the content. I doubt this is actually the case.

The other issue here is the concern for the end client. Besides being an odd concern for a web service, antivirus scanners on the client can still scan the content once it is uncompressed. Even a perimeter scanner will decompress content in order to scan it.

In addition to all this, you're right about having no control over the hacked content anyway. The hacker can choose to compress or not if they have access to your servers (which would be required in this threat model), so choosing not to compress static content is not justified.

In the end, it sounds like there is more to the story, the architecture, and odd decision than meets the eye.

schroeder
  • 123,438
  • 55
  • 284
  • 319
1

This should not be a security concern on which you spend energy.

Maybe your client doesn't have any anti-virus. Maybe they have bad anti-virus. If their system is vulnerable to attack by a website they visit, then that's their problem, not yours. Slowing down clients by not compressing content on the off-chance that their anti-virus software is good enough to catch an attack, unless it's zipped, is a strange tradeoff to make.

Adam Shostack
  • 2,659
  • 1
  • 10
  • 12
0

Your network people may be thinking of CRIME, BREACH, or other attacks that exploit the size of compressed data that changes when the attacker makes a correct guess about a byte of a header or a cookie. By prohibiting compression over encrypted channels, they may hope to thwart such exploits.

John Deters
  • 33,650
  • 3
  • 57
  • 110
  • yeah - I thought about CRIME and BREACH, too. But that's a little old to be worried about now, and it doesn't match the stated (and relayed) reasons by the network folks. It's also an odd thing to be worried about as the web server. It's more of an issue on the client end. – schroeder Dec 23 '15 at 00:03
  • @schroeder, exploiting BREACH is still possible today; and we are only hearing third-hand some of the excuses being provided by someone in their network area. It's also possible they have a more senior person behind the scenes saying "our apps are such that BREACH could make our clients' data vulnerable to attack." But yeah, we have no way of knowing what's really behind the prohibition. The only real answer is for him to directly ask his network people to clarify the precise risks they're trying to mitigate. – John Deters Dec 23 '15 at 00:15
  • 1
    I hear you (by "relayed" I meant we are getting the info 3rd hand), but it's a marketing website. There appears to be no risk to the client's data because the site does not host client data. – schroeder Dec 23 '15 at 00:25