Cross Site Cooking

Web developers by mhanoh · 2006-01-30 11:11 · Score: 5, Insightful

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 by dmeranda · 2006-01-30 11:21 · Score: 5, Interesting

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.
Re:Web developers by dasil003 · 2006-01-30 11:33 · Score: 5, Insightful

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 by jacksonj04 · 2006-01-30 11:42 · Score: 5, Informative

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?
Re:Web developers by grcumb · 2006-01-30 12:08 · Score: 1

"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 rule, of course, if you're doing anything that's in any way sensitive, you should be encrypting the traffic anyway.

--
Crumb's Corollary: Never bring a knife to a bun fight.
Re:Web developers by multipartmixed · 2006-01-30 12:59 · Score: 2, Informative

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()?
Re:Web developers by rnpg1014 · 2006-01-30 14:21 · Score: 1

While this is a possible alternative, excessive database calls every time one loads a page for multiple users many times a day could bring a server to its knees. This of course only applies to MySQL or Oracle and other third party database applications that take up large ammounts of CPU. It might be preferable to place this information in a flat database text file in a directory inacessible via the web for example: /inacessiblefolderwithsomesalttomakesureitssafe123 4554321/cookies.txt instead of /public_html/inacessiblefolderwithsomesalttomakesu reitssafe1234554321/cookies.txt

Secured sessions are another option, but they cost some extra money on shared hosts. Digitally signing cookies are definitely a must.

As an off-topic but security / cookie related note, while researching PGP Keys for this reply I performed a google search for "pgp key cookies" (without the quotations in the search) and I was offered an unkwown security certificate from www.lokmail.net, an allegedly "secure" email site with a certificate signed by "unknown authority". A bit ironic methinks.

--
- Nick
Re:Web developers by ArsenneLupin · 2006-01-30 22:49 · Score: 2, Insightful

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...)
Re:Web developers by ultranova · 2006-01-30 23:32 · Score: 1

Nothing critical, though; worst case scenario, the attacker makes the screen look a little funny. Whoopie.

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.

--
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
Re:Web developers by jonadab · 2006-01-31 17:17 · Score: 1

> This is important if the server *wants* cookies to expire, such as if used for authentication.

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. Bah. Needless complexity is a root of all kinds of evil. KISS. Put the expiration date in the cookies table. You need to do that anyway, so that a daemon can periodically delete expired records from the table. Otherwise the cookie table grows without bounds.

The cookies table really only needs four fields: token, expiration, clientip, and either userid or sessionid. The magic token itself (i.e., the string you send to the browser and have it send back to you) can be the primary key. The client's IP address is needed only if the cookie is to be limited to that IP (otherwise can be null), and either a session ID (if you allow anonymous sessions, e.g., in a "shopping cart" scenario wherein the user might do things you'll want to remember before identifying himself) or a user ID (if you hand out the cookie on login). Some rare scenarios might want both sessionid and userid fields, but usually only one of them should be required. Anything else you need to remember can be in another table keyed on the sessionid or userid value.

--
Cut that out, or I will ship you to Norilsk in a box.

Cross Site Cooking? by Anonymous Coward · 2006-01-30 11:12 · Score: 1, Funny

Don't you bake cookies?

Re:Cross Site Cooking? by Anonymous Coward · 2006-01-30 12:28 · Score: 0

Yes. That is a very astute observation. I don't know why you got modded down.
Re:Cross Site Cooking? by JourneymanMereel · 2006-01-31 01:34 · Score: 1

Reminder:
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.

--
Life has many choices. Eternity has two. What's yours?

No site should trust client-side information. by bigtallmofo · 2006-01-30 11:14 · Score: 5, Insightful

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.

Re:No site should trust client-side information. by courtarro · 2006-01-30 12:23 · Score: 1

What's to stop someone from modifying a cookie file with a hex editor?
Changing cookies is even easier than that in the Mozilla family of browsers, with the Add'n'edit Cookies extension. 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 debug problems related to cookies.
Re:No site should trust client-side information. by isomeme · 2006-01-30 12:58 · Score: 2, Insightful

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.

