Intent to Deprecate: Setting cookies from `meta` tags.

[Mike West]

Primary eng (and PM) emails

mk...@chromium.org

Summary

We should deprecate setting cookies via `<meta http-equiv="set-cookie" ...>`.

Motivation

Currently, `<meta http-equiv="set-cookie" ...>` can be used to manipulate existing cookies for a host, or to set new cookies. It would be better from a security perspective if we required either access to HTTP headers (e.g. `Set-Cookie: ...`) or script execution (e.g. `document.cookie = "..."`). This allows a non-script content injection to upgrade itself to a session fixation attack, even in the presence of a strong content security policy, which is unfortunate.

Interoperability and Compatibility Risk

Edge: No signals.

Firefox: Positive to removal in https://github.com/whatwg/html/pull/3011#issuecomment-331181807.

Safari: No signals.

The main risk is that some websites depend upon the cookies set from `<meta>` for some critical functionality. I haven't seen that in spot-checking the HTTP Archive usage, and in fact the majority of the usage seems to be on Cloudflare error pages: they seem amenable to dropping that usage.

Alternative implementation suggestion for web developers

`document.cookie = "..."` from JavaScript, or `Set-Cookie: ...` from HTTP.

Usage information from UseCounter

https://www.chromestatus.com/metrics/feature/timeline/popularity/1547

`<meta http-equiv="set-cookie" ...>` shows up on ~0.02% of pages, with intermittent spikes up to ~0.06%. Cloudflare's error page seems like a reasonable explanation of this behavior. I'm hopeful that they'll migrate off of the `<meta>` tag, and onto one of the alternate suggestions above, and equally hopeful that we'll see a subsequent drop in the usage rate which would make removal possible.

OWP launch tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=767813

Entry on the feature dashboard

https://www.chromestatus.com/feature/6170540112871424

Requesting approval to remove too?

I'd like to see what happens with the numbers post-Cloudflare. One approach would be to set a removal milestone in ~2 releases (~65?). Another would be to wait and see what happens. I think I'd be fine with either.

-mike

[mk...@chromium.org]

Brief update: Patrick Kettner from Edge expressed support on that vendor's behalf in https://twitter.com/patrickkettner/status/911282308337983489.

[Rick Byers]

Interesting.  0.02% of PageVisits isn't tiny, but it's not huge either.

What can you say about "severity of breakage"?  Can you maybe look at some of the UseCounter hits in HTTP Archive and see if you can tell how they'd be broken (eg. is there any visible behavior difference if you use those pages on a build with this disabled?).  I'm wondering if, for example, ignoring set-cookie might cause some redirects to fail or loop or something?

Can you give more detail on the security benefit?  Are there any known examples of security incidents you can point to for which this would be a mitigation?  I'm offline on my way back from Tokyo right now so can't google it, but can you suggest a good link to understand "session fixation attack"?  Sorry for the noob questions.  I trust your judgement, but in the spirit of making intentional tradeoffs between our blink compat principles I'd like to understand myself why the compat pain is worth the cost.

Thanks!

   Rick

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2051dfb6-77a3-4ab1-a384-df636f6bd95b%40chromium.org.

[Mike West]

On Mon, Sep 25, 2017 at 2:23 AM, Rick Byers <rby...@google.com> wrote:

Interesting.  0.02% of PageVisits isn't tiny, but it's not huge either.

Yup. I agree. I'm hopeful that Cloudflare is indeed a large percentage of that number; they seem to agree that they can easily get rid of their usage.

 

What can you say about "severity of breakage"?  Can you maybe look at some of the UseCounter hits in HTTP Archive and see if you can tell how they'd be broken (eg. is there any visible behavior difference if you use those pages on a build with this disabled?).  I'm wondering if, for example, ignoring set-cookie might cause some redirects to fail or loop or something?

I dug into HTTP Archive a bit (query below): 182 resources across 155 pages matched in the September 1st run.

10 were Cloudflare error pages (all porn sites, coincidentally).

71 (39%) were using an old version of Web Trends that doesn't look like it actually cares about the `inject_params` cookie that's set. For example, it's embedded in a big chunk of "Top White Papers and Webcasts" ads (example, example, example) that all seem tied to marketing campaigns from Quinstreet. It doesn't look like there's any user-visible negative effect on these pages (and I've sent an email to Quinstreet).

Olympus has 6 sites that set a `currentlang` cookie, but dropping the `<meta>` is a no-op as it's also set as an HTTP header (I suspect this is the case for a lot of these examples, actually...).

Query:

```

SELECT

  *

FROM (

  SELECT

    page,

    url,

    REGEXP_EXTRACT(LOWER(body), r'http-equiv=["\']?set-cookie["\']?[^>]+\s?content=["\']?(.+)[\'"]?') as cookie

  FROM 

    [httparchive:har.2017_09_01_chrome_requests_bodies]

) WHERE

  cookie != "null"

```

I spot-checked 20 of the other pages with different cookies set, and didn't run into any catastrophic errors like redirect loops. I can dig into that data more if it would increase your confidence. :)

