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."
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.
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
bingo. that's why i store the IP address along with the session ID in the database.
There was a merchant site that I visited quite some time ago that did something like this. Except they screwed it up and, along with putting the session ID in the URL, they "automatically" tied the session id with account information. The effect this had was that anyone who visited a copied URL would pull up the account information of the person who had spread the URL around.
It took some time to figure it out. The URL was posted on a fairly busy forum, and it was a fairly fast selling item, and 50+ people had used the link to try and make a purchase.. and every time someone checked out, the account was updated with their information.
I'm not sure what the lesson here is, other than the fact that any "safe practice" can become insecure in the hands of idiots. Cookies aren't an inherently stupid idea, but the ease of using them invites a lot of abuses.
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!
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