Content Security Policy error because of inline script

[jezdez]

Issue Summary

@ranbena @arikfr The change in #3609 leads to a Content Security Policy error when loading any page:

Chrome:

Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self' 'unsafe-eval'". Either the 'unsafe-inline' keyword, a hash ('sha256-lUaehHefE2UfaxjnDzUj5HBFcQ3z+oaNbFFBqOJn9Ck='), or a nonce ('nonce-...') is required to enable inline execution.

Firefox:

Content Security Policy: The page’s settings blocked the loading of a resource at inline (“script-src”).

I don't think we should add unsafe-inline to the script-src directive but instead indeed provide a per-request nonce in the format

<script nonce="<random nonce>">
    //...
</script>

Flask-Talisman supports rendering a random nonce like shown in the example here . Sadly we can't just not apply CSP since the templates are used on every page, if I understand correctly.

Right now multi_org.html is the only one that is rendered via Jinja2, but I think it's safe to do that for index.html, right?

Alternatively, would it suffice to move the <script> block into an own script that we can load instead?

Can you think of a way to fix this?

Steps to Reproduce

1. Open any page.
2. See the browser console.

Technical details:

• Redash Version: master
• Browser/OS: Firefox/macOS
• How did you install Redash: Docker

[arikfr]

Both options are not great:

• Rendering with Jinja -> couples the frontend with the backend, which we want to avoid.
• Moving this script to its own file -> makes page load slower.

What if we move it to its own file, but also move it to the body section? @ranbena

[jezdez]

(sorry for the typos)

[ranbena]

What if we move it to its own file, but also move it to the body section? @ranbena

Relocating the script into body won't improve perf. Scripts are synchronous by default no matter where in the document they are declared.

Options:

1. We can generate the nonce (a hash of the script content) and use it hardcoded to avoid relying on a server. I don't see us changing this script anytime soon so it might be good enough.
2. We can explicitly set async on the script for optimal loading perf but then we won't be able to use the IE conditional comment (it expects onIE() to already exist). I think this can be worked around with more useragent parsing.
3. We can explicitly set defer on the script, so it loads after document is ready but it may not run if previous scripts generate an error, which is expected if browser is IE. I'm not certain of this though.

Looks like option 2 is best.

[arikfr]

We can generate the nonce (a hash of the script content) and use it hardcoded to avoid relying on a server. I don't see us changing this script anytime soon so it might be good enough.

The nonce should be randomized on every request or otherwise it serves no purpose :)

Is there some good reference on why having script tags is a security concern?

[ranbena]

The nonce should be randomized on every request or otherwise it serves no purpose :)

Got the terms mixed up. I meant "hash-source" <hash-algorithm>-<base64-value>.

Content-Security-Policy: script-src 'sha256-B2yPHKaXnvFWtRChIbabYmUBFZdVfKKXHbWtWidDVF8='

More info here

Is there some good reference on why having script tags is a security concern?

I reckon it has to do with the risk of 3rd party modification like browser extensions.

[arikfr]

The hash-source option seems as the best one, no?

[ranbena]

The hash-source option seems as the best one, no?

Apparently, his feature (SRI) is only available for external file fetches.

I'll attempt the 2nd option then.

[jezdez]

Thanks @ranbena!