How can I make sure my JavaScript files delivered via CDN are not modified?

Question

I am working on a scenario in which some JavaScript files should be placed on a CDN. I want to have some mechanism so that when this file is loaded from the user side, I can guarantee that the files have not been tampered with and do come from the specified CDN.

I understand that the task is very simple if I use SSL, but still want to make sure that the correct files are served even over HTTP without SSL.

As far as I could look, there is no existing mechanism, such as digital signature for JavaScript files, which is supported on different platforms. Perhaps this is not necessary?

Is there any method built into browsers to validate the author of JavaScript files? Can I do this in a safe way?

Answer 1

Essentially, such a feature is currently being developed under the name Integrity Subresource. Look at the integrity attribute of the <script> . While it is not yet fully accepted in all directions , it fulfills precisely this goal.

integrity

Contains embedded metadata that the user agent can use to verify that the extracted resource was delivered without unexpected manipulations. See Subresource Integrity.

Source

Subresource Integrity (SRI) is a security feature that allows browsers to verify that the files they extract (for example, from a CDN) are delivered without unexpected manipulation. It works by letting you provide the cryptographic hash that the selected file should match.

Source

---

Example:

 <script src="https://example.com/example-framework.js" integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC" crossorigin="anonymous"></script> 

---

Please note that this one will not protect you from Man in the Middle attack if you transfer your resources via simple HTTP. In this case, the hash code can be tampered with by an attacker, which makes protection against manipulated script files useless.

For this reason, you should always use secure HTTPS connections instead of plain HTTP in addition to the security measures described above.

Answer 2

You are looking for verification of the integrity of sub-resources .

For example, here's a jQuery CDN snippet:

 <script src="https://code.jquery.com/jquery-3.1.0.js" integrity="sha256-slogkvB1K3VOkzAI8QITxV3VzpOnkeNVsKvtkYLMjfk=" crossorigin="anonymous"></script> 

Answer 3

Denial of responsibility. As always, you should keep in mind that these mechanisms can be used when using https, as they can be easily disabled using MitM using http

In addition to the mechanism in the above answers, you can also use the content-security policy http response headers on the parent page.

http://www.html5rocks.com/en/tutorials/security/content-security-policy/

Content-Security-Policy: script -src 'sha256-qznLcsROx4GACP2dm0UCKCzCG-HiZ1guq6ZZDob_Tng ='

There are a few things here. Sha * prefix - defines the algorithm used to generate the hash. The above example uses sha256-. CSP also supports sha384- and sha512-. When generating a hash, tags are not included. Capitalization and a space are also used, including leading or trailing spaces.

Using Chrome 40 or later, you can open DevTools and then reload the page. The Console tab will contain error messages with the correct sha256 hash for each of your built-in scripts.

This mechanism has existed for a long time, so browser support is most likely pretty good, just be sure to check.

In addition, if you want old incompatible browsers to be unsafe, you can enable synchronous script redirection at the top of the page, which is not allowed by the policy.

Answer 4

It is important there that such a signing can and cannot do. It can protect the user from hypothetical attacks in which someone modifies your code. It cannot guarantee your site that your code is executable code. In other words, you still cannot trust anything that comes to your site from a client.

Answer 5

If your adversary model allows an attacker to modify JavaScript files as they are delivered from the CDN, then your adversary model allows an attacker to change the source of links, since it is delivered to remove any verification attempt, change the source address except for CDN, and / or completely remove the JavaScript link .

And it allows you not to open a worm bank about how your application can determine if a custom converter is the wrong solution for CDN via HTTP requests (or any other mechanism that does not have a trusted trust chain).

/ etc / hosts:

 # ... 1.2.3.4 vile-pirates.org trustworthy.cdn # ...