Can you give more detail on the security benefit?  Are there any known examples of security incidents you can point to for which this would be a mitigation?

It's bad for attackers to be able to manipulate cookies on a site, as HTTP is otherwise ~stateless. Currently, attackers can write to (but not read) cookies by injecting a `<meta>` tag, which is a lower bar than actually executing script on the origin, or modifying headers in flight. I'd like to remove this as an injection vector, both because developers don't generally know that it's possible, and don't have any mechanism of preventing it today.

That said, I don't have a specific attack at hand that this change would have prevented, but there's been weird behavior in the past (setting same-origin cookies via cross-origin SVG images, for instance) that we could collectively have avoided by not allowing markup to do scripty things. *shrug* Still, though, this aims to be a general hardening/sanity change, not one in response to a specific attack.

 

I'm offline on my way back from Tokyo right now so can't google it, but can you suggest a good link to understand "session fixation attack"?

https://www.owasp.org/index.php/Session_fixation is a high-level overview of session fixation (and calls out `<meta>` as an injection developers can't disable). https://www.lanmaster53.com/2014/10/29/session-fixation-demystified/ is another that looks reasonable.

 

Sorry for the noob questions.  I trust your judgement, but in the spirit of making intentional tradeoffs between our blink compat principles I'd like to understand myself why the compat pain is worth the cost.

These are exactly the questions you should be asking, and tradeoffs you should be weighing! Thanks!

-mike

[Philip Jägenstedt]

On Mon, Sep 25, 2017 at 10:10 AM Mike West <mk...@chromium.org> wrote:

On Mon, Sep 25, 2017 at 2:23 AM, Rick Byers <rby...@google.com> wrote:

Interesting.  0.02% of PageVisits isn't tiny, but it's not huge either.

Yup. I agree. I'm hopeful that Cloudflare is indeed a large percentage of that number; they seem to agree that they can easily get rid of their usage.

 

What can you say about "severity of breakage"?  Can you maybe look at some of the UseCounter hits in HTTP Archive and see if you can tell how they'd be broken (eg. is there any visible behavior difference if you use those pages on a build with this disabled?).  I'm wondering if, for example, ignoring set-cookie might cause some redirects to fail or loop or something?

I dug into HTTP Archive a bit (query below): 182 resources across 155 pages matched in the September 1st run.

10 were Cloudflare error pages (all porn sites, coincidentally).

71 (39%) were using an old version of Web Trends that doesn't look like it actually cares about the `inject_params` cookie that's set. For example, it's embedded in a big chunk of "Top White Papers and Webcasts" ads (example, example, example) that all seem tied to marketing campaigns from Quinstreet. It doesn't look like there's any user-visible negative effect on these pages (and I've sent an email to Quinstreet).

Olympus has 6 sites that set a `currentlang` cookie, but dropping the `<meta>` is a no-op as it's also set as an HTTP header (I suspect this is the case for a lot of these examples, actually...).

Query:

```

SELECT

  *

FROM (

  SELECT

    page,

    url,

    REGEXP_EXTRACT(LOWER(body), r'http-equiv=["\']?set-cookie["\']?[^>]+\s?content=["\']?(.+)[\'"]?') as cookie

  FROM 

    [httparchive:har.2017_09_01_chrome_requests_bodies]

) WHERE

  cookie != "null"

```

I spot-checked 20 of the other pages with different cookies set, and didn't run into any catastrophic errors like redirect loops. I can dig into that data more if it would increase your confidence. :)

Wow, that analysis must have been pretty exhausting, and I think it's quite enough already! If no serious problem are found in 182 cases you've checked, then that's already a very strong signal. Trying it may still reveal some other problem, but it seems implausible that more static analysis will be fruitful.

Can you give more detail on the security benefit?  Are there any known examples of security incidents you can point to for which this would be a mitigation?

It's bad for attackers to be able to manipulate cookies on a site, as HTTP is otherwise ~stateless. Currently, attackers can write to (but not read) cookies by injecting a `<meta>` tag, which is a lower bar than actually executing script on the origin, or modifying headers in flight. I'd like to remove this as an injection vector, both because developers don't generally know that it's possible, and don't have any mechanism of preventing it today.

That said, I don't have a specific attack at hand that this change would have prevented, but there's been weird behavior in the past (setting same-origin cookies via cross-origin SVG images, for instance) that we could collectively have avoided by not allowing markup to do scripty things. *shrug* Still, though, this aims to be a general hardening/sanity change, not one in response to a specific attack.

Makes good sense. Since compat situation looks pretty good right now, it's best to not wait until the web depends on it and a real attack is discovered! (Usage increasing after deprecation has happened, there was a funny graph at BlinkOn about that.)

I'm offline on my way back from Tokyo right now so can't google it, but can you suggest a good link to understand "session fixation attack"?

https://www.owasp.org/index.php/Session_fixation is a high-level overview of session fixation (and calls out `<meta>` as an injection developers can't disable). https://www.lanmaster53.com/2014/10/29/session-fixation-demystified/ is another that looks reasonable.

 