--
When all you have is a hammer, everything looks like a skull.
Re:No site should trust client-side information. by zcat_NZ · 2006-01-30 14:20 · Score: 0, Redundant

God God.

We don't have Trusted Computing, and hopefully we never will. Everything sent by the client can be modified, tampered with, or stuffed with bogus data. Trust no-one. Verify everything. And don't store anything client-side other than a randomly generated number that tells you who to look up in your server-side database.

--
455fe10422ca29c4933f95052b792ab2
Re:No site should trust client-side information. by ArsenneLupin · 2006-01-30 23:03 · Score: 2, Informative

This is why I so appreciate Perl's "taint checking" mode. In this mode, *all* data obtained from external sources ... is considered tainted
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.

Never trust the input by MyNymWasTaken · 2006-01-30 11:14 · Score: 5, Informative

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.

Nothing new, nothing correct by Anonymous Coward · 2006-01-30 11:14 · Score: 0

If you still don't get it: The problem is that the browsers are doing it correctly (read: RFC-conformant and logically correct) and the domain controllers who deliberately misuse a real domain as something-like-TLD are the ones to blame.

cookies insecure by amazon10x · 2006-01-30 11:16 · Score: 1, Informative

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?)

Re:cookies insecure by amazon10x · 2006-01-30 11:39 · Score: 1

I found a link about this with LiveJournal. Bantown members said they created hundreds of dummy member accounts featuring Web links that used the Javascript flaws to steal "cookies" (small text files on a Web-browsing computer that can be used to identify the user) from people who clicked on the links. Armed with those cookies, the hackers were then able to either log in as the victim, or arbitrarily post or delete entries on the victim's personal page.

I think you misunderstand by grahamsz · 2006-01-30 11:22 · Score: 4, Interesting

Say you give some 64 byte randomly generated credential to the user as the cookie slashdot_cred. You store that in your database against their account, and then when they return that string you "know" that you've reached them. Typically that cookie is scoped to ".slashdot.org" so it can be read on it.slashdot.org and games.slashdot.org.

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.

Re:I think you misunderstand by Anonymous Coward · 2006-01-30 11:41 · Score: 1, Insightful

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.
Re:I think you misunderstand by ArsenneLupin · 2006-01-30 22:58 · Score: 1

Opportunities for exploiting this seem very limited.
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 would be worthless. But, if then the user logs in some times later, and supplies his credentials, the cookie suddenly becomes valuable.
It's a little bit like the old "browse a stack of gift cards at a shop, and carefully note their serial numbers". Initially, those numbers are not valuable (as the cards only get a value when paid for by a customer). However, after waiting for a couple of days, the card (which is still in the rack) will get bought, and the number will obtain value!
One fix is to always assign a new cookie when the client's authentication state changes.
Another possible fix would be to encode the client's IP in the (cryptographically signed) cookie: a cookie would only be considered valid if it matches the IP. However, this might be annoying to customers sitting behind a cluster of proxies, such that there IP might legitimately change during the session.

The second one suprises me by inio · 2006-01-30 11:22 · Score: 1

Of the three points, the middle (trailing dots on domain names) is the only one I hadn't considered already, as I thought browsers were smart enough to avoid it. Is there a list of browsers actually affected by it somewhere?

Re:The second one suprises me by Ark42 · 2006-01-30 11:49 · Score: 3, Informative

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
Re:The second one suprises me by Anonymous Coward · 2006-01-30 12:45 · Score: 1, Insightful

probably because the cookie isn't sent back (and the $_COOKIE global populated) until you reload the page.
Re:The second one suprises me by Anonymous Coward · 2006-01-30 15:10 · Score: 0

Oh please, you really think nobody realizes that, the test involves visiting the same page twice in a row, and if you change the domain name from ".com." to your actual domain name, visiting the page twice will actually display the cookie value, unlike when the domain name is just ".com.".
Re:The second one suprises me by Anonymous Coward · 2006-01-31 03:52 · Score: 0

You probably weren't viewing http://yoursite.com./, but http://yoursite.com/ instead.
Re:The second one suprises me by Ark42 · 2006-01-31 06:14 · Score: 1

