Consider hiding content attribute of meta tag CSP

[vrastogi]

Similar to the attack suggested in https://github.com/whatwg/html/issues/2369, an attacker may be able to extract the nonce from a Content-Security-Policy specified via meta tag. I believe the content attribute value typically has no purpose being visible to the DOM and so may very well be set to an empty string.

If any other CSP meta tags (e.g., https://github.com/w3c/webappsec-csp/issues/277) become available in the future, they should also have their content values hidden.

[annevk]

Sigh, I'd really rather we just move folks away from meta elements.

[vrastogi]

I also agree with you to some extent as the meta tag exposes information that could be misused but the use of meta tags is real and necessary as some site operators can deploy CSP only via meta tags. Moreover, I have also seen meta tag CSP proposed as a defense against misbehaving browser extensions that tamper with the header CSP (extensions can modify the response headers but they cannot modify the page content).

[mikewest]

I'm not enthusiastic about this, for a few reasons:

1. The nonce-hiding mechanism we added to HTML is limited to cases in which we know ahead of time that a policy is going to be applied to the page (step 2 of the processing algorithm in https://html.spec.whatwg.org/#nonce-attributes points to a "header-delivered" policy). Mozilla folks were unwilling to implement without that limitation, as there's a real performance cost to the processing, and skipping it is preferable. <meta> was pretty explicitly out of scope.

2. <meta> as a defense against extensions is misguided. Pages are less privileged than extensions, and really can't expect CSP, however deployed, to defend against extension-driven manipulation. Both Chrome and Firefox have dome some work to allow extensions to bypass various bits of CSP, and I'd expect more of that in the future, not less.

3. I do agree that some sites use <meta> because they can't alter headers, and that might be a reason to accept a report-uri-less content-security-policy-report-only policy via <meta>. That seems fine, but it's fairly explicitly best-effort, and not a robust solution. I'm reluctant to add additional processing mechanics to <meta>, and pretty comfortable with <meta> being a second-class delivery mechanism.

Can you help me understand the counter arguments? What attacks would this prevent? How helpful would it be?

[arturjanc]

I think we've briefly covered this on another bug when discussing the nonce-hiding behavior from https://github.com/whatwg/html/issues/2369. Basically, while this indeed allows the nonce to be exfiltrated from the <meta> tag with CSS and other scriptless techniques, there are three things to consider here:

1. The majority of users of nonce-based policies enable CSP via a response header, for various reasons (e.g. the fact that they need to use Report-Only mode not available via <meta>).
2. When CSP is specified in <meta>, the nonce-hiding behavior doesn't kick in because it applies only to CSP sent in a response header -- so hiding the meta#content attribute wouldn't help against nonce exfiltration.
3. The developer can remove the <meta> element from the DOM (e.g. with a <script> block right after the <meta>) to prevent the nonce from leaking. It's not elegant, but should be okay in the subset of cases where developers set nonce-based policies in <meta>.

I'd agree with Mike that we wouldn't gain much if we did this; but there is probably at least some opportunity to better explain the current behavior in the spec.

[vrastogi]

Thank you, all the comments here make sense. As @arturjanc suggests, it may be a good idea to document his points 2, and possibly 3, in the spec. Otherwise, I think we can close this issue.