2

It seems to me that it would be pretty useful to be able to indicate an expected crypto hash value in file downloads especially since so many application and data downloads rely on mirrored hosting. This could be done as an attribute to an 'a' tag (I'm not sure if there is a better way). In this scenario the browser would of course check the hash and probably remove the file with a warning if the hash didn't match what was downloaded. As far as I know there is no way to achieve something like this today. Is that correct? If that's true is there a good reason that something like that shouldn't be proposed as an addition to the HTML5 spec. And finally, if it is a reasonable thing to suggest, what is the best way to make such a suggestion?

4
  • I suspect HTTPS / HTTP2 solve this in a more general way. – 9000 Jun 8 '15 at 18:44
  • 1
    Regarding your ancilliary question about "the best way to make such a suggestion", I believe the WHATWG FAQ is the authoritative source on this process. – Ixrec Jun 8 '15 at 19:00
  • 1
    You should look into the BitTorrent protocol, which uses an initial download of cryptographic hashes to then download a file from distributed nodes. Also relevant could be the ETag HTTP header. – cbojar Jun 8 '15 at 19:14
  • This problem can be solved by using a javascript function, served from the same server that the trusted checksum is served from, to verify the integrity of the download from the untrusted server. See meixler-tech.com/aivwd for more info. – mti2935 Feb 24 '20 at 16:35
2

Already proposed and being implemented in most major browsers. It's called:

Sub Resource Integrity

Subresource Integrity (SRI) allows specifying the digest of the file that you want to include. The digest is the output of a cryptographic hash function, which helps us achieve integrity.

A nice overview is available here by one of the co-authors of the spec.

3
  • 1
    This is perfect! Thanks for the pointer. BTW for anyone reading this post qnimate.com/… explains how to use sub resource integrity with an 'a' tag. – Keith Aug 11 '15 at 16:27
  • 1
    argh, this was almost perfect. It looks like support for the anchor tag was initially a part of the spec but was removed, at least for the 1.0 version: github.com/w3c/webappsec/issues/81 . Oh well... – Keith Aug 11 '15 at 16:50
  • Good catch. Didn't realize that anchor tag was removed from spec (for now)! – HRJ Aug 12 '15 at 3:56
0

A feature like this would probably provide little to no actual security benefit, especially when compared to something like SSL or any potential solution to XSS attacks that I'm sure the web standards committees are looking at.

The threat models I can think of where you might try using a hash on a file download are:

1) The website shows a hash and sends you a legitimate file, but someone does a MITM attack and turns the file into malware. If the MITM attacker was competent, they would've also edited the site to show you the correct hash for his malware (or perhaps no hash at all), so trying to show you the hash doesn't prevent this attack.

2) The website shows a hash and deliberately sends you a piece of malware. Presumably, they're showing you the correct hash for the malware, so again the hash doesn't help.

3) The website shows a hash and directs you to another site that hosts the file. Now, if the second site deliberately sends you malware, the hash allows you to detect this. This is the only case I know of where the hash actually does help, and it only helps because it's on a completely different site. Note that this assumes the person putting malware on the second site has no control over the first site and is not MITM'ing you.

P.S. I'd recommend reading the very strongly related question over on Security.SE "What security purpose do hashes of files serve?". The answer there covers a lot of the same ground I just did.

6
  • 3
    Another legitimate use would be if the page listing the download is served over SSL (so properly identified), but the download itself is not over SSL to save on resources. – cbojar Jun 8 '15 at 19:06
  • Thanks, I'm aware that 1) and 2) are not valid use cases but I do think that 3) is actually a pretty big deal. I often download binaries from sites that use mirrors for download. They usually provide hashes but I very rarely check them even though I know I should... I'm guessing I'm not the only one in this boat. – Keith Jun 8 '15 at 20:01
  • I'm not saying it isn't a big deal, just that your proposal doesn't address it in any way. Plus, that particular use case is pretty thoroughly covered by the introduction of SSL/HTTPS. As long as the site providing the hash uses SSL/HTTPS, that hash is safe, and you can confidently check that your download is safe. – Ixrec Jun 8 '15 at 20:04
  • For what I'm proposing the referring site gets to set the hash for the site that it references. That is a critically important part of the use case and I don't think that is the case with ssl/https... right? I also don't understand why you say 3) isn't addressed. It's just adding a hash that's normally given as text for the user to validate in an attribute and asking the browser to validate. Sorry if I'm just being slow here. – Keith Jun 8 '15 at 20:14
  • 1
    This is being proposed and implemented as SRI. See my answer for details. – HRJ Aug 7 '15 at 20:23

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.