Nope, I tried it with and without the dot, and couldn't get a cookie set for ".com." ever. See for yourself at http://ark42.com./mozilla/cookietest/test1.php

From what I can see, only Opera 8 is vulnerable. Firefox 1.5 and IE 6.0 both refused to show the .com. cookie ever.

--
Morphing Software
Re:The second one suprises me by Anonymous Coward · 2006-02-01 07:40 · Score: 0

Opera with default settings goes:
This page wishes to set the cookie com="bad+cookie" This value will only be sent to documents on the server ark42.com., and paths that are starting in /. The cookie will be deleted when Opera is closed. ---------------------- Full cookie request: com=bad+cookie; path=/; domain=.com.

Work arounds.... by IAAP · 2006-01-30 11:22 · Score: 2, Informative

The Firefox extension: "SpoofStick" can help - I think.

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.

Opera by Joebert · 2006-01-30 11:23 · Score: 3, Interesting

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.

Re:Opera by sploxx · 2006-01-30 12:23 · Score: 1

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)
But if you obviously refuse them, you could as well disable the warning! :)
Re:Opera by Joebert · 2006-01-30 12:32 · Score: 0

But then I wouldn't know there's a problem.
I like warnings, if you rely on technology TOO much, eventually you're going to get burned. ;)

--
Wanna fight ? Bend over, stick your head up your ass, and fight for air.
Re:Opera by Anonymous Coward · 2006-01-30 12:49 · Score: 1, Informative

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.
Re:Opera by CTho9305 · 2006-01-30 13:33 · Score: 2, Interesting

I love SeaMonkey.

I've got SeaMonkey set to allow persistent cookies from sites on my whitelist, and session cookies only for other sites.

--
My server
Re:Opera by Joebert · 2006-01-30 13:40 · Score: 1

What is Seamonkey ?
Isn't that a Firefox extension ?

--
Wanna fight ? Bend over, stick your head up your ass, and fight for air.
Re:Opera by CTho9305 · 2006-01-30 14:28 · Score: 2, Informative

SeaMonkey (don't download the beta just yet - 1.0 is shipping in a matter of hours!)

--
My server
Re:Opera by Joebert · 2006-01-30 14:38 · Score: 1

Thankyou CTho9305. :)

Finally, a Mozilla product named after somthing I've actually seen before. :P

--
Wanna fight ? Bend over, stick your head up your ass, and fight for air.
Re:Opera by qzulla · 2006-01-30 16:41 · Score: 1

I have FF set to ask me about all cookies. It is not that hard to accept/deny and it is interesting to see the common tracker cookies across many sites.

qz
Re:Opera by mrdaveb · 2006-01-30 19:10 · Score: 2, Funny

Kryten: RFC Directive 2965 'No officer above the rank of mess sergeant is permitted to go into combat with pierced nipples'. Sorry sir, I fail to see the relevance

--
Homme petit d'homme petit, s'attend, n'avale

Nasty by dasil003 · 2006-01-30 11:23 · Score: 2, Insightful

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 by coolgeek · 2006-01-30 11:33 · Score: 2, Insightful

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.

--

cat /dev/null >sig
Re:Nasty by dasil003 · 2006-01-30 11:40 · Score: 2, Funny

...unless you want all your AOL-based visitors to keep getting logged out.

Uhhhhmmmm...

Nah, it's too easy.

Seriously, good point, it just underscores the problem.
Re:Nasty by analogueblue · 2006-01-30 14:21 · Score: 1

If only people consistently set the X-FORWARDED-FOR header when proxying requests. AOL doesn't. A fair number of folks do, but AOL is such a large customer base, that business-wise we can't exclude them. I'd love to get the message out to AOL users that despite AOLs advertisements about being all about your security, their refusal to implement a simple feature in their proxies, reduces the security of just about every e-commerce site online.

Anyone want to run a 5 minute special on CNN? *grin*
Re:Nasty by coolgeek · 2006-01-30 18:57 · Score: 1

=) yeah I knew I was stepping in front of the train when I wrote that...

--

cat /dev/null >sig
Re:Nasty by welsh+git · 2006-01-31 01:16 · Score: 1

