[Xymon] Chrome cookie deprecations

[Jeremy Laidman]

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


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20180313/179a952a/attachment.html>