support subresource integrity [was: CDN does not offer specific versions]

[alexbecker]

According to the documentation, the MathJax CDN does not offer any endpoints for specific versions, but only for latest patch versions. This makes using subresource integrity with the CDN effectively impossible. I understand the desire to give users the latest patches--this is one reason to use the CDN after all--but it should be possible to use the CDN without compromising security.

[pkra]

@dpvc @zorkow any thoughts?

but it should be possible to use the CDN without compromising security.

While I'm not strictly against this request, this particular argument strikes me as odd. Using a third-party CDN seems to always compromise security. After all, it could shut down or our domain might accidentally expire and be bought up by some spyware-injecting company.

[alexbecker]

@pkra The great thing about subresource integrity is that it solves exactly this problem. If the resource served is not byte-for-byte identical to what is expected, the script will simply be ignored. So if a spyware-injecting company buys the domain and injects spyware, the worst thing that can happen to the user is that their equations don't render.

[zorkow]

I'm not sure I understand what the attack scenario would be, and how having control over versions would help. On 1 Feb 2016 8:23 a.m., "Peter Krautzberger" notifications@github.com wrote:

@dpvc https://github.com/dpvc @zorkow https://github.com/zorkow any thoughts?

but it should be possible to use the CDN without compromising security.

While I'm not strictly against this request, this particular argument strikes me as odd. Using a third-party CDN seems to always compromise security. After all, it could shut down or our domain might accidentally expire and be bought up by some spyware-injecting company.

— Reply to this email directly or view it on GitHub https://github.com/mathjax/MathJax/issues/1366#issuecomment-177838349.

[pkra]

@pkra The great thing about subresource integrity is that it solves exactly this problem. If the resource served is not byte-for-byte identical to what is expected, the script will simply be ignored.

Thanks for repeating that.

@zorkow

I'm not sure I understand what the attack scenario would be, and how having control over versions would help.

See the linked spec.

[pkra]

or https://blog.cloudflare.com/an-introduction-to-javascript-based-ddos/

[zorkow]

So it's a fancy name for distributing a hash. Not very practical from a MathJax POV. But we could always offer the latest.

[pkra]

Not very practical from a MathJax POV.

Yeah, I was wondering about this.

@alexbecker I suspect this would require not just CDN maintenance but cause lots of actual implementation work in our own resource loading facilities; for legacy browser support, MathJax loads its resources by injecting script tags into the DOM and I suspect we would need to inject them with the correct hashes. So that seems difficult, especially since we're starting to work on 3.0 which will see a completely different approach to the resource loading.

[pkra]

Of course, if there needs to be some work on the code then PRs are more than welcome. If not, even better.

[alexbecker]

The <script> tag injections makes this much harder, yes. The hashes could be hard-coded in, but they'd have to be recomputed with every release, and any circular references would break. A build tool would probably be required to automate the process. It probably isn't worth it currently, but subresource integrity is worth keeping in mind for 3.0 if you remove the script injections.

In my specific use-case, I was able to use mathjax-node to precompile my equations and get better security and performance than a verified script from the CDN, so thanks @pkra for maintaining that!

[pkra]

The hashes could be hard-coded in, but they'd have to be recomputed with every release, and any circular references would break.

Thanks for confirming.

It probably isn't worth it currently, but subresource integrity is worth keeping in mind for 3.0 if you remove the script injections.

Definitely. Thanks for filing the issue and helping us understand the problem!

[moble]

Unless I misunderstand what is being requested, this seems to be resolved by now. For example, I can do this:

<script type="text/javascript"
        src="https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.1/MathJax.js?config=TeX-AMS-MML_HTMLorMML"
        integrity="sha384-Ra6zh6uYMmH5ydwCqqMoykyf1T/+ZcnOQfFPhDrp2kI4OIxadnhsvvA2vv9A7xYv"
        crossorigin="anonymous">
</script>

It is true that I had to compute the integrity hash myself, using

curl 'https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.1/MathJax.js?config=TeX-AMS-MML_HTMLorMML' -o mathjax.js
openssl dgst -sha384 -binary mathjax.js | openssl base64 -A

So maybe that could be included with the documentation for each release, for example. But it certainly seems like the original issue can be closed.

[alexbecker]

Yes, this is no longer an issue now that the CloudFlare CDN has replaced MathJax's CDN and offers specific versions. The issue was that previously you couldn't specify version 2.7.1 for example, so the resource would regularly change on you.

[pkra]

Please note that this will likely be insufficient.

MathJax 2.x loads its resources by inserting script tags and is not set up to pass integrity hashes along.

If you need proper SRI in 2.x, you will have to either whitelist all components or use a single-file build. (In v3., this won't be a problem anymore as the loading will occur differently.)

[moble]

@pkra It works on a simple page of mine, but I'm wondering if there are more complicated tex or maybe different configs that might screw it up. Do you have any examples?

[moble]

Oh, I see. There are more scripts that are loaded, but they don't have SRI; only the first one that I enter manually has SRI. So it's still a valid issue.

[falsandtru]

Mathjax should be able to have and use integrity of all the extension files. It shouldn't be difficult. All the integrity is listed in https://cdnjs.com/libraries/mathjax.

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