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."

Comments

Web developers

[mhanoh]

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!

Re:Web developers

[dasil003]

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!

Right, but hijacking a session should require at least a man-in-the-middle attack. Allowing anyone to arbitrarily grab cookies from a visitor is a pretty big gaping hole. Obviously anything requiring serious security needs SSL and/or other cryptographic measures, but for the huge number of casual websites that only need basic authentication this really throws a wrench in the works, unless you want to ask the user for their password every single time they load a page.

Re:Web developers

[ArsenneLupin]

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.

Oh, the old "the only secure machine is a machine that is switched off, thus security is a lost battle anyways, so we should not waste any precious time implementing security" canard.

Yes, statistically, all non-trivial protocols will indeed have (unknown) security holes, but that should not be an excuse to leave known security holes unpatched when they come to our attention.

We're all 100% sure that we'll die one day anyways, but nobody in their right mind uses that as an excuse to disregard safety procedures when operating heavy machinery ;-)

Of course cookies can be modified by a proxy.

... and so we should keep them modifiable by any random web site too? How about fixing one problem at a time, rather than saying "there's no point in making our banking service secure, because our customers might just get mugged in the street and lose their money anyways...".

Of course sessions can be hijacked!

You're probably right. Even after fixing the known bugs allowing session hijackings, there will still be unknown ways of doing this. But we have to start somewhere. A new method of hijacking has been shown, and suggestions to address the issue have been proposed (be more picky about Host header verification, etc.). Why not heed these suggestions, and at least plug this particular hole (even if, true enough, there are potentially zillions of other holes left...)

No site should trust client-side information.

[bigtallmofo]

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?

Re:No site should trust client-side information.

[isomeme]

This is why I so appreciate Perl's "taint checking" mode. In this mode, *all* data obtained from external sources -- http payload, env, read from a file -- is considered tainted until it's been the object of a regex pattern match, which turns off the taint bit. Tainted data cannot be used in any action that will have external effects -- writing to output streams, calling system execs, etc.

It's not perfect, of course, but it's alerted me to potential security problems dozens of times.

Nasty

[dasil003]

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.

Re:Nasty

[coolgeek]

IP Checking won't work, unless you want all your AOL-based visitors to keep getting logged out. I think some Cable users too. Basically anyone that has a proxy-cluster between their browser and your site will come from several different IPs as they surf your site.

Re:I think you misunderstand

[Anonymous Coward]

I'm wondering if you're just spam on a cookie. Slick self-promotion, there. Not sure if I should complain, or admire the way you did it.

Not THAT nasty

[sterno]

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.

Re:Not THAT nasty

[Metasquares]

There's the possibility of setting up some sort of DDoS attack by modifying cookies sent to a server in order to construct huge queries, but that means there has to be an SQL injection vulnerability on the server as well. Of course, you should validate and escape anything you put into a query from a user, whether it's a POST variable or a cookie.

Re:Not THAT nasty

[iabervon]

Maybe I give you a session where your shipping address is my house. You buy some stuff from the site, don't pay much attention, and have it shipped to me. Or I give tons of people shopping carts containing something I sell through Amazon. Some of the people don't pay attention and accidentally include my item in their next purchase. Or I create a session with a site but don't log in, and I give it to them. They use it, find they aren't logged in, log in, and I'm also logged in as them (since I'm using the same session).

Re:How Google gets around this...

[Anonymous Coward]

You are heading away from security, not towards it. A good session cookie is one that is unpredictable. That means random, not based on information the attacker could conceivably get access to like screen resolution.

Seriously, what's wrong with generating session cookies randomly that you felt the need to "fix"?

Re:The second one suprises me

[Anonymous Coward]

probably because the cookie isn't sent back (and the $_COOKIE global populated) until you reload the page.