Of course, you could ONLY accept the X-FORWARDED-FOR header for *known* 'safe' 'official' proxies, that are known to:

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.

--
Sig out of date
Re:Nasty by analogueblue · 2006-01-31 04:21 · Score: 1

Sure, but in the case of AOL, their proxies are a nice published list, so that's very doable. And frankly it's better than not being able to do any IP validation. It isn't perfect, but it raises the bar from simple link or cookie thieves.
Re:Nasty by welsh+git · 2006-01-31 04:37 · Score: 1

Yeah, I'm not disagreeing with you.. Just clarifying in case anyone read your post and said "ooh, that's a good idea, I'll start parsing X-FORWARDED-FOR" if it exists.

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

--
Sig out of date

Sorry about victim.com... by IAAP · 2006-01-30 11:24 · Score: 1

I forgot /. scripts will automtically put a link in if you have "http://blah-blah.com" in your post.

Re:Sorry about victim.com... by bobbyjack · 2006-01-30 12:02 · Score: 1

http://www.example.com/
Re:Sorry about victim.com... by Anonymous Coward · 2006-01-30 12:07 · Score: 0

Cool!
I Am not A Penis

The canonical DNS name problem by dmeranda · 2006-01-30 11:29 · Score: 5, Interesting

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.

Perhaps browser developers... by Anonymous Coward · 2006-01-30 11:31 · Score: 0

ought to focus on beefing up existing features rather than adding new cross domain holes

Good idea! by Spy+der+Mann · 2006-01-30 11:33 · Score: 2, Interesting

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.

Lesson learned EARLY on... by mistergin.net · 2006-01-30 11:44 · Score: 1

Or at least I hope it is. Devs definitely need to set up server-side security for this reason. You can't get them all, especially if they REALLY want in, but you can at least do your best on the client side.

Of course, everyone knows that if you just comment it out, it disappears. :o

--
Less Talk. More Stab.

for session id's, i think they're ok... by Spy+der+Mann · 2006-01-30 11:45 · Score: 1

after all, using cookies is MUCH better than storing the sID in the query string :-S

Of course, i'm all for IP validation.

Re:for session id's, i think they're ok... by amazon10x · 2006-01-30 11:48 · Score: 1

The problem with IP validation is the people on dial-up get different IPs all the time (some DSL/Cable users get different ones too). Therefore, the IP would not validate and they would have to login everytime they disconnect.
Re:for session id's, i think they're ok... by Ceribia · 2006-01-30 12:24 · Score: 1

As handy as IP validation is for the most part, it does make your site useless to any one working through a constantly changing proxy. A small audience, but still considerable.

--
It has yet to be proven that intelligence has any survival value. Arthur C. Clarke (1917 - )
Re:for session id's, i think they're ok... by multipartmixed · 2006-01-30 13:01 · Score: 1

AOL being a prime example here (unless they have changed in the last few years).

Also, persons infected with certain kinds of spyware. Which suits me just fine.

--

Do daemons dream of electric sleep()?
Re:for session id's, i think they're ok... by rabeldable · 2006-01-30 13:55 · Score: 1

and whats the problem with forcing the user to login to a website again after the disconnect from the internet and get a new IP?

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 Based Authentication

Secure pages that normally require logins still require a login, however, when a user accesses a page that they normally do not access or if they access a particular aspect of the web based app that they normally do not access - then they get a login page or capthcha depending on the content!

I also thought about validating: source tcp port, OS, and reverse DNS.
Re:for session id's, i think they're ok... by analogueblue · 2006-01-30 14:16 · Score: 1

It's still very much a problem. It wouldn't even be so bad if they set the X-FORWARDED-FOR header correctly, but they don't. I've contacted them about it, in my role as security architect for a very large company, but the response was basically "Yes, we know about it. No, we aren't going to fix it."

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 AOL fixes their proxies. Please contact them here...." but hey, that would be nice:)
Re:for session id's, i think they're ok... by Anonymous Coward · 2006-01-30 16:56 · Score: 0

Did AOL force users thru their proxy-cache thing that meant their IP changed all the time? If memory serves, in the web access log, there'd be one IP for the parent HTML file, and then various IP addresses for the linked images, CSS, etc files!

