You asked: Am I exposing potential vulnerabilities by exposing the same session cookie to all my users' subdomains?
Answer: It depends, but generally speaking, yes, you could be exposing yourself to some attacks. It depends upon what kind of content you allow on the subdomains (e.g.,
elmer.acme.com). There are two cases:
If you allow Elmer to put arbitrary HTML on the website hosted at his subdomain
elmer.acme.com, then you have a problem. Using the same session cookie on all subdomains is a security hole in this case.
The attack: A malicious Elmer could set up his site
http://elmer.acme.com/ (Elmer's site), Elmer learns Bugs Bunny's session cookie. Now Elmer can pretend to be Bugs Bunny when visiting other subdomains (including Bugs' own site). That's no good.
Generally speaking, the reason to use multiple subdomains is to isolate multiple users from each other, so that one malicious user cannot harm other users, and so that a security failure by one user does not harm other users. If that's the reason you are using multiple subdomains, then your practice of using a single session cookie on all domains is insecure and should not be used.
In other words, most folks who are using multiple subdomains are probably in the first case, and thus I would expect that in many cases where multiple subdomains are used, it is not a good idea to expose the session identifier to all subdomains.
A better approach, that doesn't have these problems: Add a login page on
acme.com. When users log in on
acme.com, give them a session cookie that is scoped to
acme.com only (no subdomains). This will be the secure session cookie.
When users visit a subdomain, you can do some tricks to authenticate them using their
acme.com-session cookie and then give them a new cookie that is specific to the subdomain, without requiring them to log in again. The backend webserver can remember the association between the subdomain-specific cookie and the secure session cookie, so the webserver will be able to manage authentication in a way that the user doesn't notice.
This way, because you are separating your cookies by domain, you get better security. If one subdomain hosts malicious content, it learns only the session identifier for that subdomain, but it doesn't learn the session cookie for
acme.com or for any other subdomains.
For instance, the secure session identifier for
acme.com might be 7a3f...90 (cookie:
SESSIONID=7a3f...90, scoped to
acme.com). The session identifier for
elmer.acme.com might be 09ac...b3 (cookie:
SUBDOMAIN_SESSIONID=09ac...b3, scoped to
elmer.acme.com), generated as SHA1(7a3f...9 || elmer.acme.com) = 09ac...b3. The session identifier for
fudd.acme.com might be f067...85 (cookie:
SUBDOMAIN_SESSIONID=f067...85, scoped to
fudd.acme.com), generated as SHA1(7a3f...9 || elmer.acme.com) = f067...85. If
elmer.acme.com is malicious, it cannot learn the secure session identifier or the session identifier for any other subdomain; it can learn the session identifier for its own subdomain, but that doesn't give Elmer any additional powers he didn't already have.
The only tricky bit is how to install these cookies onto the user's computer. I don't think it is a good user experience to ask/expect users to log in again for each subdomain they visit. Therefore, we should look for a technological solution that lets us transfer the session cookies across domains securely, without requiring the user to log in multiple times.
There are ways to achieve this, using iframes, postMessage, and/or redirection between domains. For instance, here is one approach.
elmer.acme.com can have an invisible iframe that loads
acme.com/authenticationhelper. The latter can use the secure
acme.com-session cookie to authenticate the user. Meanwhile, the
elmer.acme.com page can use postMessage to communicate to that iframe and ask it for a new session identifier that's good only for
elmer.acme.com receives this new session identifier, it can automatically set a session ID cookie that's scoped to
elmer.acme.com, and now you're good. Here a key fact about postMessage is that the recipient of such a message can verify the domain that sent the message, which prevents spoofing and malicious attacks (
acme.com can verify that it is
elmer.acme.com who is requesting a subdomain-specific session identifier and respond with the appropriate session identifier for
See the steps that Livejournal takes to protect its cookies, for an example of this sort of approach deployed in practice. You can also read about the attack that prompted them to implement this defense, to learn about the risks of doing nothing to defend against these threats.