Secure autoloading by integrity

[falsandtru]

Prism doesn't check integrity of extension scripts with autoloading. Can you make Prism secure by checking integrity? All the integrity is listed in https://cdnjs.com/libraries/prism.

FYI: https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity

[joshgoebel]

Out of curiosity what is the use case here? IE: How is this intended to be used in real life effectively? I was trying to think if this is something Highlight.js should consider for the future. I understand the idea of checksums for CDN resources (to prevent the resources from being replaced with malicious ones), but... I'll use an example from Highlight.js now:

A LOT of users load our entire library via CDN (and additional grammar modules if they need them; we build some in). But typically (in these cases) they are pulling in the main highlight.min.js "core" library from CDN as well... so if the CDN was compromised then then the checksums would just as easily be compromised.

Is this only for cases where the main prism.js is some how vendored (tightly controlled) and perhaps not loaded from CDN at all?

I wonder if it wouldn't be more/equally important to update all the docs to make sure users (using CDNs) are loading the core JS library itself with a SHA384 integrity tag...? Or perhaps this isn't an issue because Prism core always expects to first be run thru a complex build pipeline rather than ever loaded discretely via <script>?

[falsandtru]

so if the CDN was compromised then then the checksums would just as easily be compromised.

The correct checksums copied to our service can't be compromised.

[joshgoebel]

@falsandtru Why not? And I'm talking about any CDN service not just cdnjs.com... it seems the "master database" of SHA384 keys (stored in prism.js?) only has any "guaranatee" at all if it's coming from a "known good" server, such as one NOT on the CDN... then the other resources are perhaps fetched via CDN...

This is what I was asking for clarification on...

Again in other cases I'm familiar with the library itself is loaded via CDN... (then the modules are loaded from CDN)... so if the library has already been compromised then any embedded SHA384 would also be suspect.

[falsandtru]

I'm expecting the following scenario.

1. The integrity of the core library is verified by the correct checksum.
2. The correct checksums of plugins are contained in the verified core library.
3. The integrity of plugins is verified by the correct checksums contained in the verified core library.

[joshgoebel]

Number one is just as simple as adding the integrity attribute to the rendered HTML? Right?

[falsandtru]

Yes.

[joshgoebel]

@falsandtru Thanks. :) We're going to start making these digests available for Highlight.js going forward:

highlightjs/highlight.js#2892

For us it's all manual (no auto-loading) but still this might provide a nice security bump to those who want/need it.