1

Suppose, a user can click a button on a website and downloads a file with a secret. Via ajax. Is it more secure if a server generates that file and sends it as

1) zip, tar or the like -- a binary file. Content type: application/octet-stream or application/zip or something similar.

2) or as a plain text file? Content type: text/plain.

Note that in the 1) case, zip/tar whatever isn't protected by a password.

HTTPS is used in both cases.

Incerteza
  • 2,177
  • 3
  • 15
  • 22

6 Answers6

29

There isn't really a difference.

If you use proper TLS encryption, neither can be read by a man in the middle, and if the server properly authenticates requests, nobody who is not allowed to will be able to download the file.

If you don't use proper TLS or do not properly authenticate users, an attacker could read the file in both cases.

You definitely should not use non-password protected zipping as a security measure.

tim
  • 29,018
  • 7
  • 95
  • 119
  • I agree that zipping alone should not be considered a "security measure" by any means, however, zip files can be password protected in and of themselves. Even if the file is intercepted, the attacker would need to know (or crack) that password to extract the contents within. – Steve-O May 26 '17 at 20:40
  • 4
    @Steve-O true, but the OP specifically asked about non-password protected files (I added it to the answer). But even with password-protection, I wouldn't recommend zip files in this case. If TLS is not used, a mitm could read session cookies/credentials, authenticate with the application themselves, and read the file that way. Apart from that, [password protected zips](https://security.stackexchange.com/questions/35818/are-password-protected-zip-files-secure) have other disadvantages compared to TLS. – tim May 26 '17 at 20:57
  • what if a zip file is password-protected and the password is emailed to a user? – Incerteza May 27 '17 at 04:50
  • @アレックス It's difficult to answer in a comment (you could ask a new question about this), but I wouldn't recommend it (see eg the link in my previous comment). – tim May 27 '17 at 07:03
  • your coment is about a password-protected zip vs TLS. But I didn't say that it was either or. I meant tls and a password-protected zip – Incerteza May 27 '17 at 11:45
  • @アレックス That would also be a new question. But I would say that it only provides marginally more security. If the browser caches HTTPS replies (which would be a misconfiguration for sensitive pages), password-protected zips could mitigate an attack where an attacker with local access can read the response that contains the file from the browser cache. In the same manner, once the file is saved on the users HDD, a password might protect against an attacker with local access (but that's less of a question of deliver method, but of local encryption). – tim May 27 '17 at 12:08
  • each time a password is new. – Incerteza May 27 '17 at 14:17
12

No,

If the type of file is specified then there is no added security at all. For example, unzipping a file is so trivial that it doesn't add any security.

If you ask whether it's more secure to share a secret via a file with an unknown type then this is just security by obscurity. Sure security by obscurity discourage some people but it's still not secure.

Gudradain
  • 6,921
  • 2
  • 26
  • 43
9

The file format is irrelevant to the security of the data transport. You can send plain text as well as arbitrary binary formats securely through an encrypted TLS tunnel. Without transport security, the data can be captured either way and would only be protected by encryption in the format itself.

With regard to security on the application layer, zipping sensitive data has historically been a popular measure against a class of web application attacks related to content sniffing. E.g., depending on the format of the secret data and the predictability of the download path, you might introduce a cross-site script inclusion (XSSI, not XSS) vulnerability by offering plain text downloads without appropriate security measures. Here's an imaginary scenario to explain the attack:

Let's assume any authenticated user on your platform can download a user-specific sensitive configuration file from this URL:

https://yourservice.example/download/myconfig

The config file has the following format:

user_id = 314159
secret_token = "719fe66f5159f86e798eabf930b8c9c2"

Now an attacker could simply send you a link to a prepared website with the following content:

<script src="https://magicservice.example/download/myconfig"></script>
<script>
    alert(secret_token);
</script>

What happens here is that your browser interprets the response from the download link as external JS code and thereby leaks the values of user_id and secret_token to the embedding attacker-controlled page as global JS variables. Zipping or reformatting the data in some way would have prevented this attack because a ZIP file cannot produce valid JS code. While this specific case might appear far-fetched, there have been many other sniffing-related vulnerabilities in the past.

Note that the correct and modern way to mitigate this XSSI scenario is not zipping the file but sending an X-Content-Type-Options: nosniff header that forces browsers to only accept JS with a correct MIME type, and sending a Content-Disposition: attachment header that instructs browsers to not display the download inline.

Arminius
  • 43,922
  • 13
  • 140
  • 136
  • 2
    Worth noting that although you _can_ solve this attack vector by using ZIP files, the _better_, more correct way is to send the appropriate MIME type with your responses. (i.e. *not* `text/javascript`) and send the `X-Content-Type-Options: nosniff` header. – Ajedi32 May 26 '17 at 18:13
  • @Ajedi32 Thanks, I was more concerned about demonstrating the concept than showing what the correct countermeasures are. I added that. – Arminius May 26 '17 at 18:34
  • 3
    As the OP specified that a file will be downloaded (not displayed), I would assume that the content-disposition header is set, so this attack should not work. This seems to be more of an accidental defense for poorly written applications, but your point is still valid. – tim May 26 '17 at 18:46
  • @tim I might have been a little too excited to make that point because I thought that was actually where OP was coming from - as opposed to the far-fetched "does this protect me against a MITM?" point. Also, I can still imagine that attacks related to data leakage via "accidental" polyglots are somewhat relevant and not fully mitigated through the `nosniff` directive, e.g. when they involve badly written plugins. – Arminius May 26 '17 at 19:00
3

It does not matter if it is over HTTPS. You can read binary file as easy as text file.

Fis
  • 1,200
  • 7
  • 10
  • You mean: "It does only matter if it is over HTTPS."? – rugk May 28 '17 at 13:40
  • If you transfer the data over HTTPS - what is actually using TLS in version at least 1.2 - everything else (lower) id hazardous, it is not (or it is very hardly) possible to capture the data traversing the network as it is encrypted. And it really does not matter if you transfer binary or text file. What I want to say is, you don't need additional encryption layer as the data is encrypted once. Of course, in some cases you might need to encrypt them. For example, it is good practice to encrypt the data you store on some kind of cloud drive as the owner of the store can't read it. – Fis May 28 '17 at 16:07
  • 1
    You're completely right, but what you said in your very short answer is "(Using) HTTPS does not matter", which is the contrary of what you seem to mean. – rugk May 29 '17 at 16:59
2

Yes, but not by enough to be worth worrying about except in the most security-conscious settings.

Text is big, bulky, and consists of a generally known, limited character set, whereas a compressed binary format like zip is compact and tries to use the full range of possible values for its bytes so as to need the smallest possible number of bytes to represent the content. It also will generally remove at least the most significant cyclic patterns.

All this makes cracking the transport layer encryption you are hopefully using to secure the download more difficult. (Hence why programs like GPG by default compress messages before encrypting them.) But then, if you've got your TLS set up correctly, cracking it should already be so difficult that you don't have to worry about anyone other than major governments, and even they would have a hard enough time of it that they'd be likely to just show up at your house and beat you until you gave them the file.

If you're not using TLS, then it makes no difference unless you manage to pick a binary format so arcane that the adversary is incapable of identifying it... In which case your user probably won't be able to either... So you might as well just give them len($FILE ) bytes from /dev/urandom to download and then burn the actual file to disk and send it to them in the post.

Perkins
  • 199
  • 4
  • Just to note, it seems the question is related to web (or downloading a file from server over web). Hopefully, everybody is using gzip for web servers these days. If so, I can't see any reason to use another compression method such as rar or zip on files. Regarding "making it more difficult"... In my opinion, text is totally the same as binary. If I have text in ASCII its binary representation will be totally the same as in binary. If I pack it to ZIP and I will transfer this zip million times over the network the pattern will be always the same as well. I can't see any reason to pack the file – Fis May 28 '17 at 09:37
  • @Fis The encryption keys are regenerated for every new connection, so a million transfers of a smaller, zipped file will still be harder to crack than a million transfers of the uncompressed version. Also, gzip transfer encoding seems to be implemented a lot less frequently than one might hope... Getting to be more common though. – Perkins May 28 '17 at 19:56
0

This actually depends a bit. Obviously as everyone pointed out the encoding as such doesn't prevent any extra challenge for an attacker, but there is something else to consider.

There is couple of things you usually can't manage to protect when transferring encrypted data, source and destination is one, length is another. It turns out that length is a surprisingly powerful side channel, check out https://www.youtube.com/watch?v=skQNwd9Jij4 for an example of traffic analysis of google maps.

The point I am trying to make is that in some rare cases the encoding can have an effect on the security of the whole system. This is especially the case when there is a small number of acceptable transmitted states. If you only get to choose between "No I don't want the job offer." and "Yes please send the contracts along.(contract appended)" then you will need padding for the no answer to make the information look the same.

This is just a specific version of the low entropy in data problem you sometimes see in hashing of identifiers and similar. If there are only a couple of million acceptable inputs then the hash of them will be easily invertible.

DRF
  • 384
  • 3
  • 7
  • But what does padding have to do with "binary vs text files"? Also I'd say that low entropy allowing brute-force attacks on a hash function has nothing to do with padding or these site-channel attacks as checking some meta data (i.e. "How big is the request?"). – rugk May 28 '17 at 13:44
  • @rugk Quite a bit. The way files are presented has essential effects on whether side-channel attacks are feasible. The reason you can do traffic analysis on google maps is an artifact of using vector maps for efficient compression. If the maps were presented as bitmaps this would become almost impossible to do since the size would be uniform. The same maybe true for other file formats. – DRF May 29 '17 at 05:22