views:

241

answers:

2

Suppose you have a webapp that gives users their own site on a subdomain (eg: awesome.super-cms.com) and that you let them edit HTML. Further assume that you're setting the SessionID in a wildcard subdomain cookie ("*.super-cms.com")

The user who manages evil.super-cms.com could easily write a JavaScript that grabs the SessionID from other super-cms.com users:

var session = $.cookie('SessionID');
// Now send `session` to evil.com

My question is: Could an attacker user these harvested SessionIDs to do bad things? For example, spoof authentication as another user?

(I realize this is a pretty newb question. I'm afraid I don't know enough about the internals of sessions to confidently answer this question myself. Please feel free to link to any reading material that might aid my understanding.)

+3  A: 

Yes, they can. This guy appears to have an article outlining examples: http://skeptikal.org/2009/11/cross-subdomain-cookie-attacks.html

You can set the domain of the cookie to prevent this. It is set as ;domain=... inside the cookie, your given language will probably have a facility to do this directly.

Noon Silk
Thanks. We're using Django, which allows you to set a SESSION_COOKIE_DOMAIN to do this. An unfortunate situation, however, because we were really hoping to keep users authenticated across subdomains.
Kyle Fox
Kyle: You can still do the authentication across domains, but just with a little bit more work (ensure all links to other domains contain a special querystring, and then validate that appropriately (it's more complicated then this, but that's the general idea, or at least something similar)). What you *don't* want, is them accessing each others cookies.
Noon Silk
A: 

Could an attacker user these harvested SessionIDs to do bad things?

Yes, but its a no-brainer to prevent this:

  • don't use wildcard cookies
  • set the http only flag on any cookies

I assume that you're running this on top of SSL (otherwise its already wide open to MITM attacks) in which case, setting the SSL only flag is a good idea too.

Note that you can't rely on the client ip address not changing (some ISPs use load-balanced proxies) mid session, but the browser headers don't change - however thats not going to help in an attack from someone who knows what they are doing.

C.

symcbean