Sorry for the noob questions.  I trust your judgement, but in the spirit of making intentional tradeoffs between our blink compat principles I'd like to understand myself why the compat pain is worth the cost.

These are exactly the questions you should be asking, and tradeoffs you should be weighing! Thanks!

With positive signals from both Edge and Cloudflare, this is an easy LGTM1

[Rick Byers]

On Mon, Sep 25, 2017 at 8:28 AM, Philip Jägenstedt <foo...@google.com> wrote:

On Mon, Sep 25, 2017 at 10:10 AM Mike West <mk...@chromium.org> wrote:

On Mon, Sep 25, 2017 at 2:23 AM, Rick Byers <rby...@google.com> wrote:

Interesting.  0.02% of PageVisits isn't tiny, but it's not huge either.

Yup. I agree. I'm hopeful that Cloudflare is indeed a large percentage of that number; they seem to agree that they can easily get rid of their usage.

 

What can you say about "severity of breakage"?  Can you maybe look at some of the UseCounter hits in HTTP Archive and see if you can tell how they'd be broken (eg. is there any visible behavior difference if you use those pages on a build with this disabled?).  I'm wondering if, for example, ignoring set-cookie might cause some redirects to fail or loop or something?

I dug into HTTP Archive a bit (query below): 182 resources across 155 pages matched in the September 1st run.

10 were Cloudflare error pages (all porn sites, coincidentally).

71 (39%) were using an old version of Web Trends that doesn't look like it actually cares about the `inject_params` cookie that's set. For example, it's embedded in a big chunk of "Top White Papers and Webcasts" ads (example, example, example) that all seem tied to marketing campaigns from Quinstreet. It doesn't look like there's any user-visible negative effect on these pages (and I've sent an email to Quinstreet).

Olympus has 6 sites that set a `currentlang` cookie, but dropping the `<meta>` is a no-op as it's also set as an HTTP header (I suspect this is the case for a lot of these examples, actually...).

Query:

```

SELECT

  *

FROM (

  SELECT

    page,

    url,

    REGEXP_EXTRACT(LOWER(body), r'http-equiv=["\']?set-cookie["\']?[^>]+\s?content=["\']?(.+)[\'"]?') as cookie

  FROM 

    [httparchive:har.2017_09_01_chrome_requests_bodies]

) WHERE

  cookie != "null"

```

I spot-checked 20 of the other pages with different cookies set, and didn't run into any catastrophic errors like redirect loops. I can dig into that data more if it would increase your confidence. :)

Wow, that analysis must have been pretty exhausting, and I think it's quite enough already! If no serious problem are found in 182 cases you've checked, then that's already a very strong signal. Trying it may still reveal some other problem, but it seems implausible that more static analysis will be fruitful.

Agreed, this is more than enough to demonstrate that the severity of breakage is likely to be very low.  Thank you!

Can you give more detail on the security benefit?  Are there any known examples of security incidents you can point to for which this would be a mitigation?

It's bad for attackers to be able to manipulate cookies on a site, as HTTP is otherwise ~stateless. Currently, attackers can write to (but not read) cookies by injecting a `<meta>` tag, which is a lower bar than actually executing script on the origin, or modifying headers in flight. I'd like to remove this as an injection vector, both because developers don't generally know that it's possible, and don't have any mechanism of preventing it today.

That said, I don't have a specific attack at hand that this change would have prevented, but there's been weird behavior in the past (setting same-origin cookies via cross-origin SVG images, for instance) that we could collectively have avoided by not allowing markup to do scripty things. *shrug* Still, though, this aims to be a general hardening/sanity change, not one in response to a specific attack.

Makes good sense. Since compat situation looks pretty good right now, it's best to not wait until the web depends on it and a real attack is discovered! (Usage increasing after deprecation has happened, there was a funny graph at BlinkOn about that.)

Yep, agreed. 

I'm offline on my way back from Tokyo right now so can't google it, but can you suggest a good link to understand "session fixation attack"?

https://www.owasp.org/index.php/Session_fixation is a high-level overview of session fixation (and calls out `<meta>` as an injection developers can't disable). https://www.lanmaster53.com/2014/10/29/session-fixation-demystified/ is another that looks reasonable.

 

Sorry for the noob questions.  I trust your judgement, but in the spirit of making intentional tradeoffs between our blink compat principles I'd like to understand myself why the compat pain is worth the cost.

These are exactly the questions you should be asking, and tradeoffs you should be weighing! Thanks!

With positive signals from both Edge and Cloudflare, this is an easy LGTM1

+1.  

LGTM2 to deprecate AND remove (at whatever time you are comfortable with, after at least one milestone of deprecation warning)

[Chris Harrelson]

LGTM3 to deprecate and remove after a cycle or two. (Note that we don't deprecate features without removal timelines anymore.)

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-pdVLpZGv0tr1sSQ-sS1xHKCzyg84q%2BD6iRcouSwNnUg%40mail.gmail.com.