如何确保通过 CDN 交付的 JavaScript 文件不被更改？

我正在研究一个场景，其中一些 JavaScript 文件将托管在 CDN 上。我希望有一些机制，以便当这些文件在用户端下载时，我可以确保这些文件没有被篡改，并且确实来自指定的 CDN。

我理解，如果我使用 SSL，这项任务非常容易，但是，我仍然希望确保即使在没有 SSL 的 HTTP 上也能提供正确的文件。

据我所知，目前还没有像 JavaScript 文件的数字签名这样的跨平台支持的机制。也许不需要？

浏览器是否内置了某种方法来验证 JavaScript 文件的作者？我能做些什么来保证安全吗？

14160 次浏览
小开

You're looking for subresource integrity checks.

For example, here's the jQuery CDN snippet:

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

As a matter of fact, a feature like this is currently being drafted under the name of Subresource Integrity. Look into the ABC0 attribute of the <script> tag. While not yet fully adopted across the board, it fulfills just this purpose.

integrity

Contains inline metadata that a user agent can use to verify that a fetched resource has been delivered free of unexpected manipulation. See Subresource Integrity.

Source

Subresource Integrity (SRI) is a security feature that enables browsers to verify that files they fetch (for example, from a CDN) are delivered without unexpected manipulation. It works by allowing you to provide a cryptographic hash that a fetched file must match.

Source

Example:

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

Note however that this will not protect you against Man in the Middle attacks if you are transferring your resources via plain HTTP. In this case, the hash code can be spoofed by the attacker, rendering the defense 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.

小开

Disclaimer: As always, you should only consider these mechanisms to be of any use when using https, as they can easily be disabled via MitM with 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 to note here. The sha*- prefix specifies the algorithm used to generate the hash. In the example above, sha256- is used. CSP also supports sha384- and sha512-. When generating the hash do not include the tags. Also capitalization and whitespace matter, including leading or trailing whitespace.

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

This mechanism has been around for quite some time, so the browser support is likely pretty good, just be sure to check.

Additionally, if you want to ensure that older non-compliant browsers are not insecure, you can include a synchronous redirect script at the top of the page that is not allowed by the policy.

小开

If your adversary model permits an attacker to modify JavaScript files as they are delivered from a CDN, then your adversary model permits an attacker to modify the referring source as it is delivered to remove any attempt at verification, to alter the source address to other than the CDN, and/or to remove the reference to the JavaScript entirely.

And lets not open the can of worms of how your application can determine whether the user's resolver is or is not correctly resolving to the CDN via HTTP requests (or any other mechanism that doesn't have a verified chain of trust).

/etc/hosts:

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

There's an important point about what this kind of signing can and cannot do. It can protect the user from hypothetical attacks in which someone modifies your code. It cannot assure your site that your code is the code being executed. In other words, you still can't trust anything that comes to your site from the client.

小开

You can ensure this with Subresource Integrity. Many public CDNs include SRI hashes in the embeddable code offered on CDN websites. For example, on PageCDN, when you click on jquery file on the jQuery CDN page, you get the option to either copy the URL or use the script tag that contains SRI hash as below:

<script src="https://pagecdn.io/lib/jquery/3.4.1/jquery.min.js" integrity="sha256-CSXorXvZcTkaix6Yvo6HppcZGetbYMGWSFlBw8HfCJo=" crossorigin="anonymous"></script>

On page load, browser will issue a request for this resource and on completion of request it will match the hash of the received file with the one given as the integrity value in script tag. If both hashes do not match, browser will discard the jquery file.

At the moment, this feature is supported by 91% of browsers worldwide. More details on caniuse.


提交答案