SXG files can't be protected by nonce-based CSP

[shhnjk]

SXG file is valid for 7 days (IIRC), and that file will serve static response header specified inside SXG file. This doesn't align with the concept of nonce-based CSP, where server needs to serve random nonce for every request.

Since SXG might have DOM-based XSS, attacker can just read nonce inside the SXG file and use same nonce in the XSS payload.

We should expose option to service CSP nonce, which is generated by browser when rendering SXG file. Publisher of SXG file can specify <script nonce={}>, where browser will replace {} with randomly generated nonce for every request. This should be safe because SXG file is a static file, so there is no threat for stored or reflected XSS. The only concern is the DOM XSS.

[shhnjk]

CC: @mikewest @arturjanc

[jyasskin]

Thanks for noticing this! Would it be better to ban nonces from packaged resources entirely? Or https://lists.w3.org/Archives/Public/public-webappsec/2014Sep/0055.html suggests an 'unsafe-static-inline', which might be equivalent to your nonce={} suggestion.

[mikewest]

My suspicion is that something like Trusted Types is going to be a better defense against DOM-based XSS than CSP.

That said, I have been thinking about a variant of CSP in which the browser would send out a nonce along with each request (I wrote a doc internally back in July... I should publish it somewhere), and expect the server to reflect it. It seems like that might be something we could assume for SXG, as you've noted above.

[mikewest]

(https://github.com/mikewest/strict-csp-for-everyone/, FWIW)

[shhnjk]

Thanks for noticing this! Would it be better to ban nonces from packaged resources entirely? Or https://lists.w3.org/Archives/Public/public-webappsec/2014Sep/0055.html suggests an 'unsafe-static-inline', which might be equivalent to your nonce={} suggestion.

I think browser should implement a way to serve nonce for static files. It's not only SXG that requires this feature, but also extensions.

My suspicion is that something like Trusted Types is going to be a better defense against DOM-based XSS than CSP.

Then maybe we enforce Trusted Types to SXG files that has CSP? That way, we break all SXGs and the web is now safe😊

[arturjanc]

I would say that Trusted Types and Mike's https://github.com/mikewest/strict-csp-for-everyone/ proposal are interesting platform solutions to this problem, and I'd bank on them being the recommended solutions for static content in the future.

Currently, CSP nonces have limitations which makes them a fairly poor fit for any cacheable content. Instead, an approach that could work well for SXG is hash-based CSP where external scripts are loaded via a bootstrapping script, as outlined in https://csp.withgoogle.com/docs/faq.html#static-content. My guess is that this would be fairly straightforward to deploy and can be useful until the other features ship.

[shhnjk]

I agree with @arturjanc. So should we BAN nonce in SXGs until those feature ships?

[jyasskin]

I'm happy to ban nonces in SXGs. Should they be banned or ignored for all cacheable content (which is a superset of SXGs)?

[arturjanc]

I don't think it's really necessary to have special logic for CSP in SXG. It's already possible to configure your CSP in ways that gives you no security benefit (e.g. script-src 'unsafe-inline' https:) and it's up to the developer to define a policy that will work for their setup.

Also, there is one mode of deploying nonce-based CSP in SXGs that could be useful:

1. Set a CSP of script-src 'nonce-staticknownvalue' 'strict-dynamic'
2. Add the nonce to all scripts in the SXG <script nonce="staticknownvalue">.
3. In the SXG, after DOMContentLoaded, add a new CSP via a <meta> element with a random, dynamically generated nonce and strict-dynamic:
   script-src 'nonce-[Math.random()]' 'strict-dynamic'

Since both the original CSP and the dynamically added one will apply simultaneously, and their nonces will be different, the only scripts that will be able to be loaded by the SXG are those created by APIs allowed by 'strict-dynamic'. This would protect the SXG from any injections that happen after DOMContentLoaded, assuming the lack of script gadgets.

I wouldn't claim that it's a good way to use nonces, but it could be an interesting alternative to hashes in some scenarios. So allowing them in SXG files and cacheable content may offer some benefits (in addition to not introducing the complexity of different CSP behavior depending on the type of document.)

[mikewest]

I generally agree with Artur's comments.

I'd also note that hashes are probably a better answer, especially given the timeframe in which a specific bundle is known to be good. Some script files do change every 7 days, but many don't, and would be best locked-in via hashes. Since I imagine that bundler scripts must exist regardless in order to deal with the signature mechanism, it seems reasonable to point folks in that direction (with Artur's crazy hacks as a backstop).

[shhnjk]

Agreed :)

[jyasskin]

Is that consensus to close this issue? If not, what's the next step?

[shhnjk]

Probably add security consideration, or inform SXG users to not to use nonce and use hash instead, if they are using CSP in SXG's inner response.