Going forward with CSP

[rugk]

Google has just released a CSP testing tool and some more detailed information about CSP.

They mention some interesting things:

1. There is a new 'strict-dynamic' being created.
2. unsafe-inline can always be used as a fallback for older browsers supporting only CSPv2. CSPv3-compliant browsers will ignore this if strict-dynamic, nonces or hashes are used.
3. They do discourage the use of 'self' in script-src as it can be bypassed in certain cases.

In CSPv3 you can AFAIK also define subdirectories (privatebin.org/scripts), which could be another way to strengthen our policy. However in this case there might be compatibility issues.

So together with #82 this might be an issue we can address in the future when CSP has further developed itself 😃

[Framartin]

Agreed. Using nonce- or sha256- in script-src is a a lot better than 'self' to mitigate the exploitation of XSS, like #183. See Documentation.

[rugk]

Interesting, there is a new strict-dynamic thing in CSPv3 that – as far as I understand it – let's one script load any other scripts.
I'm still thinking of whether that could make it easier to use nounces or in our case, rather, hashes (we do recalculate SRI hashes anyway, so another place for these would also be possible).

[rugk]

And there is more crazy (experimental) stuff (again found via Googles CSP tool), but that seems to look like a better solution for unsafe-eval, which we only include, because of Chrom/ium's PDF reader, so I guess we can ignore that…

[elrido]

The unsafe-eval is required in Chrome and Safari for WASM loading. If not set, calling WebAssembly.instantiate will trigger an error in those browsers.

PrivateBin/js/zlib-1.2.11.js

Lines 34 to 35 in 8232dce

	const module = await WebAssembly.compile(buff);
	const ins = await WebAssembly.instantiate(module, { env });

• Technical background
• Browser comparison matrix
• Proposal to W3C to standardize wasm-eval directive, that Chrome has implemented for web apps, but not web sites, that would allow to restrict eval while allowing wasm. It hasn't been accepted and even if it will, it will take years for browsers with support for it to be rolled out for a majority of users. :-(

[rugk]

Regarding unsafe-eval the Matrix Element client has the same issue and someone suggested this:

Using WebAssembly.instantiateStreaming would avoid this problem.

[rugk]

Also the docs for this say:

This is the most efficient, optimized way to load wasm code.

So would likely not be a bad idea to use this altogether…

[rugk]

Opened a new issue for that, so we can keep this “meta-issue” here and fix that WebAssembly loading: #814