Closed shpendk closed 7 years ago
I feel pretty strongly about having this classified as P5 as this is a feature and should not be seen as a vulnerability. Session cookies may be shared across subdomains by design. I do agree that this type of setup might sometimes be unintended and would like to see it classified as P5 best practices/informational, in case of potential subdomain takeover. We should also be looking into how IE and Edge handle cookies across subdomains before making any decisions: https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/8183708/
Trying to make my case a little stronger: If a session cookie is sent to ALL subdomains, it takes only one XSS on any the subdomains to compromise it and take over the account. I feel like this is the same level as missing httponly/secure flags for session cookies.
Thanks @plr0man for your answer.
As @plr0man said this might be intended. For XSS on any the subdomains
, the issue is XSS and not the scope of the cookie. For session cookies, it would be worth to ping the client and ask what is their take on this.
I can definitely see your point on this one Shpend, but I think most clients will push back and view this as intentional behavior. I do agree with Vishal's point of the real issue being the XSS. Maybe take it case by case with a max of P4?
I totally agree @shpendk that it is the same level as missing HTTPOnly cookie flag (P4). I would go even one step further and apply the HTTPOnly variant in this case. If however a cookie does have the HTTPOnly flag set, then it is not accessible from the DOM and XSS is not a threat.
You're right. With httponly set (which we have p4), the only real risk is subdomain takeover. I do think scoping a session cookie to all subdomains is bad. yes the XSS is a subdomain problem, but the impact immediately increases if the session cookie is scoped to it.
I guess what i'm trying to say is that if the session cookie is scoped to all subdomains, you gotta secure all of them as good as the main domain, which is not immediately obvious.
Do we want to add this as a P5 variant? If not, i'll close the issue. Thanks guys !
After doing some checks it seems like IE and Edge are fixed and scope cookies like any other browser. So to conclude, if an application sets the domain for a cookie, it does not matter if it's '.domain.com' or 'domain.com' that cookie will be accessible to all subdomains. That is according to RFC 6265 and confirmed by my tests on various browsers. If however the domain is not set, so by default, the cookie will be a host only cookie, meaning accessible explicitly to the domain from which it was set. It may happen that an inexperienced developer instead of not setting the cookie's domain will set it to 'domain.com' and therefore make it accessible to all subdomains.
As far as I know there is no way to set a cookie to a particular subdomain (from the main domain) over HTTP (correct me if I'm wrong), so if a developer needs to send a cookie to just one subdomain it will have to be scoped to all subdomains.
We should definitely record our conclusions in the VRT especially considering the potential of the Informative state. I am proposing Server Security Misconfiguration->Overly Broad Sensitive (or Session?) Cookie Domain
(P5)
I also agree that using a top level domain cookie many times can be by design.
Consider any implementation of the Single-Sign-On (SSO) feature across multiple websites (eg. google, gmail, youtube, google drive etc.). So the SSO functionality uses a top level domain cookie to indicate to any of its subdomains that the user is authenticated already (so it won't be asked to login again).
However, this cookie should definitively has HTTPOnly
flag set (potentially the secure
flag as well). So I would say if there is such a cookie with missing HTTPOnly
flag, it would be a P4 (which we already have in VRT). While, we can add a new one like:
Server Security Misconfiguration->Top Level Domain Cookie (P5)
@plr0man By RFC 6265, you cannot set cookies for a specific subdomain from the parent domain. The browser will accept cookies for a subdomain only if it was set from the same subdomain.
For example, the user agent will accept a cookie with a Domain attribute of "example.com" or of "foo.example.com" from foo.example.com, but the user agent will not accept a cookie with a Domain attribute of "bar.example.com" or of "baz.foo.example.com".
Thanks for your input @trimkadriu. I mentioned IE and Edge earlier since they didn't follow RFC's for a good while. Looks like they are up to best standards now in this regard.
Seems like we have a general consensus on priority and it's a matter of finding the right entry name. @trimkadriu is there any particular reason why you would prefer Top Level Domain Cookie
over Overly Broad Session Cookie Domain
? Top Level Domain Cookie
doesn't seem to indicate clearly enough what the problem is
Hey @plr0man thanks for your comment. I was thinking for Top Level Domain Cookie
(or TLD Session-Cookie) name only because of the terminology used. Yet, I agree with you that this may not clearly indicate the issue itself. In the other hand, the "Overly Broad" part also sounds kind of confusing to me. However, maybe others may have another suggestion?
"Server Security Misconfiguration->Top Level Domain Cookie (P5)" looks like the most direct way to name this.
+1 for Cookie scope to parent domain
+2 for "Cookie scoped to parent domain"
Cookie scoped to parent domain
it is.
Implemented in #23
I suggest that we create a new entry, for issues that report cookies scoped to
.target.com
, and effectively being made available to all subdomains. I'd suggest we make two variants session cookies -> P4 and rewardable non-session cookies -> P5 and non-rewardable.The reason this is rewardable for session cookies, is due to the fact that if a subdomain occurs, the attacker can read the session cookie on that subdomain, and effectively take over all logged in accounts that browse that subdomain.
Thoughts?