Cookie `experimentation_subject_id` shouldn't be set for subdomains
Summary
The cookie experimentation_subject_id
is set with ; domain=.<top-level-domain>;
. This causes the cookie to be considered as a valid cookie for all subdomains of that organization, which is probably rarely a problem. However, if you run intrusion detection software on your firewall this may cause false alerts.
- The
domain=
option should be omitted to tie the cookie only to the domain of the emitting service. - If this is not possible the entire domain name (not only the TLD) should be used for
domain=
.
Steps to reproduce
- Browse to a GitLab instance running on a subdomain.
- Inspect the cookies the GitLab set; all of them have "domain" set the the full domain, only
experimentation_subject_id
has "domain" set to.<toplevel.domain>
. - Browse to another service running on a subdomain of the same domain.
- Inspect the cookies that service set; the
experimentation_subject_id
is there too and has "domain" set to.<toplevel.domain>
.
What is the current bug behavior?
- The cookie is set for all subdomains of the top-level domain that GitLab is running on.
What is the expected correct behavior?
- The cookie should not be sent to services running on subdomains other than those GitLab explicitly needs them for.
Possible fixes
Most probably, domain: all
needs to be removed from the cookies.permanent.signed
dictionary in set_experimentation_subject_id_cookie.
- Other potentially related source code locations
Edited by Peter Bittner