![Security Security](http://a.fsdn.com/sd/topics/security_64.png)
![Programming Programming](http://a.fsdn.com/sd/topics/programming_64.png)
![The Internet The Internet](http://a.fsdn.com/sd/topics/internet_64.png)
![IT IT](http://a.fsdn.com/sd/topics/it_64.png)
![Technology Technology](http://a.fsdn.com/sd/topics/technology_64.png)
Cross Site Cooking 125
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 developers (Score:5, Insightful)
Of course cookies can be modified by a proxy. Of course sessions can be hijacked!
Re:Web developers (Score:5, Interesting)
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.
Re:Web developers (Score:5, Informative)
Re:Web developers (Score:2)
"Alternatively, only drop a session tracking ID by cookie then maintain session expiry data on the server."
Indeed. I would have thought it was common sense to pass no data at all in a cookie, except a session token. I think every app I've written in the last 6 years uses cookies for session tokens only. It doesn't completely protect you from man-in-the-middle attacks hijacking a session and altering data on the server, but it does help reduce the amount of information that can be stolen. And as a general
Re:Web developers (Score:3, Informative)
Nothing critical, though; worst case scenario, the attacker makes the screen look a little funny. Whoopie.
Re:Web developers (Score:2)
And when the attacker has trained the user(s) to ignore the unexpected screen features or password prompts, then it is time to launch a "misspellled domain name" or other such attack.
Re:Web developers (Score:1)
Re:Web developers (Score:1)
If you want the cookie to expire, then put an expiration date in your cookies table. You can also send the expiration date to the browser, but be aware that some browsers allow the user to arbitrarily modify the expiration date at the browser end. You *could* encode the expiration date into the cookie, but then things start getting complicated and you end up with needlessly complex cryptographic schemes. Ba
Re:Web developers (Score:5, Insightful)
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.
Man in the middle (Score:1)
I'm starting with the man-in-the-middle,
(Man-in-the-middle -Oh yeah!)
I'm asking him to change his ways
(Better change!)
No message could have been any clearer
(If you wanna make the world a better place)
(Take a look at yourself and then make the change)
(You gotta get it right, while you got the time)
('Cause when you close your heart)
You can't close your... your mind!
(Then you close your... mind!)
Re:Web developers (Score:3, Insightful)
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
Cross Site Cooking? (Score:1, Funny)
Re:Cross Site Cooking? (Score:2)
This is slashdot.
95% of the readership believes there are two kinds of cookies... those that magically appear in mom's cupboard (or a speacial jar) and those that are generated by a webserver. How the former ones come into existance is of little consequence.
No site should trust client-side information. (Score:5, Insightful)
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 think you misunderstand (Score:5, Interesting)
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 [shutterstock.com] 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.
Re:I think you misunderstand (Score:1, Insightful)
Re:I think you misunderstand (Score:2)
That depends on how the target web site manages its authentication. Some web sites establish a session before the user supplies his credentials. This session is marked "anonymous" in the site's db, until the user is authenticated. On authentication, the (random) cookie is not updated, but only the site's database associating that cookie with a user.
An attacker could exploit this by foisting a cookie for the target site on the user. Initially, the cookie
No misunderstanding (Score:2)
Re:No misunderstanding (Score:2)
You need to emulate stateful behavior, so you have to have some way to recognize that a client has returned. Giving a cookie to the client is the only way i can think of to recongize the returning client.
Typically you make sure that you either give the client some random data that you've associated with them, or perhaps a cryptographically signed token. The idea being that that if the client modifies it then it'll be worthless.
However nothing stops the client swapping credentials
Lesson learned EARLY on... (Score:1)
Of course, everyone knows that if you just comment it out, it disappears.
Re:No site should trust client-side information. (Score:2)
Changing cookies is even easier than that in the Mozilla family of browsers, with the Add'n'edit Cookies extension [mozdev.org]. You're right that, in general, cookies should be treated like POST or GET data, which can be full of crap you, as web designer, don't want. Just like POST and GET data, it should be thoroughly cleaned if it's to be used within an SQL query or to look up a file in the filesystem. The extension, though, is a great way to deb
Re:No site should trust client-side information. (Score:3, Insightful)
It's not perfect, of course, but it's alerted me to potential security problems dozens of times.
Re:No site should trust client-side information. (Score:3, Informative)
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,
Never trust the input (Score:5, Informative)
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.
cookies insecure (Score:1, Informative)
Re:cookies insecure (Score:1)
for session id's, i think they're ok... (Score:2)
Of course, i'm all for IP validation.
Re:for session id's, i think they're ok... (Score:1)
Re:for session id's, i think they're ok... (Score:1)
Seems to me that if the user wanted to stay logged in and if the site has the functionality to remember user names/passwords by saving the information in the browser then they could easily login again...
Personally I say - validate IP's, user agent, login name, session ID and time of day ( I kill idle users )
I've also been throwing around a more secure authentication scheme: FIFO Ba
Re:for session id's, i think they're ok... (Score:1)
Re:for session id's, i think they're ok... (Score:2)
Also, persons infected with certain kinds of spyware. Which suits me just fine.
Re:for session id's, i think they're ok... (Score:1)
Unfortunately I don't have the freedom to detect AOL IP blocks and return a page saying "Hey, due to our concerns for your security, and AOLs lack of concern for your security, we can't service you until AO
Re:for session id's, i think they're ok... (Score:1)
it's certainly not our only means of authentication, but look at the two possibilities:
Use a session cookie (or, god forbid, session id in the url for web apps that MUST support non-cookied users). Trust it completely.
OR
Use a session cookie, verify it against source IP to ensure it's the same user as had initiated the session. Unfortunately this breaks for everyone coming from AOL. We can't ignore them, as they are a lot of customers. So, recognize who's co
The second one suprises me (Score:2)
The canonical DNS name problem (Score:5, Interesting)
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.
Re:The second one suprises me (Score:4, Informative)
<?
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.
Re:The second one suprises me (Score:1, Insightful)
Re:The second one suprises me (Score:2)
From what I can see, only Opera 8 is vulnerable. Firefox 1.5 and IE 6.0 both refused to show the
Work arounds.... (Score:2, Informative)
FTFA: One can set a cookie for ".com.", then bounce the visitor to http://www.victim.com./ [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.
Sorry about victim.com... (Score:1)
Re:Sorry about victim.com... (Score:1)
Opera (Score:3, Interesting)
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 ?...
Re:Opera (Score:2)
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)
But if you obviously refuse them, you could as well disable the warning!
Re:Opera (Score:1, Informative)
http://nontroppo.org/wiki/CookieSettings [nontroppo.org]
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 co
Re:Opera (Score:3, Interesting)
I've got SeaMonkey set to allow persistent cookies from sites on my whitelist, and session cookies only for other sites.
Re:Opera (Score:1)
Isn't that a Firefox extension ?
Re:Opera (Score:2, Informative)
Re:Opera (Score:1)
Finally, a Mozilla product named after somthing I've actually seen before.
Nasty (Score:3, Insightful)
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 (Score:3, Insightful)
Re:Nasty (Score:3, Funny)
Uhhhhmmmm...
Nah, it's too easy.
Seriously, good point, it just underscores the problem.
Re:Nasty (Score:2)
Re:Nasty (Score:1)
Anyone want to run a 5 minute special on CNN? *grin*
Re:Nasty (Score:1)
a) Delete the header if it already exists from the client.
b) Set the correct value for this header.
Just relying on that header if it's there is the worst possible thing you could do, as any client can add that header to say whatever they like.
Re:Nasty (Score:1)
Re:Nasty (Score:1)
You'd also have to test before you rely on this feature of a proxy that the proxies "do the right thing" if the user tries to spoof the X-FORWARDED-FOR client-side, which would presumably mean getting an account via that ISP to test, but I realise you know that already..
Much Worse than That (Score:2)
Because you know what? The only places where I stay "logged in" are the ones that I don't care about. My bank makes me log in every time I use it - fair enough. But slashdot? Who gives a rat's arse? What's worse, the main people who would implement this would be the very people for whom security should be the least concern, like the vendor m
Good idea! (Score:3, Interesting)
If I'm a paranoid, tinfoil-hat slashdot type, i could check on the "perform IP validation for a greater security" option.
Not THAT nasty (Score:3, Insightful)
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
Re:Not THAT nasty (Score:3, Insightful)
Re:Not THAT nasty (Score:2)
Re:Not THAT nasty (Score:2)
I agree, though; if you're not validating what your cookies are sending you in some way, you do likely have larger problems.
Re:Not THAT nasty (Score:1)
Re:Not THAT nasty (Score:2)
For these kinds of things, there's a far easier trick than cookies: use the injection URL (usually, a form submitted using GET action) as an image URL and put it on your site (or better, on another site with an SQL injection vulnerability...). Result: a self-refreshing SQL injection attack...
The sysadmin of the main target can remove the lovely goat man from his site as often as he wants, he keeps coming back! And each ti
Re:Not THAT nasty (Score:4, Insightful)
Re:Not THAT nasty (Score:2)
Re:Not THAT nasty (Score:2)
How would that work? You seem to assume that sites store information in a cookie. That's not how most of them do it. They generate a random md5, set that as a cookie, and save a copy in their database. A session key maps to an entire account, not to a piece of an account.
Re:Not THAT nasty (Score:2)
Most reliable sites also do an IP address check (in addition to just using the cookie-based session) to prevent against session hijacking [google.ca].
Re:Not THAT nasty (Score:1)
You seem to miss the fact that some sites do not regenerate the session cookie upon login and reuse the se
How Google gets around this... (Score:5, Interesting)
Re:How Google gets around this... (Score:1, Insightful)
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:How Google gets around this... (Score:2)
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.
If you use a keyed hash, you can get the benefit of both cookies you can check for validity and cookies that an attacker cannot guess.
Re:How Google gets around this... (Score:3, Interesting)
Cross-site cooking, maybe? ;-)
If you encode some client identifying info into the cookie, in addition to a random seed, you protect against attackers grabbing a cookie from your site, then foisting that cookie on an unsuspecting victim, and finally coming back to reap the rewards...
The client info would prevent step 2 (because the server will notice that it never handed out that cookie to the victim, and jus
Re:How Google gets around this... (Score:2)
Subnet mask is obviously non-unique.
That's not much in the way of variety there.
I guess you add some resistance to XSS, but you don't stop it entirely using that.
While you're at it, though, why didn't you include IP address?
That's a lot more unique than all of the other things you mentioned. Obviously it'll change in the case of dynamic stuff, but probably not as fast as session
Opera (Score:2, Informative)
Re:Opera (Score:1)
qz
Re:Opera (Score:3, Funny)
Formkeys (Score:2, Informative)
Microsoft have been doing this for years (Score:3, Informative)
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) [pc-help.org]
news report here [com.com]
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
maybe not as serious as it seems ... (Score:2, Interesting)
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 *.ww
Re: (Score:3)
Re:maybe not as serious as it seems ... (Score:2)
Re: (Score:2)
This can be used in DoS attacks... (Score:4, Interesting)
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 [terrorist.net] )
Re:This can be used in DoS attacks... (Score:1)
-imgunby
Re:This can be used in DoS attacks... (Score:2)
Re:This can be used in DoS attacks... (Score:1)
Re:This can be used in DoS attacks... (Score:2)
Re:This can be used in DoS attacks... (Score:1)
Re: (Score:2)
Don't Use Cookies: Most Sites Don't. (Score:1, Informative)
Only 22% of servers use cookies [securityspace.com]. The best sites work fine without them.
LiveJournal (Score:3, Informative)
I read TFA... (Score:1)
My question to the powers that be here who control cookies is why do so many site expire in 2016 or 2038?
qz
Re:I read TFA... (Score:1, Informative)
Re:I read TFA... (Score:1)
> perl -le 'print scalar localtime 2 ** 31 -1;'
Mon Jan 18 21:14:07 2038
Monday January the 18th, 2038. This is probably why they always are set to expire in 2038. Don't know about 2016.
And this explanation could be bull anyway.
Re:I read TFA... (Score:1)
Don't hit on Michal (Score:1)
An example of how to exploit this: SSO phishing. (Score:1)
It's often the case that a WAYF implementation will utilise a cookie in order to "remember" the user's home site, permitting either the selection of an appropriate default or the automatic redirection to the user's local SSO origin.
The replacement of that cookie would mean the user doesn't wind up going to their
Nothing new (Score:3, Interesting)
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.
Re:Easy solution? (Score:2)