Server side verification that the domain of an issued cookie matches the host header

Question

If an application issues an authenticated user a session and gives them a cookie that should only be valid for a certain subdomain (say, because there are other customers located on other subdomains but all the subdomains resolve to the same running application) then should the server verify this cookie's intended subdomain against the host header before setting the session at the beginning of a request?

e.g.

• User successfully authenticates to client.example.com

• Server creates a new session for them and adds a property to the session about the originating domain

  {user: "fred@gmail.com", domain: "client.example.com"}

• Server sends a Set-Cookie header in the response with the session id

  Set-Cookie: secure-session-id=1234-5678; Secure

• The browser won't send that cookie if the user navigates to otherclient.example.com due to the implicit same-domain behavior of Set-Cookie
• There's nothing stopping the user from constructing a curl command with that cookie but pointed at otherclient.example.com.
• If the server doesn't validate that the host header of an incoming request matches the originating domain of the session for the provided session id in the cookie, then it's possible that a user with a valid account could masquerade as another customer (if the app bases any logic off of the subdomain instead of purely off of information gathered from the authentication). Prior to setting the user's session and continuing with the request I would expect the server to take the session id submitted, look up the session, see if the request host header matches the "originating domain" that was put on the stored session and if not then either return a 401 or redirect the user to the appropriate subdomain.

This seems like a generic enough scenario that I'd expect most server authentication frameworks to do this out of box unless you turn it off (ultimately it boils down to enforcing on the server side the same behavior that browsers are relied upon to do by default (not send session cookies for one subdomain to another subdomain). Are you aware of any that do this? Is there a better way of preventing this scenario? Am I misunderstanding anything?

Answer 1

Are you aware of any that do this?

ASP.NET has a different Application Domain per IIS application. Therefore, a session cookie from one application won't be valid on another. The only exception is if you've written a multi-tenant application that resides in the same Application Domain and you're not doing any validation on the received session cookie to ensure that the host matches the one where it was set.

PHP on the other hand will store all sessions in the session.save_path (e.g. /var/lib/php/session) and therefore a session cookie from one application would set session variables if used for another, which, as you've rightly pointed out is a security concern.

This can be remedied by overriding the session.save_path local value for each application or access host for the application.

Is there a better way of preventing this scenario?

As an additional security measure you could set the host when starting a session.

Session["host"] = HttpContext.Current.Request.ServerVariables["HTTP_HOST"];

Then validate this before any session values are used in the request. i.e. what you said in your question:

I would expect the server to take the session id submitted, look up the session, see if the request host header matches the "originating domain" that was put on the stored session and if not then either return a 401 or redirect the user to the appropriate subdomain.

If these measures aren't being done then it would be an interesting attack vector in substituting a set of session variables from one application into another that reside on the same server. Of course, if the applications are the same (e.g. multi tenanted scenario) then there would be exploits such as leveraging admin access on one host to gain admin access on another. If not, then there still may be attack paths there depending on which variables are set and how they are used.