Apart from that, I'm all for IP checking too, but I'm not sure that you can count on the user having a sensible ISP!
Re:for session id's, i think they're ok... by Anonymous Coward · 2006-01-30 22:27 · Score: 0

It wouldn't even be so bad if they set the X-FORWARDED-FOR header correctly, but they don't. I've contacted them about it, in my role as security architect for a very large company

Let me get this straight... you reckon you are a "security architect for a very large company"... and yet you'd trust the X-Forwarded-For header, supplied by the client?

Please resign. Now.
Re:for session id's, i think they're ok... by analogueblue · 2006-01-31 05:38 · Score: 1

I hate responding to cowards, but hey:
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 coming from AOL, based on their source IP matching the AOL proxy IP list, and if they're coming through AOL, use forwarded-for to ensure that the forwarded-for source ip is consistent through out the session.

Is that fool proof? Nope. Is it significantly better than option A? You bet!
We all know that you can't totally trust ANY data sent from the client. It's just a matter of making things as secure as you can and still serve your customers. Raising the barrier of entry to a point where it's more trouble than it's worth. I'm not sure what your job is, but it doesn't sound like you much real world experience with securing real live e-commerce sites.

How Google gets around this... by Sheepdot · 2006-01-30 11:46 · Score: 5, Interesting

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.

Re:How Google gets around this... by Anonymous Coward · 2006-01-30 11:59 · 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... by swillden · 2006-01-30 12:21 · Score: 1

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.

--
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Re:How Google gets around this... by Anonymous Coward · 2006-01-30 19:15 · Score: 0

I was amused at reading about your surprise at google independantly coming up with the same idea as you. :)
Re:How Google gets around this... by ArsenneLupin · 2006-01-30 23:09 · Score: 2, Interesting

Seriously, what's wrong with generating session cookies randomly that you felt the need to "fix"?
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 just give the victim a new brand-new cookie, foiling the attack)
Re:How Google gets around this... by fireboy1919 · 2006-01-31 00:55 · Score: 1

All of those things are terribly non-unique. In fact, most people I know run either Firefox or IE with a resolution of 1024x768.

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 cookies do.

The fact that MD5 is broken can also be a problem if you don't store all the user data on the server side to validate against the specific instance of the client (and under certain other cases it can also be a problem).

Of course, then you'll run into problems if they use two browsers. I actually regularly use IE, Firefox, and Opera, so that site wouldn't be for me.

--
Mod me down and I will become more powerful than you can possibly imagine!

Session.Abandon by Anonymous Coward · 2006-01-30 11:50 · Score: 0

Use Session.Abandon before any logon attempt to prevent the type of session hijacks mentioned in TFA.

Opera by Rits · 2006-01-30 11:53 · Score: 2, Informative

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

Formkeys by Bemmu · 2006-01-30 11:53 · Score: 2, Informative

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.

Not THAT nasty by sterno · 2006-01-30 11:56 · Score: 2, Insightful

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

Re:Not THAT nasty by Metasquares · 2006-01-30 12:07 · Score: 2, Insightful

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 by sterno · 2006-01-30 12:20 · Score: 1

This is partially avoided by the size limits that are placed on a cookie. Frankly though you've got bigger issues if you're that trusting of a cookie's contents :)

--
This sig has been temporarily disconnected or is no longer in service
Re:Not THAT nasty by iabervon · 2006-01-30 13:25 · Score: 3, Insightful

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:Not THAT nasty by Metasquares · 2006-01-30 13:33 · Score: 1

It isn't that the cookie is huge; the problem is that if you stick some JOINs, or perhaps even an OR 1=1, into a query, it can really drag down the DBMS if you have enough rows. MySQL's documentation has some information on how that can happen.
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 by insertwackynamehere · 2006-01-30 14:54 · Score: 1

you could just make a batch file which pings the server a lot, modifying cookies seems a little overkill for DDoSing. of course DDoSing is moronic like most malicious hacking so w/e i'm just saying :P dont think i defend either way or anything.
Re:Not THAT nasty by sterno · 2006-01-30 15:11 · Score: 1

