From: https://groups.google.com/a/chromium.org/d/msg/blink-dev/0sJ8GUJO0Dw/lZaJf43...

"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."

I imagine this makes it possible for a bad guy to post text on a forum, with embedded <meta> tags, and inject cookies into the browser of anyone who reads my message. In some contexts, browser protection ensures that any <script> code is not executed, but <meta> tags are not treated with such care. The suggested alternative is to replicate the meta tag using (JavaScript) scripting, which allows the same feature, but is constrained by context. This constraint includes things like allowing JavaScript to access (eg exfiltrate to) a different website from which the JavaScript came.

Xymon already uses JavaScript. I don't think it would be a big job to change the <meta> into the equivalent <script> tags.

J

On 13 March 2018 at 04:36, John Thurston <john.thurston at alaska.gov> wrote:

It took me a bit to figure out where you were seeing this. It wasn't evident on my default page (non-green). A simple repro is to visit the 'Info' page for any host:

https://foo.bar.com/xymon-cgi/svcstatus.sh?HOST=baz.bar.com&SERVICE=info

In Chrome, look at the 'Console' and display messages of at least "Warnings" severity. As mentioned, the warning message references: https://www.chromestatus.com/feature/6170540112871424 which further references: https://github.com/whatwg/html/pull/3011#issuecomment-331187136

So it looks to me like this change has only been in the works since late 2017. I know in the 'modern' world, this is an eternity, but to an old guy like me it seems rather abrupt. The hazard here is our users with Chrome are soon not going to cookies set. I suspect this is going to make it much more difficult to choose hosts to enable/disable/ack. What else is going to break when the cookies aren't set?

I don't understand the issue, or what business-need is driving this change in cookie-setting methods. Regardless of how little I understand the problem, as soon as my users are faced with an un-filtered list of of hosts on which they can 'ack' an alarm, they're going to be even less likely to ack anything :(

If history is any guide; as goes Chrome, so will go the rest of the world's browsers.

Can anyone tell us more about why this cookie setting behavior is being changed, and what is required to alter?

-- Do things because you should, not just because you can.

John Thurston 907-465-8591 John.Thurston at alaska.gov Department of Administration State of Alaska

On 3/7/2018 1:07 AM, Rich Jones wrote:

...

Hi all, finally getting round to posting about this...

Chrome is going to be deprecating the meta tag for setting cookies... is there a fix in the works for this? Error console throws the following:

[Deprecation] Setting cookies via <meta http-equiv='Set-Cookie' ...> is deprecated, and will stop working in M65, around March 2018. Consider switching to document.cookie = ..., or to Set-Cookie HTTP headers instead. See https://www.chromestatus.com/feature/6170540112871424 for more details.

This is showing for all pages on Xymon 4.3.28 testing through Chrome 64.0.3282.186 which I presume is caused by the following in the head

<META HTTP-EQUIV="Set-Cookie" CONTENT="pagepath=; path=/"> <META HTTP-EQUIV="Set-Cookie" CONTENT="host=; path=/">

---

Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon

---

Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon