Restrict <meta http-equiv=set-cookie>

[annevk]

Tests: ..?

Fixes #1950.

[annevk]

@mikewest how would I add the CSP inline script protection? Something like this perhaps:

1. If the Should element's inline behavior be blocked by Content Security Policy? algorithm returns "Blocked" when executed upon the meta element, "script", and the meta element's content attribute value, then return.

[annevk]

I suspect @bsittler's suggestion was to add a check for https://html.spec.whatwg.org/#concept-n-script as well. I don't think it's expected that if you disable scripting you also disable set-cookie, although I suppose this is a bit of a mixed bag.

[bsittler]

Do CSP and meta http-equiv=set-cookie ever actually co-occur in the wild outside of test suites? If not, perhaps presence of CSP could prevent the element's cookie-setting behavior entirely

[bsittler]

(I meant: mere presence of the content-security-policy header or meta element; however that would still, in the meta-supplied-csp case, give document authors a chance to set cookies this way prior to the CSP-supplying element)

[annevk]

I'm not sure, but https://www.chromestatus.com/metrics/feature/timeline/popularity/1549 is nonzero and that is about a subset.

We should probably also consider sandboxing restricting this as you suggested, though I'm not sure if I want to tightly couple all those changes.

[mikewest]

I would enjoy getting rid of <meta http-equiv='set-cookie' ...> entirely. However, usage is hovering around 0.02%, which is higher than I'd like to see. I get ~298 hits on that in HTTP Archive's 2017-07-15 run, with no real pattern to the few I spot-checked. shrug

I think it's conceptually tied to script-src, since it seems to me that setting a cookie from a page should require script access, but I'm not sure the impact is worth the churn. Perhaps @dveditz or @johnwilander has an opinion from Firefox/Safari respectively?

[annevk]

It sounds like we should maybe make the change I proposed here first and then file a follow-up if anyone is interested in further restrictions.

[mikewest]

SGTM! :)

[domenic]

LGTM, just waiting on tests.

[annevk]

FWIW, I looked into tests a bit, but there appear to be none for this feature and existing cookie tests weren't super clear either...

I wonder if @bsittler has looked into improving that for his cookie work?

[dveditz]

@mikewest could you get a sense whether the documents you saw using this were "old" or created more recently? Was it on documents that were trying to be "no-scripty", or do you think it was just folks who didn't have the control of Set-Cookie headers on their server?

I'd be fine killing this in script-disabled contexts, or treating it like inline-script for CSP purposes.

If you want to kill it more generally (which I'm OK with) perhaps it should be part of a re-examination of the entire mechanism. Does it really make sense to allow content to set arbitrary headers? Maybe we should enumerate the ones we have to support for historical reasons and disallow the rest.

[annevk]

@dveditz if by content you mean HTML, <meta http-equiv> is already restricted to a limited list in the standard. set-cookie just happens to be one of the allowed values.

[mikewest]

@dveditz: The usage graph is spikey https://www.chromestatus.com/metrics/feature/timeline/popularity/1547. I suspect that's because Cloudflare uses it on their gateway error page (e.g. http://www.xuebang.com.cn/ contains <meta http-equiv="set-cookie" content="cf_use_ob=0; expires=Fri, 22-Sep-17 08:57:01 GMT; path=/"> (note: That might be a porn site if/when it ever starts loading, so, you know, browse carefully)). Poking them about it again in https://twitter.com/mikewest/status/911151559173689344.

[mikewest]

Spot-checking HTTP Archive, I'm going to try to deprecate this in Chrome. Cloudflare seems to account for a substantial amount of usage, and they seem amenable to dropping it from their error pages. If they drop it, and the usage numbers go down accordingly, I'll try for removal.

Intent to Deprecate at https://groups.google.com/a/chromium.org/d/msg/blink-dev/0sJ8GUJO0Dw/iMmcXLIGBAAJ

[mikewest]

@annevk: Should we repurpose #1950 for general deprecation/removal of http-equiv="set-cookie"? Or would you prefer filing a new issue? In addition to Dan's support above, Edge has expressed support for general removal in https://twitter.com/patrickkettner/status/911282308337983489.

[annevk]

I filed #3076 for you, seems a little cleaner.

[bsittler]

@annevk i do have some coverage for <meta http-equiv="set-cookie" ... > in pending https://crrev.com/c/594890 as part of the async cookies API effort; i just uploaded a snapshot that reverses the expectations (i.e. expects the meta element to have no effect) as that behavior is now default in chromium's WPT runner

[bsittler]

There is coverage of this from the point of view of the still-tentative "async cookies API" in web-platform-tests/wpt@cd3a926 - I intend to create parallel cases not relying on that API but have not yet done so. /cc @pwnall

Actually it looks to me like @mikewest already added the needed test: https://github.com/w3c/web-platform-tests/blob/master/cookies/meta-blocked.html