From:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/0sJ8GUJO0Dw/lZaJf43tBAAJ
"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
▸ quoted from John Thurston
On 13 March 2018 at 04:36, John Thurston <user-ce4d79d99bab@xymon.invalid> 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 XXX-XXX-XXXX
user-ce4d79d99bab@xymon.invalid
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=/">