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."
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.
Wasn't this demonstrated when some guy managed to steal a bunch of passwords stored in cookies. It would grab the cookie when they visited his site and he would look through them and access accounts accordingly. I think this happened on a social netowrking site (myspace?)
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.
Alternatively, only drop a session tracking ID by cookie then maintain session expiry data on the server. With this it's possible to also do things like hostmask matching, so if the hostmask of the machine sending the session doesn't match one on the database, the password can be asked for again as verification.
How many people can read hex if only you and dead people can read hex?
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.
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
Only 22% of servers use cookies. The best sites work fine without them.
LiveJournal is already aware of this issue, and trying to do their best to prevent said issues within their system
The Incorrect Paths thing is handy, but I refer you here:
http://nontroppo.org/wiki/CookieSettings
I would never have worked out Opera's cookie handling without this. Now, it works nicely.
Clear out all your old cookies. Set Opera to accept anything. Go to all the sites you trust and log in and out. Then set your cookies to Normal: Treat as specified in Server Manager; Third-Party: Accept All.
Do a quick review[1] to be sure there's nothing unwanted left in the list. Opera stops bothering you about crap cookies, because Server Manager just denies them right away, but all those junky sites (eBay, for one) that seem to need your blood group and mother's maiden name, in a cookie that goes across a hundred servers, actually work.
'Course, a Hosts file that blocks many of their affiliates is never a bad idea either.
AC
[1] Quick is a complete lie. Opera has a funny approach to displaying the cookie list. You'll find you need to close it and reopen it to populate it, and after deleting one cookie, it weirdly decides to hide some others. So you close, reopen and delete, lather, rinse, and repeat. You'll get there.
I also use cookies for display preferences which might reasonable change from browser-to-browser or host-to-host for the same user.
Nothing critical, though; worst case scenario, the attacker makes the screen look a little funny. Whoopie.
Do daemons dream of electric sleep()?
SeaMonkey (don't download the beta just yet - 1.0 is shipping in a matter of hours!)
My server
Because that's the latest they can.
Except that this only allows you to protect against lack of datavalidation/escaping bugs (SQL injection, etc.), not against this attack.
The cookie planted by the attacker looks legit at first glance (the attacker may very well have gotten it from your site in the first place, before foisting it on an unsuspecting victim). The problem lies not in the cookie's contents, but on the fact that that content is known by a third party in addition to the victim. No amount of taint-checking will reveal this.