Developer Tools: add mechanism for adding script to page directly as well as via URL

[CrispinF]

See discussion here https://www.cloudscribe.com/forum/thread/how-use-datatables-with-page-content-without-deployment-to-server

[markidox]

Complete

[CrispinF]

@markidox this has not actually been done, and I think needs discussion as a feature request. Re-opening.

[JimKerslake]

The main issue with doing this is that we are increasingly being pressured by customer pen test reports to implement Content Security Policies which prohibit the "Unsafe-Inline" execution of inline scripts. (The word Unsafe says it all really...)

We've been through the majority of the cs core repo and stripped out as many of these bits of inline JS wherever possible (various stray "onClick" references on buttons for example) - we didn't get them all yet, but the aspiration would be to make cloudscribe free of any such reliance on inline scripts, so we can keep the pen testers happy.

As specified/implemented at the moment this feature would be incompatible with that - needs thought about whether there might be a way of implementing this that circumvents the 'Unsafe'ness issue.

[CrispinF]

@JimKerslake couldn't this script content be brought securely into the page with a handler?

[JimKerslake]

Yes we'd need to do something like that - can't just 'HTML.Raw' the JS content from the database straight into an inline page <script> tag.

[markidox]

I've updated this to use a tag helper. The users entered JS is then rendered to the page under a tag and then an a JS file is run which picks up that JS and dynamically inserts it into the page in a <script> tag.

Whilst this may seem like it would violate CSP it doesn't as CSP cares not about how a script is rendered in the DOM but on how the script was/is created in the first place. Because we are using a trusted script to get the JS into the page the CSP doesn't count it as being 'inline', despite it appearing inline if you were to inspect the page.

[JimKerslake]

In practical testing, for me, this did still fail to execute the script when a NWebSec CSP was in place that did not permit UnsafeInline()

Maybe that's OK though... it fails cleanly and still renders that page - just no JS execution.
If we do implement such a CSP then maybe we want to prevent this kind of thing anyway... if we just state clearly on the UI that it is incompatible.

Alternatively perhaps we need to be computing, storing and delivering hashes for each dynamic script...?

[markidox]

I wonder if we need to put 'self' in that CustomSources list or if the s.Self is doing that?
It should work regardless if we have that in place, according to the interweb anyway: Content-Security-Policy: script-src 'self';

[JimKerslake]

I think I can see a route to doing this without triggering the CSP police... will make a second branch and have a tweak.