Slashdot Mirror
The Dangers of Improper Cookie Use
shifted89 writes "Over the last year, the security community have exposed web application security for what it is — extremely lacking. However, for all the focus on XSS, CSRF, history stealing, etc., not much attention has been given to the cookie. Unfortunately, cookie misuse can be just as dangerous, if not more so than XSS attacks and InformIT illustrates why. In short, the author clearly demonstrates what can happen when a website improperly uses cookies for customer tracking — including a working illustration."
Cookie misuse has been chronicled here
See my journal for slashdot ID's by year. Mine created in 2005. http://slashdot.org/journal/289875/slashdot-ids-by-year
I disable them all because I hate any innovation of the web past 1991. Anyone who disagrees with me is wrong. This article is proof.
... but isn't this old news? Hacking (plaintext) cookies is about as innovative as hacking URLs or telnetting into your office SMTP server to write fake CEO emails to the new guy.
Still.. I'm off to get my $4 off coupons from Restaurant.com, ad-free weather from Wunderground.com, and free schools data from GreatSchools.net...
-BA
Me Like Cookies! - Cookie Monster
Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
If you think that's bad try going to a page like this with IE after copying and pasting sensitive information.
Oh well, I guess this is just another lesson in how marketers will shoot themselves in the foot. Animated gifs are abused, so i turn animation off. Cookies are abused, so i reject any cookie that is not obviously necessary. Flash is useful, but no way to request that it does not start automatically, so either I don't install it or install a hack to block it. I don't even see the product that is being advertised.
I hope this gets everyone off thier high horse, and realize that third party cookies should be rejected on all machines by default. What I really wish existed was a screen that popped up every time you went to a new site that informed the user of the site, and asked for a cookie preference for that site. That way, all cookies could be accepted at the corporate site, and no cookies might be accepted at google.
"She's a scientist and a lesbian. She's not going to let it slide." Orphan Black
It says "updated Dec 15, 2006" but the comments at the end of the article are all dated from 2004. I mean, the problem is much older than that, but it seems the article was just updated with 2006 dates to make it seem more current. Or am I missing something?
$nice = $webHosting + $domainNames + $sslCerts
This was possible because, against the dev security specs which said *everything* had to go over SSL, someone had decided that Javascript, CSS and Javascript should live on a separate, non-SSL server. The wonderful "enterprise" product they'd built their site with was kindly sending session cookies out with every response. Oops! :)
You may think "Ah, but this scenario has nothing to do with the real world" -- actually it did, because the "admin users" are people at the customer sites who control their service through the web front-end. So an attacker working for a client co could easily snaffle admin rights and just drop the service (or buy all our other services, or change IP settings, and all sorts of other phun.)
Web devs: if there's one piece of advice I could give, it'd be to get familiar with Ethereal ("Wireshark" as it's now called - bleurgh) and get to understand the basics of TCP and IP so you can interpret what you see on the wire. A pen-test proxy such as WebScarab is highly recommended.
There's only one simple rule to follow. The client can never be trusted, and all information should be verified server side.
I like how the first thing the 'cookie misuse' site is doing is trying to do is to set a cookie. The 'why' remains unknown.
Other things they do is prohibit tabbed browsing by using javascript to open an image from a thumbnail to a new window. Can someone please send these guys to a usability crash-course?
See my blog for my free opinions.
As it references XSS attacks and then jumps to cookie abuse like it is something newer than XSS, I mean you know the whole web 2.0, almost everything being session and cookie based, yes turn those boogers off their dangerous, and return to the safe land of 1998 where static web pages reigned supreme. The fact is that we can't just dismiss the cookie, yes we can play safely in the field with it, but past that it is a integral part of today's web infrastructure and there is no short term replacement for it, between JS, ASP, and PHP all nearly relying on the whole concept of the cookie to validate session etc. You can't just say they are dangerous and to stop accepting them in general, and you can't just tell the web designer to stop using them, for the primary reason that it isn't practical.
Did someone say cake?
Cookies go in the mouth not the nose.
``"Over the last year, the security community have exposed web application security for what it is extremely lacking. However, for all the focus on XSS, CSRF, history stealing, etc., not much attention has been given to the cookie.''
Maybe that's because the dangers of cookies have been known for AGES?
Please correct me if I got my facts wrong.
Cookie abuse reached new heights a few weeks ago when top sites in Google search results throw cookies on the search results page. So far it's not a guaranteded occurance, and only happens for the top search result. Still, it's jumping the gun.
I can't wait for the Mozilla devs to clean up their cookie code so that blocking cookies is as easy and configurable as blocking images. Even being able to prompt to block everything other than a session cookie would be a nice improvement.
Or am I full of you-know-what again?
Two Words: Crumby Milk
Thank You and Tip your Servers.
OSGGFG - Open Source Gamers Guide to Free Games
. . . about an extra 5 - 10 pounds around the waistline, in my experience.
What?
Mindy: What's wrong?
Homer: Oh, yeah, like you don't know. We're gonna have sex!
Mindy: Oh...well, we don't have to.
Homer: Yes we do! The cookie told me so.
Mindy: Well...desserts aren't always right.
Homer: But they're so sweet!
There are way more subtle ways to misuse cookies than demonstrated here.
This article shows us that you shouldn't let people in only by username without their password. Well duh.
I read the article and the author talks about the usual stuff: what cookies are, what they contain and how they track you. Then he goes on to say that since some of the cookies expire in 2009, a lot of information could be collected on you during this time.
As is said everytime the issue of cookies comes up, DELETE THEM! You don't need to keep them.
Once you delete them, you're a new, unique visitor to a web site. You screw with their statistics since they think you're someone new, thus increasing their advertising budgets because they think they have more visitors.
There is no reason to keep cookies. Delete them and laugh everytime you read stories like this.
We will bankrupt ourselves in the vain search for absolute security. -- Dwight D. Eisenhower
So used to Fark, that I thought it meant the pastry for a moment...
Ok... if you're storing the session id via cookie... what's the best solution for preventing cookie theft abuse? Pardon my stupidity for not knowing this already...
FTFA:
That section about the "personal identification code" talk is very weaselly. It makes cookies sound like any website can read a cookie on your computer that's flagged as "owned" by that website at any time. Cyrus Peikari and Seth Fogie (article authors) leave out the important, necessary link: the DoubleClick cookie can be read only when your computer makes an outgoing HTTP connection to DoubleClick. Like when a DoubleClick banner ad is included in a Slashdot page's HTML. Which HTTP request includes a CGI param (REFERER) pointing to the Slashdot page from which the IMG tag instructed the computer to pull the DoubleClick banner image. That's how Doubleclick gets its cookie, and the context that you visited a Slashdot page.
DoubleClick cannot read its cookie any other time, when there's no HTTP connection from your computer to DoubleClick. Like all the rest of the pages on which DoubleClick has no banner or other "self-clicking" link. There are web bugs, invisible images tags embedded in other pages just to hit their server with the REFERER of the page triggering their bug, updating your computer's cookie with their counter (etc). But they cannot be read "at any time".
Besides, the cookie is a nonessential part of this snooping. DoubleClick doesn't need to keep its counter on your computer - the IMG hit can update its server-side counter DB. It can ID you, though not as precisely, by your IP# and other CGI parameters you send with every HTTP request. Or DoubleClick's deal with, say, Slashdot, is that Slashdot encode the DoubleClick banner IMG tags the Slashdot server sends you with its pages with a unique ID, like your Slashdot userid. ACs and public terminals mostly escape, but they're not really targets for these marketdroids.
And you can turn off cookies in any non-retarded browser, making them anonymous (encoded IMG URLs are much harder - see?). And you can inspect the cookies stored on your computer.
All these issues were discussed in great detail by the HTTP Working Group as we invented cookies, almost a decade ago. Some people were philosophically opposed to letting untrusted servers store any data on users' computers. Though every page, every image is stored on users' computers, after retrieval for presentation. And we realized that stopping cookies would mean only people with money to make "cross-site" deals and maintain large centralized databases would get the power to exploit cookies for tracking. So the cost would motivate more profit-exploitation of the tech. Ultimately only profiteers would track you, and there'd be plenty of them, without even the local control that cookies offer. And the entire Web would lose even voluntary easy tracking of intersession client state.
We decided to make cookies simple and use them. They're mostly harmless - a good balance with the huge benefit they deliver all day long in the Web Era. But I guess there's still profit to be made by scaring people on the Web, like the naive "technologists" to whom this InformIT article is directed, with incorrect cookie hysteria, and offers to help protect us.
That's the way the cookie crumbles.
--
make install -not war
It's almost scary looking at your cookie list after some surfing. That's why I have allowed cookies only from certain hosts.
good website:want a cookie? you:not from your site! good website:alright, I'll live on. bad website:want a cookie? you:not from your website bad website:that wasn't a question. We're not going to work for you now.
"A Cookie is a Sometimes Food". Do not overuse; may cause drowsiness, fatigue or a fat ass.
Hard work is just an accumulation of the easy things that you didn't do when you should have.
Firefox and Opera both make it easy to automatically delete cookies.
In Firefox, go to Tools->Options* and select Privacy. In the Cookies section, change "Keep until:" to "I close Firefox." Voila! All cookies will be deleted automatically whenever you close Firefox. Plus, by clicking on the "Exceptions..." button, you can set a list of sites for which you want to remember your cookies. Alternatively, you can use the Clear Private Data feature, but wipes all cookies, even the ones you've listed under Exceptions.
In Opera, go to Tools->Preferences and select Advanced. Then choose Cookies. Select "Delete new cookies when exiting Opera." Then clear out any cookies you want to get rid of. From that point on, cookies set before you turned on the checkbox will stay until they expire, but cookies set afterward will be dropped when you close the browser. You can add more semi-permanent cookies by unchecking the box, visiting a site, then checking it again.
*Or equivalent on Mac or Linux.
I have a friend who works for a medical software company. Their system handles all kinds of personal information; SSNs, medical records, body scans, etc. The authentication is cookie-based; All the information about a user's access is a serialized, base64 encoded data structure.
Yup, you heard it right. base64 decode your cookie, change a few values, stick it back in... Ta-da, you're an admin.
Improper cookie use can be a nasty, nasty thing. The worst part is that this problem was brought up to the lead developer, who had originally wrote this auth system, but... "Well, it is base64 encoded, noone will ever figure that out." Yeah, right.
Love sees no species.
Firefox 2 includes the new WHATWG-specified client-side persistent storage. However, some argue it is critically flawed. Learn the arguments now and we can discuss this further on Slashdot in 2010!
that when I read the title, I expected an article about the dangers of chocolate chips, maimings performed with oatmeal-raisin, and death by fudgee-o's? Hrm, methinks I should have a snack.
It may look like I'm doing nothing, but I'm actively waiting for my problems to go away.
--Scott Adams
...outdated
Firefox could do better around cookies.
For example, just look at their cookie management under "privacy". Sure, they have white and blacklists for cookies, and that's fine. But bring up your cookie list - the *ONLY* option you have for each cookie is to delete.
Why isn't there are "delete and block" button? It would be SO SIMPLE to add this function, and make the management of cookies so much simpler for the 95% of web users like me who want to accept *most* cookies, and only block obvious cross-site tracking cookies.
The task of copying cookies from one list to another is very tedious. This sort of thing should be able to be automatic.
One of the great features of a cookie that the article leaves out is the fact that servers don't need to set an Expiry date.
If you don't set an expiry date, the cookie is temporary, and will not be stored to disk. It will be deleted/destroyed when the browser is closed.
Cookies with SessionID information should ALWAYS be temporary, or no Expiry date. Anyone who sets a cookie with sensitive information with an expiry date is asking for trouble, plain and simple.
C'mon. This is completely on topic--is not robbing a bank with a spritz-cookie gun an improper use of a cookie? Sheesh. What's a man got to do to get a laugh around here.
They previously were slashdotted on sessions at http://www.informit.com/articles/article.asp?p=603 037&seqNum=1&rl=1
If you use cookies improperly you'll grow blue muppet hair.
I'd use Jabber instead since it's a stateful protocol. HTTP is not and that's why we have all these work-arounds to make it into one...badly.
This cookie is certainly malicious. Don't worry- It's just a picture. The Malicious Cookie
I wish there was a way to reject cookies from specific sites. I like the ability to not having to login to various sites each time I visit them but I don't like getting tagged with non-esential cookies.
If you were really that old-fashioned, you wouldn't have to disable JavaScript. The graphical web browser was invented in 1992, so you'd be compelled to use a text-only browser, such as Lynx. And those don't have any JavaScript to disable.
You are obviously part of an Evil Conspiracy. Please rant some more so I can figure out which one.
If I can sniff your http traffic, I can also spoof your IP. All your plan will do is break your site for people who are behind a proxy pool.
Anyone want to guess how many more stupid articles we're going to see explaining the basics of how HTTP, cookies or Javascript works? I find it amusing, yet sad, that so many people are pointing out web vulnerabilities that are nothing more than a n00b not understanding how someting works and either misconfiguring it or using it improperly.
I'm sorry, but cross-site scripting attacks are not real vulnerabilities! The problem is that your stupid browser can execute Javascript that's allowed to read local files and send data out over the network. The problem is not some forum maintainer allowing people to post Javascript, the problem is that you're allowing it to run. Turn Javascript off! It's garbage.
As for cookies being used improperly, what's so hard to understand? It's a file that's stored on a client's system. Under no circumstances should you store data you don't want the client to see, nor should you blindly trust the data the client provides.
Let's not even get into form validation. Apparently a lot of "web developers" don't understand the difference between an HTTP server and HTML content. No, just because you limited that pulldown to three options in your HTML doesn't mean the client can't send something else in its POST request.
I can't help but to wonder where companies are finding all of the idiot web developers.
Hmm, not even old, more like ancient use. It's as basic as it gets. Idiots will always get a chance to create software, so it's hardly surprising that you can find dumb site implementations.
The article mentions the vulnerability of cookies to XSS attacks. There is actually a way of protecting cookies from javascript, by using the HttpOnly option. It was introduced in IE6. Hopefully, it will get implemented in other browsers too, as it is a step forward in security for cookies.
t tponly_cookies.asp
http://msdn.microsoft.com/workshop/author/dhtml/h
seriously, that headline really freaked my out!! I had just eating like 18 cookies!! Doesn't look like this applies to me though. Thank god for that.
Clearly we are all ignoring the true danger of improper cookie use: a fat ass.
khasim (12/9/06): In a blind taste test, more people preferred Coke over the Pepsi that I had previously pissed in.
It affects us all
So where did Scott post his social security number, credit card numbers, drivers license number, license plate number, employee id number, his entire medical history, his entire school records, how many times he visits a whore, and a digital copy of his finger prints, retnal pattern and DNA.
I'd go on a Vegan diet but the delivery time from Vega is too long. --brownkitty