Interesting twist on it. Only problem is under both scenarios, I'd be readily able to track you down :)

--
This sig has been temporarily disconnected or is no longer in service
Re:Not THAT nasty by prockcore · 2006-01-30 18:24 · Score: 1

Maybe I give you a session where your shipping address is my house.

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 by javifs · 2006-01-30 21:08 · Score: 1
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.

You seem to miss the fact that some sites do not regenerate the session cookie upon login and reuse the session ID generated in a non authenticated area. This can lead to session fixation attacks, and, consequentely, to impersonation attacks. A malicious user could log in as a the user he "fixed" the session to.
Here's how it is done:
1. user A visits a malicious site property of user B
2. malicious user's B software generates a valid session cookie for site X (valid can be just properly formated, a valid hash or a cookie obtained from the site by accessing it without any authentication it depends on the application, really). This can be either static or dynamic
3. user A is provided a modified session cookie from site X (expiration date is set very far in the future) and the software keeps track of which user's have been given which cookies.
4. user A, later in the fure, goes to site X
5. site X does not issue a new cookie, the user's browser already provided one
6. user A logs in to site X
7. site X associates the session with the user authentication (like, say, store the session ID in a table matching session to user like many PHP scripts do or storing this in a servlet context)
8. user A uses the site
9. malicious user B goes to site X with the session cookie he provided to user A and can bypass the site authentication.
So the malicious user can impersonate the user at the site without authentication.
Of course, the problem here is with the site (steps 5 and 7), it should regenerate session identifiers, at the very least, when a user logs in. That way the authentication is associated with the new session, not the old one. However, you would be amazed to see how many sites (even banks) reuse the session identifier generated in a non-authenticated throughout a user's session, and only regenerate it when it's marked as invalid (authentication session timeout expired).
The scenario differs in the case you are handling software in which session identifiers expire even if not associated with a user session (Notice this is not typically the case for many application servers, as they don't include timestamps in sessions, typically applications will be in charge of expiring the session for authenticated users). In this scenario the malicious user B just needs to obtain the cookie from the remote server when the user A accesses his own malicious server and then redirect the user to the login of the site. This makes the attack a modified version of the traditional phishing attack, in this attack you are not asking for user's credentials since you do not need them to access the site once the user is logged in (the session ID is sufficient to access the site).
For more info check out WebApp Security threat definition for session fixation Chris Shiflett: Security Corner: Session Fixation
Re:Not THAT nasty by ArsenneLupin · 2006-01-30 23:19 · Score: 1

but that means there has to be an SQL injection vulnerability on the server as well.
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 time, the attack comes from a different IP that is not traceable to you!
Re:Not THAT nasty by icepick72 · 2006-01-31 01:10 · Score: 1

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).
Most reliable sites also do an IP address check (in addition to just using the cookie-based session) to prevent against session hijacking.

Microsoft have been doing this for years by Anonymous Coward · 2006-01-30 11:59 · 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)
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

maybe not as serious as it seems ... by pikine · 2006-01-30 12:10 · Score: 1, Interesting

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.

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 /robots.txt (/cookies.txt) to indicate that the host "example.com" accepts cookies set by certain hosts.

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.

Re:maybe not as serious as it seems ... by Aeiri · 2006-01-30 16:10 · Score: 2

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.
Re:maybe not as serious as it seems ... by pikine · 2006-01-31 03:15 · Score: 1

How do you tell which host is in context when you run javascript in the address bar?

--
I once had a signature.
Re:maybe not as serious as it seems ... by Aeiri · 2006-01-31 09:00 · Score: 1

How do you tell which host is in context when you run javascript in the address bar?

If I understand what you are saying correctly, executing javascript in the address bar using the void function (NOT without it) executes javascript on the currently being displayed page as if it were called from that page. So if you were to put this code in slashdot.org's source code, it would have the same effect.

This is used as a web security tool to alter form information on pages (such as hidden values, <select> tags, and others) that people don't think to validate properly, among other things such as altering cookies (whoddathunkit?). GreaseMonkey is based on a similar concept, too.

