Building in SHA-256 hashing for javascript

Building in SHA-256 hashing for javascript

by Garrett Boone -
Number of replies: 15

Hi, I'm new to the community and used to be an online high school math teacher. I'm now working on a project for a health-care provider who offers side courses. From a security standpoint, I've been brainstorming how to run CSP without "unsafe-inline" for scripts.

If anyone has a solution for this, I'm very interested in hearing about it.

But I was thinking that it should possible to build in a hashing function so that the loaded modules, even with random-elements to them, can have a SHA-256 attribute. I'm about a year into part-time programming, so I'm not an expert by any means. But I was reading about how someone took the js-sha256 package and used it with requirejs.

I only just read about AMD last night, and I'm still trying to wrap my head around how everything is structured in Moodle (been on this for just a couple weeks now). Am I going to run into a dead-end? If not, I was surprised not to see this already implemented. My goal is to not have to allow unauthorized inline scripts.

Thanks for any tips!

Average of ratings: -
In reply to Garrett Boone

Re: Building in SHA-256 hashing for javascript

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

Don't try to re-invent the wheel, particularly when it comes to internet security. You will get it wrong.

Use what is tried and tested and standardised. That is: run the site over HTTPS.

In what way is that insufficient?

Average of ratings: -
In reply to Tim Hunt

Re: Building in SHA-256 hashing for javascript

by Garrett Boone -

I'm sorry, I'm not understanding your reply. It seems you know something I don't know, as I'm new to Moodle. Maybe you could point me to documentation that explains what Moodle does that nullifies the need for CSP? Looking through the security history, it seems pretty evident that script attacks are the primary concern, as would be on any site. https://www.cvedetails.com/vulnerability-list/vendor_id-2105/product_id-3590/Moodle-Moodle.html

A better question for me might be how is Moodle architecture sufficient? Site breaches occur through https too. I'm learning, and can understand quite a bit, but you know - one doesn't know what one doesn't know. Especially about how Javascript bundling puts the script code in with the HTML instead of having a separate file. How then, in general, is the security of that script addressed?

Thanks for the quick reply.

Average of ratings: -
In reply to Garrett Boone

Re: Building in SHA-256 hashing for javascript

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

In what sense are you using the abbreviation CSP?

Average of ratings: -
In reply to Tim Hunt

Re: Building in SHA-256 hashing for javascript

by Garrett Boone -

Content Security Policy

Average of ratings: -
In reply to Garrett Boone

Re: Building in SHA-256 hashing for javascript

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

With only one exception (MathJax) Moodle does not need any scripts form third-party servers. Therefore, you should be able to set a security policy that says only trust JavaScript from this server.

Of course, if you want to spam your users with nasty stuff like Google Analytics, or facebook like buttons, then you have a problem.

Average of ratings: -
In reply to Tim Hunt

Re: Building in SHA-256 hashing for javascript

by Garrett Boone -

No I don't want to include analytics. To me that's counterproductive - for this project, definitely counterproductive.

I think I need confirmation regarding CSP settings: if I do "script-src: 'self'" and that's it, then I am getting errors re: inline scripts.

If I do 'self' and 'unsafe-inline', I get no errors. This is what is to be expected, correct? And that leaves all inline-scripts unchecked at that point, correct?


https://webpack.js.org/guides/csp/ 

Webpack incorporates the use of nonce. Didn't see anything from Requirejs about this. But a plugin could possibly be made to function similarly, couldn't it?

https://stackoverflow.com/questions/42922784/what-s-the-purpose-of-the-html-nonce-attribute-for-script-and-style-elements

Here's an example of using nonce on the fly. I would think the same thing could be done with a hash instead of a nonce. If so, it would effectively shut down all non-hashed scripts.

Crazy idea or possibility?


Average of ratings: -
In reply to Garrett Boone

Re: Building in SHA-256 hashing for javascript

by Marcus Green -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers

Garret: what is the purpose of your cvedetails link?

Average of ratings: -
In reply to Marcus Green

Re: Building in SHA-256 hashing for javascript

by Garrett Boone -
The purpose of the link was to show as a reference the regularity of issues being related to scripting. Seems at least recently to be in the 30-40% range, with the other issues related to URL manipulation and more simple features-not-working-as-intended type problems.


