Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider hiding content attribute of meta tag CSP #291

Open
vrastogi opened this issue Jan 31, 2018 · 5 comments
Open

Consider hiding content attribute of meta tag CSP #291

vrastogi opened this issue Jan 31, 2018 · 5 comments
Labels
agenda+ To be discussed at a triage meeting needs concrete proposal Moving the issue forward requires someone to figure out a detailed plan

Comments

@vrastogi
Copy link

Similar to the attack suggested in whatwg/html#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., #277) become available in the future, they should also have their content values hidden.

@annevk
Copy link
Member

annevk commented Jan 31, 2018

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

@vrastogi
Copy link
Author

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
Copy link
Member

mikewest commented Feb 2, 2018

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
Copy link

I think we've briefly covered this on another bug when discussing the nonce-hiding behavior from whatwg/html#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
Copy link
Author

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.

@qabandi qabandi added agenda+ To be discussed at a triage meeting needs concrete proposal Moving the issue forward requires someone to figure out a detailed plan labels Mar 12, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
agenda+ To be discussed at a triage meeting needs concrete proposal Moving the issue forward requires someone to figure out a detailed plan
Projects
None yet
Development

No branches or pull requests

5 participants