Slashdot Mirror
Cross Site Cooking
Liudvikas Bukys writes "Michal Zalewski identifies a new class of attacks on users of web applications, dubbed Cross Site Cooking.
Various browsers' implementations of restrictions on where cookies come from and where they're sent are weaker than you think. Web applications that depend on the browser enforcing much will offer many opportunities for mischief."
Unless of course you encrypt, or at least digitally sign all cookies you legitimately send.
The fact that none of the cookie meta-data is ever sent to the server along with the cookie body is one of the biggest pains. Aside from the domain restriction that the article talks about, another big one is the expiration date. This is important if the server *wants* cookies to expire, such as if used for authentication.
Thus a safe server will encode the cookie expiration date directly into the cookie value (as well as the cookie metadata), and then sign (or HMAC) the cookie value. And there's also the previously mentioned Ajax cookie stealing attacks to guard against, which usually means disabling the TRACE command or setting the secure cookie property.
Now, when the user visits evil.org it requests that a cookie called slashdot_cred be set for the site ".org." It has 2 dots in it, so it's set as a valid cookie and then next time you hit /. you'll hand over some alternate credential from evil.org.
Opportunities for exploiting this seem very limited. The only one i can think of are store affiliate programs. I know that if you visit a link that i give you for shutterstock then they'll set a cookie with my id so that i'll get the referral credit if you sign up within 30 days.
I'm not sure what goes into that cookie, but i might be able to make my own .com fake it and get credit for any signups that happen.
I love Opera.
I've got Opera set to warn me about cookies with "incorrect paths", I've been getting alot of warnings about cookies lately. (which I obviously refuse when they come up)
Should have known somthing like this was going on with all the questions about cookies & paths on Webmaster Forums awhile ago ya think ?...
Wanna fight ? Bend over, stick your head up your ass, and fight for air.
As a DNS administrator, the trailing dot is something I was very aware of (although I didn't know about the cookie implementation errors). I've always wondered why you never saw URLs such as http://www.example.com./, instead of http://www.example.com/ ? The later (without the dot) is subject to local DNS spoofing.
However, aside from the browser problems, it seems that web servers also mess up the trailing dot problem. Most servers won't recognize their own hostnames when the Host header has a trailing dot. Proxies are also clueless and confused.
In fact, I was always surprised that the HTTP and URL standards (not to even mention the horrid X.509 certificate standards) seem so careless about the canonical domain name representation. There's no requirement, nor even a warning, about any use of the trailing dot in domain names, nor that any software (server, proxy, or agent) should do any sort of canonical name equivalence checking.
How about this - some sites could implement IP validation, _IF_ you allow them too.
If I'm a paranoid, tinfoil-hat slashdot type, i could check on the "perform IP validation for a greater security" option.
About two years ago I came up with a mechanism to base session cookies off of a series of md5 hashes along with the user-agent, screen resolution, and the Class B subnet mask and wrote up a document on how it could be done. Lo and behold I find that Google must have also independently figured out a way to do this as well. They implemented something like this into their gmail cookies, making XSS attacks damn near useless unless you're a good guesser or you know what you're doing when you do the cookie stealing and actually include javascript variables and record EVERYTHING you possibly can.
The exploit "Problem #3" won't work if the "victim" is already on virtual host. In this case, the web server would not recognize that it is hosting a site for evil.example.com and show the default site (if one is configured), not the desired site. For those who did not pay a premium to get a dedicated IP web hosting, this is a non-issue.
/robots.txt (/cookies.txt) to indicate that the host "example.com" accepts cookies set by certain hosts.
In general, I think cookies should only be allowed if the domain suffix of the cookie matches the host name---so www.example.com can set cookies for www.example.com and *.www.example.com, but not uwww.example.com, *.example.com, nor *.com. If you really want to let www.example.com set cookies for *.example.com, you should run a web server on example.com and put a trampoline script there to set the cookies for you. Or you could rename additional web servers *.www.example.com so they can all access the cookies set by www.example.com.
(I mean, really, those additional web servers are part of the world wide web of that domain, so they should all fall under the www domain.)
If this is still too restrictive, I think it is also viable to use, for example, additional DNS records or something like
Users will have an incentive to use those user agents that honor additional cookie restrictions because it provides some guard against cross site scripting (cooking).
I once had a signature.
I believe I have found a really wicked attack that could utilize this method to implement a serious DDoS effect. Lets consider issue #1, where I can create cookies in .org.
/. effect having serious financial impact on Slashdots bandwidth costs.
When a user visits my site, I set 20 cookies for slashdot.org. that are 4KB in size each (maximum number for a domain, and maximum allowed size per cookie). I also set the expiration for some time far into the future. I only have to send this data to each visitor 1 time.
As a result, everytime the user goes to slashdot, he transmits 20*4KB (80KB) of data at slashdot. Not a big deal right? But what if my site is slashdot'd, and a million faithful readers visit my evil website and get this bogus cookie data. Now slashdot will be flooded with 80KB from 1,000,000 users every single time they click on any slashdot page (potentially for years). Yikes! Slashdot becomes victim of covert and malicious
This is a potentially serious amplification attack vector that would be really hard to clean-up.
--
This attack ©The Terrorist Network ( www.terrorist.net )
I'm under NDA, so pardon me while I dance a little... a certain large company with whom I have done business in the past, and which maintains a large stable of popular sites, once sent us their cookie documentation. As a partner site, we were required to play ball with this document, and I can only describe it as vile. It was a manual akin to the anarchist's cookbook, but for subverting the trust of our users. The information coming out about cookies is not "theoretical", it is practical and widely used by the largest sites.
If you don't believe me, turn on manual cookie accepting, and start visiting the largest sites on the net. Accept all cookies for just the session and see what you get. I assure you that you will see these games played, not by disreputable hackers, but by the companies that many thought they could trust. You will see your personal information (to the extent that company A has it), handed off to company B in ways that HTTP was not supposed to allow for. You will see a great many interesting things.