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

<meta http-equiv=Set-Cookie> should do nothing if document is cookie averse #1950

Closed
metromoxie opened this Issue Oct 23, 2016 · 9 comments

Comments

6 participants
@metromoxie
Copy link

commented Oct 23, 2016

In https://html.spec.whatwg.org/#table-http-equiv under Cookie setter, the algorithm should do nothing if the Document is cookie-averse. This would match the behavior of document.cookie in cookie-averse documents.

In particular, the Cookie setter algorithm should be updated similar to our proposed change in w3c/webappsec-suborigins#56, from:

  1. If the meta element has no content attribute, or if that attribute's value is the empty string, then abort these steps.

to

  1. If the meta element has no content attribute, or if that attribute's value is the empty string, or if the Document is cookie-averse then abort these steps.

cc @annevk @devd

@annevk

This comment has been minimized.

Copy link
Member

commented Oct 24, 2016

We should probably also do nothing if the document's origin is an opaque origin.

I think a good refactoring here would be to give document.cookie's setter and <meta http-equiv=Set-Cookie> a shared algorithm.

Other interested parties: @mikewest @bsittler @inikulin.

@bsittler

This comment has been minimized.

Copy link

commented Oct 26, 2016

Should <meta http-equiv=set-cookie ... > work when scripts are not allowed to execute?

@annevk

This comment has been minimized.

Copy link
Member

commented Oct 26, 2016

@bsittler when scripts are disabled or are you thinking specific documents that are not currently cookie-averse?

@mikewest

This comment has been minimized.

Copy link
Member

commented Oct 26, 2016

Given apparent usage, perhaps <meta http-equiv="Set-Cookie"> should do nothing at all: https://www.chromestatus.com/metrics/feature/timeline/popularity/1547 (that metric hasn't hit stable yet; I'm waiting on that data before deciding whether to send an "Intent to Make Developers Sad By Removing Things They Might Sometimes Rely On" to blink-dev@).

Given https://www.chromestatus.com/metrics/feature/timeline/popularity/1549, I do intent to treat it as "inline script" for CSP's purposes if we don't decide that removing it entirely is a reasonable thing to do. To that end, it should probably also fail inside <iframe sandbox="allow-same-origin"> or if JS is otherwise disabled.

@sendilkumarn

This comment has been minimized.

Copy link
Contributor

commented Oct 26, 2016

I will take this one, if it is up for grab

@annevk

This comment has been minimized.

Copy link
Member

commented Oct 26, 2016

@sendilkumarn thanks, but it seems like we should wait for usage metrics at least and a clarification from @bsittler. I'm going to remove the "good first bug" label for now until we have a plan.

@annevk annevk added the topic: cookie label Sep 6, 2017

annevk added a commit that referenced this issue Sep 6, 2017

@bsittler

This comment has been minimized.

Copy link

commented Sep 6, 2017

I regret not noticing the request for clarification from @annevk earlier. It's been too long to be sure, but I think I wondered three things:

  • whether cookie-aversion should prevent <meta http-equiv="set-cookie" ...>
  • whether restricting scripting (whether through UI or sandboxed iframe) should prevent it
  • whether a restrictive content-security-policy (e.g. one requiring script nonces or disallowing inline scripting) should prevent it (and if so, should there be a nonce allowance for this element?)

I think it's already clear that it should not work in a cookie-averse document, e.g. in html parsed by a scripts constructed document object.

I asked these in the context of cookie-averse documents because of the related suborigins proposal where suborigin documents are (IIRC) cookie-averse at the script level but HTTP-level Set-Cookie on their responses still works. Which policy should apply to the meta element?

Given that meta http-equiv=set-cookie can be dynamically constructed and inserted into the HEAD by script at any time (and modifies the cookie jar when added to the document), my intuition is that it should be restricted similarly to document.cookie in cases where scripting is allowed, but this leaves the question of whether to allow it when scripting is not allowed -- whether by UI setting, by iframe sandboxing, or partially disallowed by content security policy forbidding some or all inline scripts.

annevk added a commit that referenced this issue Apr 27, 2018

Make <meta http-equiv=set-cookie> into a no-op
Tests: ...

Closes #1950, closes #3011, and fixes #3076.

@annevk annevk closed this in #3649 Apr 27, 2018

annevk added a commit that referenced this issue Apr 27, 2018

<meta http-equiv=set-cookie> is now a no-op
Tests: cookies/meta-blocked.html in web-platform-tests.

Closes #1950, closes #3011, and fixes #3076.
@jccleaver

This comment has been minimized.

Copy link

commented Oct 26, 2018

Given that meta http-equiv=set-cookie can be dynamically constructed and inserted into the HEAD by script at any time (and modifies the cookie jar when added to the document), my intuition is that it should be restricted similarly to document.cookie in cases where scripting is allowed, but this leaves the question of whether to allow it when scripting is not allowed -- whether by UI setting, by iframe sandboxing, or partially disallowed by content security policy forbidding some or all inline scripts.

Yes. We're using CSP to block scripts but relied on this to set cookies in static pages. For the life of me, I can't understand why anyone thought the ability for a cookie to be set using simple HTML needed to be killed after all these years.

@annevk

This comment has been minimized.

Copy link
Member

commented Oct 29, 2018

Because it's been a source of subtle security bugs and is almost never used.

alice added a commit to alice/html that referenced this issue Jan 8, 2019

<meta http-equiv=set-cookie> is now a no-op
Tests: cookies/meta-blocked.html in web-platform-tests.

Closes whatwg#1950, closes whatwg#3011, and fixes whatwg#3076.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.