This can be used in DoS attacks... by Alascom · 2006-01-30 12:25 · Score: 3, Interesting

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.

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 /. effect having serious financial impact on Slashdots bandwidth costs.

This is a potentially serious amplification attack vector that would be really hard to clean-up.

--
This attack ©The Terrorist Network ( www.terrorist.net )

Re:This can be used in DoS attacks... by imgunby · 2006-01-30 12:52 · Score: 1

Not to be an over-correcting troll, but the cookie limit is 4KB, or up to 20 name-value pairs per domain. Seems like the best you could hope for would be corrupting all cookies under .org, and adding another second or two to the initial request.
-imgunby
Re:This can be used in DoS attacks... by drew · 2006-01-30 14:18 · Score: 1

Maybe in theory, but in practice I can tell you that isn't true. I've known somebody who was experimenting with storing certain non-sensitive user history data in cookies rather than the database, and eventually started getting 500 Internal Server Error from Apache because the cookie was longer than the maximum allowed request header size (for 1.3.x, I believe it is 8k by default, but can be increased at compile time)

--
If I don't put anything here, will anyone recognize me anymore?
Re:This can be used in DoS attacks... by Lehk228 · 2006-01-30 14:20 · Score: 1

there is a very easy way to undo that, when slashdot recieves one of those cookies the user sending it is directed to a page instructing them to delete all cookies from slashdot.org and re-login.

--
Snowden and Manning are heroes.
Re:This can be used in DoS attacks... by imgunby · 2006-01-30 14:27 · Score: 1

That I don't doubt, but IE is just strange when it comes to cookies in general, and that assumes that everything between client and server correctly handles and passes that much header data, and I can tell you that AOL's proxies are pretty strict when it comes to that sort of stuff.
Re:This can be used in DoS attacks... by blue_adept · 2006-01-30 14:51 · Score: 1

oh, so your "wicked" attack requires that you first get slashdotted? if you're already slashdotted and want to launch an attack, why not just redirect/send all visitors to an alternate page with as many hidden frames as you like, which all load the slashdot main page? that would increase the size of the "attack" many, many times over what you've described.

--

"Is this just useless, or is it expensive as well?"
Re:This can be used in DoS attacks... by Aeiri · 2006-01-30 16:03 · Score: 1

This is a potentially serious amplification attack vector that would be really hard to clean-up.

You do realize that slashdot.org can tell browsers what to do with their cookies for their site, right? Those 1 million viewers aren't using "hacked IE" that you distribute that keep the cookie even after the site tells it to delete them.

Assuming a slashdotting gives out 1 million users to your site, as you assume (I have no idea what the real number is), you would have 80*(1 million) or 80GB of bandwidth sent to slashdot. The people at slashdot probably wouldn't notice something was up until say 40GB were used, and they would add code to delete that cookie on their site. So, now we have 120 GB of used bandwidth.

