search

Graylog2 / graylog2-server

Free and open log management
https://www.graylog.org
Other
7.38k stars 1.06k forks source link

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

Open AnnoyingTechnology opened 10 months ago

AnnoyingTechnology commented 10 months ago

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 :

Your Environment

nginx as a reverse proxy

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

Screenshot from 2023-12-19 11-28-22

dennisoelkers commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

Related: #15527

dennisoelkers commented 10 months ago

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 commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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 commented 2 months ago

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.