Cenzic 232 Patent
Paid Advertising
sla.ckers.org is
ha.ckers sla.cking
Sla.ckers.org
Q and A on cross site request forgeries and breaking into sessions. It's one of the attacks that XSS enables and the attack of the future. For Session, fixations, hijacking, lockout, replay, session riding etc.... 
Go to Topic: PreviousNext
Go to: Forum ListMessage ListNew TopicSearchLog In
Cross-subdomain Cookies
Posted by: clayfox
Date: June 12, 2009 04:27PM

I think this area of the message board is the most focused on the Same Origin Policy, so I'll put this post here even though it isn't related to sessions (necessarily).

Cookies are used in many ways: storing session credentials, presentation specific information or switches, and data that affects the functionality of the web app. For large domains that attempt to silo different areas in different subdomains there are many issues that arise such as potential domain escalation via javascript. Another attack surface that most scanners miss (that's a random assumption of mine) and may not be as obvious is cookies.

Consider the following scenario. We have two sister domains: A.example.com and B.example.com. A.example.com needs to be very secure but B.example.com has no sensitive data and has been deemed less important to secure. B.example.com has an XSS hole.

A few facts about cookies should be stated. There are two HTTP headers involved with cookies: the Set-Cookie response header and the Cookie request header. The Set-Cookie response header sets the name and value, domain, path, and a few extra switches. The domain must be the same as the response domain or any superdomain up to one level below .com or .edu, etc. So a response from B.example.com could set a cookie for .example.com. The Cookie request header contains only the name and value of the cookie, and this is the header that is sent to the server. Cookies are sent to all subdomains of the domain they are defined for, so a cookie for .example.com will be sent with requests to A.example.com and B.example.com.

Several cookie-based attacks on A.example.com may now be possible. Session fixation is the most prominent one that comes to mind. Also header injections, although current browsers seem to stop this in my research. Rare XSS holes might appear that weren't expected. Any functionality that relies on cookies is now at risk as well.

This is just a list of the first attacks that came to mind. What nefarious ideas come to you lot? Also, this just seems like how the internet works. I don't know if this is a problem or if it is how it should be addressed and by whom.

-clayfox

Options: ReplyQuote
Re: Cross-subdomain Cookies
Posted by: rvdh
Date: June 12, 2009 05:21PM

Yes, it's important to restrict paths when setting cookies -if- you propagate more than one sub domain, for this very reason.

However I don't agree that cookie authentication is at risk per se, because it all depends on it's implementation and proper caution on coding web applications, and it's risk thereof. Thus, it isn't a risk in it's own league but only the coders malpractice that determines the vulnerability.

Options: ReplyQuote
Re: Cross-subdomain Cookies
Posted by: clayfox
Date: June 13, 2009 01:24PM

Path restriction:
In this context (cross-subdomain cookie attacks), why is path restriction important? Cookies can be overwritten and multiple ones with the same name can be stored as long as certain other parameters are different. I would think things like path and domain restriction, httponly, and secure flags are not important for two reasons. First, we aren't attempting to access currently stored cookies. Second, in the Cookie request header, only the name and value of the cookies are sent, not the path, domain, or any flags.

Cookie Authentication not at risk:
You are definitely correct that cookie based session fixation attacks are only exploitable when there is vulnerable authentication code involved. However, in order to exploit that vulnerable code without cross-subdomain cookies, one must be able to find an XSS or header injection hole (are there other ways I am leaving out?) in A.example.com in order to store a cookie on another user's browser. If A.example.com is extremely well secured, that might not be a reasonable task. This task can be made easier by a not-too-well secured sister domain. Yes, the hole wouldn't be there if the coder didn't introduce it in the first place. But no, it is not _only_ the coders malpractice that determines the vulnerability. There is an element of violation of the Same Origin Policy going on here also. Buzzword: Defense in depth (sorry about the appeal to buzzwords, I hate buzzwords).

I have not found any way to store a cookie for the domain I am attacking without being in some super, sub, or sisterdomain. Perhaps there are other methods involving DNS tricks to get around the browser restrictions on this? If it was possible to store a cookie on A.example.com from evil.com, then I would agree that this version of session fixation is a convolution using sisterdomains.

Thanks for the input. I can't find many people that are interested in hashing through these ideas other than here.

-clayfox

Options: ReplyQuote
Re: Cross-subdomain Cookies
Posted by: rvdh
Date: June 16, 2009 03:14PM

Of course, that totally goes without mentioning actually. Which is exactly what I did otherwise I got accused for being a smart-ass. But that again requires one to find a browser vulnerability, but if you got such a vulnerability you can code as secure as you like, it won't stop an attack.

Options: ReplyQuote
Re: Cross-subdomain Cookies
Posted by: clayfox
Date: June 17, 2009 01:18PM

Here are some questions I have about cookies. Apparently what I'm talking about is more widely known as Cross-site cooking.

domain=
Jo Hermans for Mozilla went through the process of creating a file defining how many dots different domain suffixes required (things like .blah.com or .blah.co.uk). What about directly accessing IPs? If site1 has IP 1.2.3.4 and site2 has IP 2.2.3.4 can there be cases of Cross-site cooking?

path=
Here you are not restricted strictly to sub or super paths. If your scripts path is in /foo/bar, you can set a cookie for /foo/baz, or for /random/anything. For /foo/bar should it be restricted to /, /foo, /foo/bar, or /foo/bar/anything?

-clayfox

Options: ReplyQuote
Re: Cross-subdomain Cookies
Posted by: kuza55
Date: July 16, 2009 08:28AM

clayfox Wrote:
-------------------------------------------------------
> Here are some questions I have about cookies.
> Apparently what I'm talking about is more widely
> known as Cross-site cooking.
>
> domain=
> Jo Hermans for Mozilla went through the process of
> creating a file defining how many dots different
> domain suffixes required (things like .blah.com or
> .blah.co.uk). What about directly accessing IPs?
> If site1 has IP 1.2.3.4 and site2 has IP 2.2.3.4
> can there be cases of Cross-site cooking?

Possibly, but sending cookies to an IP is usually pointless, and while I haven't tested this, I recall that when I went through the Firefox source when investigating this last year, there were specific protections to stop this happening. Of course IE, etc, could have different behaviours, but that brings me back to the fact that I can't really see the point of sending an arbitrary cookie to an IP as there are very few sites people can only access by IP which have cookie-based auth (home routers maybe).

I made some notes on the subject here: http://kuza55.blogspot.com/2008/02/understanding-cookie-security.html (Depending on how much you cbf reading, I've played quite a bit with cookies to exploit various scenarios: http://kuza55.blogspot.com/search?q=cookie )

Also, in mythical ages past (until late 2007), you could use Flash to send cookies by simply adding a cookie header to a request.

----------------------------------------------------------
Don't forget our IRC: irc://irc.irchighway.net/#slackers
[kuza55.blogspot.com]

Options: ReplyQuote
Re: Cross-subdomain Cookies
Posted by: clayfox
Date: July 17, 2009 01:21PM

Did the flash exploit add the "Set-Cookie" header to the response?! That would have been a global header injection attack, like the old global XSS attack on PDFs.

Thanks for that article. It answered a lot of my questions specifically about browser cookie limits, what parts of the spec browsers don't enforce, and which cookie a browser will use in a conflict.

-clayfox

Options: ReplyQuote
Re: Cross-subdomain Cookies
Posted by: kuza55
Date: July 18, 2009 07:00AM

clayfox Wrote:
-------------------------------------------------------
> Did the flash exploit add the "Set-Cookie" header
> to the response?!

Nah, it didn't, it just let you send Cookie headers along with your requests: http://www.webappsec.org/lists/websecurity/archive/2006-07/msg00069.html

With some tweaking, being able to send headers still works, however there is a blacklist of headers you cannot send that I don't know any bypasses for: http://kb2.adobe.com/cps/403/kb403030.html

----------------------------------------------------------
Don't forget our IRC: irc://irc.irchighway.net/#slackers
[kuza55.blogspot.com]

Options: ReplyQuote


Sorry, only registered users may post in this forum.