If you were really attacking slashdot that's like chump change to them. That's assuming you get 1 million hits, and they all go through (your server would buckle after 100,000 probably, unless you have massive bandwidth.

On top of all this, I have a feeling that this would be a really easy to trace attack (everyone on slashdot is getting these cookies after viewing this article... I wonder whats causing that?)... you wouldn't be laughing for long.
Re:This can be used in DoS attacks... by Anonymous Coward · 2006-01-30 19:19 · Score: 0

Even easier, write a script that sets the expiration date for all non-official cookies to a date in the past.

Problem solved, no user involvement needed.

Don't Use Cookies: Most Sites Don't. by Anonymous Coward · 2006-01-30 12:30 · Score: 1, Informative

Rewrite URLs with encrypted data as required instead.

Only 22% of servers use cookies. The best sites work fine without them.

Re:Don't Use Cookies: Most Sites Don't. by Anonymous Coward · 2006-01-31 00:19 · Score: 0

Session data doesn't belong in a url!

Re:Easy solution? by Vo0k · 2006-01-30 12:47 · Score: 1

'cause even if you do, the attacker may still happily use your domain name and it will work just fine. (and don't worry, if you don't have any associated with the IP, they will make one for you)

--
Anagram("United States of America") == "Dine out, taste a Mac, fries"

LiveJournal by darkain · 2006-01-30 12:48 · Score: 2, Informative

LiveJournal is already aware of this issue, and trying to do their best to prevent said issues within their system

Am I the only one who is scared about clicking any by Anonymous Coward · 2006-01-30 13:31 · Score: 0

links contained in this discussion. No I don't wish to see tubgirl of goaste for the millionth time, thank you for your example links but no thanks!!!!

I read TFA... by qzulla · 2006-01-30 15:41 · Score: 1

And was interested.

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... by Anonymous Coward · 2006-01-30 15:59 · Score: 1, Informative

Because that's the latest they can.
Re:I read TFA... by Jonathan_Jeffus · 2006-01-30 19:36 · Score: 1

A conjecture about this would be that 2038 is the ending of UNIX time. The maximum numer of seconds a signed integer can hold is 2 ** 31 - 1. So all as far as all Linux boxen are concerned the world ends on:

> 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... by Zed+Too · 2006-01-30 21:22 · Score: 1

2016 is exactly 10 years in the future.

EVERYTHING expires in 2038. by Anonymous Coward · 2006-01-30 18:05 · Score: 0

That's when the world ends. Haven't you heard?

Don't hit on Michal by NaveWeiss · 2006-01-30 20:08 · Score: 1

For anyone who might be turned on by Michal's geekyness - you should be aware that he's not a girl, unlike what his name might imply.

--
Slashdot community, please notice: I am looking for a girlfriend.
Nave H. Weiss

An example of how to exploit this: SSO phishing. by gedhrel · 2006-01-30 23:30 · Score: 1

SAML implementations (shibboleth, lib aliance etc) for distributed authentication usually include WAYF (where are you from) servers that direct a user to their home site for authentication purposes.

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 usual origin to authenticate, potentially permitting credential capture.

WAYF implementatinos may mitigate against this by sanity-checking the cookie (only redirecting to members of a federation, for instance) - however, this is an example of how a fairly obscure bug might have wide-reaching consequences.

So many PORN webmasters on one place by Anonymous Coward · 2006-01-30 23:33 · Score: 0

Happy reunion...

No misunderstanding by bigtallmofo · 2006-01-31 00:04 · Score: 1

You missed my point. It was that if your site relies on a secure browser (as the article stated) or data that is stored client side (cookies), you have many worries, not just the one outlined in the article.

--
I'm a big tall mofo.

Re:No misunderstanding by grahamsz · 2006-01-31 07:07 · Score: 1

How else could a site work?

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 with another client, and i cant see any way to design around that. Am i missing something here?

Relates to a problem we're having by notbob · 2006-01-31 00:37 · Score: 0

This kind of relates to a problem we're having.

How to get around sites that require session IDs just to link to them?

A ton of sites anymore require you to go to a main page to get some idiotic session ID just to get into the site.

Anyone have a way of using the stuff from this article or other methods to link to them?

I haven't been able to even wrap it in frames and make it iterate through or anything.

Nothing new by ajs · 2006-01-31 01:29 · Score: 2, Interesting

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.

Much Worse than That by rjstanford · 2006-01-31 02:18 · Score: 1

Laptops. There are many of us who find ourselves working out of hotels, airports, wherever. Having to log in again to multiple sites all the damn time would suck.

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 message boards which, while useful, think they're being l33t by making you sign in with a 17 byte password as if your chat account was as important as nuclear launch codes.

--
You're special forces then? That's great! I just love your olympics!

Man in the middle by Sigg3.net · 2006-01-31 04:05 · Score: 1

"Right, but hijacking a session should require at least a man-in-the-middle attack."

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!)
That man, that man, that man, that man
With that man-in-the-middle
(Man-in-the-middle, oh yeah!)
That man, that man, that man
I'm asking him to change his ways
(Better change!)

Sorry, couldn't help myself. Hee Hee! Aouh! *grab nuts doing V-sign!*

--
Defining Statistics and Social Research

idea by Anonymous Coward · 2006-02-01 04:52 · Score: 0

What about setting a new session cookie every request, and requiring the user to send that one once he accepted it?

--brgr

125 comments