18

Is there any implementation or specification for including a hash or signature in an attribute of a <script> tag, so that the browser can verify that the correct file was retrieved before executing it? Something like:

<script
  src="http://cdn.example.com/jquery-2001.js"
  signature="sha-256/e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
></script>

The motivation is this: generally, each additional CDN or host you use for your site increases your vulnerability, by adding a new target that can be hacked to compromise your site. Allowing your primary front-end servers to assert hashes or signatures of those files could entirely eliminate that risk, allowing you to be more flexible when designing your architecture. You could even request missing files from an untrusted peer-to-peer network.

I thought I remembered a specification about this, but haven't been able to find it.

sideshowbarker
  • 81,827
  • 26
  • 193
  • 197
Jeremy
  • 1
  • 85
  • 340
  • 366
  • [There is no `signature` attribute.](https://html.spec.whatwg.org/multipage/scripting.html#the-script-element) Why do you need this? – Ram Mar 26 '15 at 03:34
  • I didn't expect this to be in the accepted standards yet, but thought there was a proposal that had been implemented on some platform. `signature` was an example of what the name could be -- I'd expect the real name and syntax to be more well-thought-out than my example. –  Mar 26 '15 at 03:37
  • Something like this is necessary to be able to use shared CDNs (like the ones provided by jQuery), or CDNs in general, without increasing your security risk. Generally, each additional CDN service you add means one more service that could be hacked to compromise your site. If your primary site can assert hashes/signatures of the files it's referencing, that risk is eliminated. I'm sure we will have a standard eventually. –  Mar 26 '15 at 03:39
  • 2
    Well, this can be a good security layer and makes sense! You can load the file programmatically and leave the validation to your application. I live in a country that it's stupid government filters domains randomly for no particular reason and do not use CDNs. – Ram Mar 26 '15 at 03:41
  • Some more info: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20789 – Jeremy Apr 02 '15 at 07:50
  • as Vohuman suggested, theoretically you can implement it by yourself. download the file using xhr and analyse the signature. should be easier with webcrypto. you can also implement it in a service worker so it can be also seamless to the page js code. And it will be nice to have a callback when you have signature mismatch – Bnaya Apr 08 '15 at 15:59

2 Answers2

20

This feature was proposed by the W3C as Subresource Integrity. As of December 2015, this recommendation has been implemented by Chrome 44 and Firefox 43.

EXAMPLE 1 
<link rel="stylesheet" href="https://site53.example.net/style.css"
      integrity="sha256-vjnUh7+rXHH2lg/5vDY8032ftNVCIEC21vL6szrVw9M="
      crossorigin="anonymous">

There is a superficially similar feature in Content Security Policy Level 2, but it only restricts the contents of inline <script> and <style> elements, not external ones.

Jeremy
  • 1
  • 85
  • 340
  • 366
0

It does not look like it is supported according to Mozilla Developer Network docs:

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script

However, you could always fetch a resource via XHR (assuming CORS is configured), hash it, and if it is cool, eval(). However, while an interesting technical exercise it does not seem practical.

Remento
  • 927
  • 4
  • 6