Graylog creates a cookie on the top-level domain, instead of its subdomain

[AnnoyingTechnology]

Graylog creates two cookie. One is correctly created in .subdomain.domain.tld the other is created in .domain.tld

Expected Behavior

Graylog should not escape its subdomain.

Possible Solution

Create all cookies in the subdomain configured in server.conf

Steps to Reproduce (for bugs)

1. host graylog in a subdomain
2. observe what cookies it creates

Context

This sends a cookie to all ours applications, websites, etc. It is :

• wasteful as there is no reason for this cookie to be sent outside of the scope of graylog
• triggering WAF as this cookie contains symbols and special characters
• a security concern as this cookie contains OS Version and more sensitive stuff

Your Environment

nginx as a reverse proxy

• Graylog Version: 5.2.2-1
• Java Version: 17.0.9
• MongoDB Version: 6.0.11
• Operating System: Debian 12
• Browser version: Chromium 116

There doesn't seem to be a workaround, as the cookie is deposited using Javascript, so nginx cannot rewrite it on the fly.

[dennisoelkers]

Hey @AnnoyingTechnology,

thanks for reporting this. Just to clarify: you are talking about the first of the two cookies (the one starting with ph_phc_) which is problematic, while the authentication cookie is fine?

Edit: You are explaining that already in the first sentence, sorry.

[HenryTheSir]

Hi @AnnoyingTechnology,

if you disable telemetry globally (graylog.conf ) the cookies gets not created.

# New for 5.1 disable telemetry global for all users
telemetry_enabled = false

best regards

[AnnoyingTechnology]

Wow, that's unexpected but it checks out.

Thanks!

(still a security concern for people who don't notice and leave this enabled)

[coffee-squirrel]

Related: #15527

[dennisoelkers]

Thanks, @coffee-squirrel! I think disabling telemetry for now is a valid workaround if the overly wide cookie domain is an issue for you. I think we should try to fix that nonetheless, as we want users to have as little privacy/security issues as possible when deciding to send telemetry data, because it helps us improving the product (finding out if features are actually used, at which scale, which user flows can be streamlined, etc.). The cookie is set by the Posthog client library and it looks like they are doing this (setting it to *.domain.tld) on purpose to allow cross-domain tracking. We do not want this and it makes little sense for an on-premise product, so I hope there is a way to disable it.

[hydrapolic]

Hi @AnnoyingTechnology,

if you disable telemetry globally (graylog.conf ) the cookies gets not created.

# New for 5.1 disable telemetry global for all users
telemetry_enabled = false

best regards

Probably an other issues, but users not having telemetry disable could not connect to graylog after upgrading from 5.1 -> 5.2. Graylog is behind nginx with oauth2-proxy doing the authentication.

After setting telemetry_enabled = false they could login again. By checking the Cookie, it was very long containing special chars, so probably the processing in graylog changed for 5.2?

[dennisoelkers]

Hey @hydrapolic,

do I understand you correctly that with Graylog 5.2 you were not able to login when telemetry was enabled? What error did you see? Can you create a separate issue for this?

[hydrapolic]

Hey @hydrapolic,

do I understand you correctly that with Graylog 5.2 you were not able to login when telemetry was enabled? What error did you see? Can you create a separate issue for this?

Yes, after upgrading from Graylog 5.1 to 5.2, users were unable to login, they received error 400. My user was able to login because I had telemetry disabled previously. After setting telemetry_enabled = false globally, users were able to login.

The only difference I saw was the cookie, mine was shorter, while the users had telemetry data in the cookie. Probably the cookie processing changed in 5.2 so that it's more stricter what to accept?

Unfortunately I don't have the logs any more, but I see no errors in the graylog log from that day, just http 400 from graylog in the nginx log.

We use oauth2-proxy with Azure for password management.

[der-eismann]

We experienced the same issue as @hydrapolic, created a separate issue since the cookie broke it for us, but the domain is irrelevant here.

Regarding the actual issue here: The top-level domain cookie does not make any sense at all, since we use graylog.<environment>.example.com with multiple instances and these cookies would get mixed up constantly.

[slalomsk8er]

Just had an other web application refuse to work because the Graylog cookie under the top-level domain was to big for it to handle. Setting http_external_uri didn't help.