I was simply coming at the general picture with a question regarding why can't scripts that are legitimately served be authorized with hashing so as to tighten up the security policy, thereby blocking either malicious or unintended scripts.

I'm still not sure I have my answer. Script from the same site still leaves open attacks from users. 

I've Googled the question to death and looked through StackOverflow, etc. but if a simple inline-script can be hashed so it's considered "safe", and requirejs script is being dynamically loaded so it's efficient...couldn't there be a solution where the outputted bundled javascript is hashed and noted as such before serving? Then the browser sees the script as hashed, and every other script as not hashed, and blocks it.

By hashing I don't mean using nonce, but sha-256 hashing like I can with some of the scripts that don't change in Moodle...but it's the other ones that do because they have random numbers in them that result in the hash no longer being valid. Of course, after purging caches it's all invalid again...but there is the history which brings me to how to make it safer.

Can it be done? It's not the hashing I can't understand, it's the process of bundling and then using templates to build out the final html page. I try not to approach things like it can't be done, but I definitely understand why in some cases in just isn't done for some other reason. Trying to learn what those reasons are, and if other procedures are in place to mitigate the risks (other than a process of reporting flaws, that is).

Average of ratings: -
In reply to Garrett Boone

Re: Building in SHA-256 hashing for javascript

by Marcus Green -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers

Is this something done by other comparable web applications?

Average of ratings: -
In reply to Garrett Boone

Re: Building in SHA-256 hashing for javascript

by Dan Marsden -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers Picture of Plugins guardians Picture of Testers Picture of Translators

I wouldn't bother with building in sha-256 hashing but you can implement csp headers in Moodle using our local_csp plugin:
https://moodle.org/plugins/local_csp

Just make sure you run it in reporting mode for a week or so first, and keep adjusting your reporting policy before you start using the blocking mode. Teachers like to embed all sorts of things in their courses.. 

Average of ratings: Useful (1)
In reply to Dan Marsden

Re: Building in SHA-256 hashing for javascript

by Garrett Boone -
I tried installing it before, actually... On the Moodle plugin page the download link wouldn't install. Eventually I got it to show up on the Local Plugins page, but I couldn't get it to work. I called it up to a version conflict. My entire site is served with https, so that feature is not something I'm concerned about.

I'd be willing to try installing this again if it can do what I'm looking for. There aren't many examples to find, so please forgive me for asking: does this give me the ability to "approve" scripts that are reported and then block all others?

Thanks

(Edited by Helen Foster to remove quoted copy of previous forum post - original submission Wednesday, 24 October 2018, 1:15 AM)

Average of ratings: -
In reply to Garrett Boone

Re: Building in SHA-256 hashing for javascript

by Dan Marsden -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers Picture of Plugins guardians Picture of Testers Picture of Translators

You might need to try installing the plugin manually rather than using the UI install process in the moodle.org plugins db (grab the latest version of the code from github too) 

yes - this allows you to define the csp header and define which domains should be allowed.

It provides the ability to generate warnings (report-only) - so you can add a CSP policy without affecting your users and get it to report on failures which you can review and allow you to adjust the CSP policy before you use the blocking policy.

Average of ratings: -
In reply to Dan Marsden

Re: Building in SHA-256 hashing for javascript

by Garrett Boone -

The good news: I got the CSP plugin working, thanks for your assistance with that.

I already had CSP in my headers, so I turned it off. The plugin looks nice - but, is it aimed toward getting people access to what is normally only done at the server level (without needing to go to the server)?  Or does it offer functionality beyond what implementing CSP on the server level provides? 

Average of ratings: -
In reply to Garrett Boone

Re: Building in SHA-256 hashing for javascript

by Dan Marsden -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers Picture of Plugins guardians Picture of Testers Picture of Translators
The main advantage is specified in the plugin description:

"Any policy you wish to use can be safely tested first using 'Report only' mode, and this plugin has a built in CSP aggregator and reports all errors which are raised. You can have two different policies, one for testing and one for enforcing and gradually move each directive from 'report' to 'enforcing' after the various issues have been found and fixed."

But this also makes the policy much easier to maintain - especially if you have multiple web servers.

Average of ratings: -