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."
Any web developer worth their salt would be able to tell you nothing, and i mean nothing, sent or received over http should be regarded as secure.
Of course cookies can be modified by a proxy. Of course sessions can be hijacked!
A basic rule of web design is that information submitted from forms and cookies stored on a client computer should at the very least be validated before processing.
Otherwise, insecure browsers like TFA mentions are only one of your worries. What's to stop someone from modifying a cookie file with a hex editor? What's to stop someone from saving a local copy of your form and modifying it and submitting the modified form to your form processor?
I'm a big tall mofo.
Web applications that depend on the browser enforcing much will offer many opportunities for mischief.
That is true regardless of what the exact nature of the issue is. Never trust user provided input.
Expecting, not just a specific third-party program but, an entire class of programs to maintain your data integrity & overall security is sheer laziness or plain incomptence.
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.
FTFA: One can set a cookie for ".com.", then bounce the visitor to http://www.victim.com./ .
I'm thinking plugins like the one I mentioned would help a user from getting screwed like this. I'd be curious as to other methods.
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.
Well I can't say this was unexpected, nevertheless, it's pretty nasty considering that cookie trust is the standard way of keeping someone logged in. I suppose you could implement IP checking as an additional security measure, forcing wireless users to constantly re-login, but it would provide significant security improvements.
What it really goes to show is that web applications should always require a password to be entered for any 'sensitive' transactions. The definition of 'sensitive' is left as an exercise to the web developer.
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.
Yeah, that one surprised me as well, and he made it seem like modern browsers where still affected, but a simple PHP script:
<?
SetCookie("Test","Value",0,"/",".com.");
print_r($_COOKIE);
?>
Did not work in Firefox or IE6 for me, so those browsers at least, seem safe from this.
Morphing Software
Opera is the one browser that was apparently not researched, as the issues do not show there (#2) or are less severe (in case of issue #1). People sometimes complain that Opera throws a warning for (or refuses) a cookie that the other browsers happily accept. This is no error, just Opera better at following the specs like RFC 2965...
If you don't like having choices made for you, you should start making your own. - Neal Stephenson
I wrote about this a while back, warning community sites about it. That was before the MySpace chaos. Formkeys help as a basic precaution, although they may also be read and passed on by ajax techniques.
If I'm reading this correctly, it's not that bad for most websites these days. There are two exploits that I see are possible from this.
1) Pushing a hacked cookie to the client that then is transmitted to a legitimate site
2) Stealing data contained in a cookie
In the first case, this seems like an exploit of limited value. Great I can make you send the wrong data to a site, but what exactly would be the construction of this wrong data such that it would cause mischief. I can make you log into your bank as me... great... so you can log take all my money? I mean there may be some strange setup that this can be used to exploit but I should think it's a rarity.
The second case is a more disconcerting concept, but I think this is a matter of common sense security. Most sites these days use a unique user identifier in cookies and don't store real data on the client. So the cookie doesn't provide a direct way to steal the information about that user. It does permit the ability to impersonate a user, which could be nasty, but most sites that have some sort of security consideration (i.e. banks, etc) require users to authenticate each time they access the site whether they have a cookie or not.
Having said that, my impression is that neither of these is all that easy to pull off in the real world. For #1, you have to visit a corrupted site, get the corrupted cookie, then go to a site that is vulnerable to the particulars of that corrupted cookie. So when you create the page you kinda have to know what the target is and the user may never go to that target. You might pick a high profile site to increase your odds, but the higher profile, the greater the likelyhood that they'll apply some level of paranoia to such things (on average).
For #2, you not only have to get them to hit your corrupt site, and hit a valid site, then you have to have them hit your corrupt site again. Then, for this to be of value, the valid site has to engage in realtively risky behavior with the cookies. So, once again, you'll get the most bang for the buck on higher profile sites which will be more likely to double check what you're doing.
So in the grand scheme this could be bad, but isn't terribly practical from what I can gather.
This sig has been temporarily disconnected or is no longer in service
with MSN network, we (large corp) banned all of their MSN domains as this is a security risk and as its intentionally deceptive on their part we had to classify it as malicious due to the intent
here (with analysis)
news report here
of course MS still use it and the surfers still have no idea its occuring, though if you block their servers you soon find out how many times they try.
never mind trusting the user, its the server and the company that does it that people cant trust
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 )
LiveJournal is already aware of this issue, and trying to do their best to prevent said issues within their system
As far as this article goes, problems #1 and #2 are bugs in the browser, not errors with web developer's coding, I don't know why it is presented that way. The guy says "sites rely on secure browsers, but they aren't!", the site doesn't rely on the browsers being secure at all, the user does. If the user uses an insecure browser, and his cookies get stolen because of it, the site isn't damaged at all, the user is.
On top of that, he says he tested these things on MSIE and Firefox. I'm running Firefox 1.5, and it quite definitely DOES NOT work, test it for yourself, even give it a push. Turn off "for the originating site only" under cookies, and try to create a cookie with domain ".org.". It doesn't work. Run this in your address bar (on this page):
javascript:void(document.cookie="cook1=bobjones; domain=.slashdot.org");
Now look at your cookies. "slashdot.org" has "cook1" listed with value "bobjones".
Now open a new tab/window/whatever. Open "http://slashdot.org./". Let's try this "exploit":
javascript:void(document.cookie="cook2=bobjones; domain=.org.");
Look at your cookies. No cook2 under ".org", ".org.", not even "slashdot.org". The cookie just isn't set. Try this on just slashdot.org as well and it will do the same thing (or it.slashdot.org, whatever, all the same).
As far as #3 goes, I'm not quite sure what he thinks the "host" field it used for. If the site he's trying to attack is under a virtual host, which a lot of sites are, it will just discard it because the host doesn't match its table. On top of that, if they don't have a virtual host, all they would have to do is look through the packets being sent and see "Host: evil.example.com" and you're screwed.
These "attacks" either don't work or will get you busted really easily. Kids, don't try this at home.
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.