Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

The Dangers of Improper Cookie Use

CmdrTaco posted more than 7 years ago

Security 191

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

cancel ×

191 comments

Sorry! There are no comments related to the filter you selected.

not first? (-1, Troll)

crossbow_of_speed (527135) | more than 7 years ago | (#17289338)

plork!

Old News (4, Funny)

MyLongNickName (822545) | more than 7 years ago | (#17289382)

Cookie misuse has been chronicled here [bbc.co.uk]

Remember.. (2, Funny)

Swimport (1034164) | more than 7 years ago | (#17289770)

Cookies go in the mouth not the nose.

Re:Old News (1)

Kabuthunk (972557) | more than 7 years ago | (#17289826)

Ok, albeit not quite what I was thinking, but at least I wasn't the only one who was thinking something else after reading the title.

I was picturing children somehow jamming oatmeal cookies in their eye or something :P

Cookies? Javascript? Etc? (5, Funny)

Anonymous Coward | more than 7 years ago | (#17289396)

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.

Re:Cookies? Javascript? Etc? (2, Funny)

Anonymous Coward | more than 7 years ago | (#17289658)

Really? I'm the opposite.

As Scott McNealy once said, "Privacy is dead, deal with it". I've extended that to security which is why I enable javascript and install the binary-only flash player which is configured to auto execute bytecode from any server on the web. In my vision of the future, anybody with disabilities, privacy concerns, security concerns or who is running something other than Windows isn't worth bothering with. Viva innovation, especially from Microsoft!

Re:Cookies? Javascript? Etc? (4, Insightful)

Kelson (129150) | more than 7 years ago | (#17289880)

I disable them all because I hate any innovation of the web past 1991.

Hmm. Animated GIFs? Check. Blink? Check. Scrolling status bar? Check. Background MIDI files? Check. Pop-ups? Check. Flash ads with full video and sound? Check. Garish color schemes? Double-check.

I think you're on to something!

Re:Cookies? Javascript? Etc? (4, Funny)

kalaf (963208) | more than 7 years ago | (#17290764)

High resolution porn? No wait, I take it back!

Re:Cookies? Javascript? Etc? (-1, Flamebait)

Anonymous Coward | more than 7 years ago | (#17291024)

High resolution porn? No wait, I take it back!
No, you take it brokeback.

Re:Cookies? Javascript? Etc? (4, Insightful)

BLACKtactx (1015407) | more than 7 years ago | (#17290516)

Do you count CSS as an innovation??. If so, i have to disagree with you. Wouldn't it be better to word it "I hate any innovation that annoys me", instead of a blanket "any" innovation. Or maybe I should just develop all my sites in size 15 font, using framesets, in times new roman, and 16 colours. Innovation in itself is not bad, innovation for the sake of it is. The misuse of tehcnology cannot also be blamed on the technology itself but the dumb people who develop. I find javascript incredibly useful to improve my ui, some people decide to make yellow scrolling text on a magenta background, thats not javascripts issue. Dont shoot the messenger. Better go, my brick cell phone is ringing, and Im missing Magnum PI reruns.

Re:Cookies? Javascript? Etc? (0)

Anonymous Coward | more than 7 years ago | (#17290608)

someone didn't see the tag...

Re:Cookies? Javascript? Etc? (-1, Flamebait)

Anonymous Coward | more than 7 years ago | (#17290692)

You seem to think CSS is a good thing.

Let's see:
1) breaks minimal browsers (page down 6 times in /. to get to the first useful text? WFT?)
      1a) causes dinks to tell me to update my browser
2) makes it trival to use annoyingly small text
3) makes it trival to use garish colors
4) makes it trival to use different shades of the same color making it impossible to read the text
5) is used to keep so-called web designers in business
6) makes it harder to see where the fuckup is in the HTML
7) is used by so-called web designers to masturbate (ooo, i can control the exact layout, uuhh, ooo, ahhhhhh)

CSS sucks and serves no useful purpose. It was a solution in search of a problem and it is the wrong solution and it is misused by boneheads.

Are animated GIFs always wrong? No, NOAA uses them for some of their weather radar loops. But I don't get to see them because I'm not going to allow animated GIFS for anyone, not NOAA, not my mom, not doubleclick.net.

Is CSS always wrong? Hard to tell, I can't get get the kind of control over it I get with other web annoyances, but I suspect it can be useful and good. But mostly it is used for #7 which disgusts me.

IMHO.

Re:Cookies? Javascript? Etc? (1, Informative)

Anonymous Coward | more than 7 years ago | (#17290706)

Or maybe I should just develop all my sites in size 15 font, using framesets, in times new roman, and 16 colours.

Fonts, font sizes, frames, and colors are all post-1991 innovations and would be invalidated by the GP's criteria.

Also, you seem to be missing a sense of humor. I recommend immediate surgery to remedy the problem.

Okay, I know it's not an old article... (1)

Bright Apollo (988736) | more than 7 years ago | (#17289412)

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

Obligatory (2, Informative)

Archangel Michael (180766) | more than 7 years ago | (#17289418)

Me Like Cookies! - Cookie Monster

Re:Obligatory (1)

silentounce (1004459) | more than 7 years ago | (#17289496)

I'm confused. Does obligatory mean not funny?

Re:Obligatory (2, Insightful)

Archangel Michael (180766) | more than 7 years ago | (#17289600)

Why yes! Yes it does!

My problem is that I missed the Anonymous Coward Check box, and now, my karma has taken a hit. Sigh.

Oh well. Live and learn

Re:Obligatory (1)

silentounce (1004459) | more than 7 years ago | (#17289682)

I'm not an expert or anything, but I'm pretty sure that's not your problem.

Re:Obligatory (3, Insightful)

Archangel Michael (180766) | more than 7 years ago | (#17289898)

Okay, it is ONE of my problems. Sheesh

No need to beat a man while he's down.

Re:Obligatory (0, Offtopic)

silentounce (1004459) | more than 7 years ago | (#17290066)

Tell that to my wife. I'm sorry. My wife is taking her PMS out on me, and now I'm taking it out on you. It's the circle of life. Beautiful, no?

Re:Obligatory (0)

Anonymous Coward | more than 7 years ago | (#17289686)

In any case, you live.

What about clipboard theft? (1)

mongus (131392) | more than 7 years ago | (#17289422)

If you think that's bad try going to a page like this [scriptingmagic.com] with IE after copying and pasting sensitive information.

Re:What about clipboard theft? (1)

Cartack (628620) | more than 7 years ago | (#17289524)

Not sure about older versions, but IE 7.0 asks before allowing the clipboard to be copied.

cookies passed as plaintext (3, Informative)

brunascle (994197) | more than 7 years ago | (#17289450)

Second, cookies are passed as plaintext unless there is an encrypted session. As a result, anyone with a sniffer can capture the cookies contents and use them as their own.
bingo. that's why i store the IP address along with the session ID in the database.

Re:cookies passed as plaintext (0)

Anonymous Coward | more than 7 years ago | (#17289534)

Yes, and the instant you store IP addresses with session IDs you break your web applications for the millions of people that run their machines behind any sort of NAT device.

Re:cookies passed as plaintext (1)

daeg (828071) | more than 7 years ago | (#17289578)

How do you figure? He's storing the public-facing IP, not the private address.

How does this break?

(Of course it does break for anyone using anonymizer-type services)

Re:cookies passed as plaintext (0)

Anonymous Coward | more than 7 years ago | (#17289704)

Some large companies, not just AOL, do the interal->external address mapping dynamically. That means the same user can send requests from multiple ip addresses during a single session.

When the company I worked for at the time encountered this, we just used the first three octets instead of the whole IP address. That worked in all the cases we ran into.

However, AOL does so many other weird things that in the end we had to tell our customers that we could not support them if they were using AOL. In one case, I was able to run the equivalent of tcpdump on both the client and the server while attempting to connect to our web site via AOL. In each case, the first three packets made it and the rest were silently dropped.

Re:cookies passed as plaintext (1)

multipartmixed (163409) | more than 7 years ago | (#17289542)

That's bitten me a few times with AOhelL users... their proxy sometimes dynamically changes.

Mind you, nobody's bitched about it in a couple of years now. Maybe their proxies are smarter now?

Re:cookies passed as plaintext (1)

brunascle (994197) | more than 7 years ago | (#17289592)

yeah, i knew that was going to happen going forward, but it's a small price to pay to eliminate a rather large vulnerability. and i have yet to hear any complaints.

Re:cookies passed as plaintext (1)

adnonsense (826530) | more than 7 years ago | (#17289594)

When I faced that problem, I made the IP check only consider the first 2 octets of the IP address, and compared the user agent too. By no means watertight, but was enough to stamp out some casual abuse with a minimum of effort.

Re:cookies passed as plaintext (5, Insightful)

Xzzy (111297) | more than 7 years ago | (#17289820)

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.

Re:cookies passed as plaintext (1)

darthlurker (663459) | more than 7 years ago | (#17290234)

Second, cookies are passed as plaintext unless there is an encrypted session. Or if you encrypt the cookie's value. Isn't that SOP if your HTTP state information is sensitive?

Re:cookies passed as plaintext (3, Insightful)

jgc7 (910200) | more than 7 years ago | (#17290722)

> bingo. that's why i store the IP address along with the session ID in the database.

How does that do anything for the example given? If someone uses a sniffer at a wireless access point with NAT, they have access to the same IP as their victim.

Re:cookies passed as plaintext (0)

Anonymous Coward | more than 7 years ago | (#17291088)

Bad idea, unless you like to prevent AOL users from using the site.

Gimme yer dough (-1, Offtopic)

big_oaf (560706) | more than 7 years ago | (#17289454)

Headline: Man robs bank with spritz-cookie gun. Demands dough. Sorry. Couldn't resist.

Re:Gimme yer dough (0)

Anonymous Coward | more than 7 years ago | (#17291100)

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.

restaurant.com, here I come! (-1, Troll)

multipartmixed (163409) | more than 7 years ago | (#17289502)

MmmMmmmm.

Eatin' for free tonight!

Yummy cookies.

practical, perhaps? (4, Insightful)

fermion (181285) | more than 7 years ago | (#17289526)

I was going to read the article until the 5th cookie was set at which point i just assumed that the entire thing was an practical lesson. Be stupid enough to read an article about cookie abuse and get caught in the trap. Sort of like trying to find a windows virus filter only to find that the virus filter has infected you.

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.

Re:practical, perhaps? (2, Informative)

blindcoder (606653) | more than 7 years ago | (#17289798)

My mozilla from a year-or-so ago has this setting where it ask you about each cookie being set. it can then remember the setting for this website.
Maybe you should learn about or change your browser.

Edit - Preferences - Privacy & Security - Cookies
Here Check 'Allow Cookies based on privacy settings' and 'Ask for each cookie'.

Also, for flash, google for flashblock. Nice plugin, disables all flash and replaces it with a 'play' button. You can then click on that button to show the flash.

Re:practical, perhaps? (2, Interesting)

FireFury03 (653718) | more than 7 years ago | (#17290674)

My mozilla from a year-or-so ago has this setting where it ask you about each cookie being set. it can then remember the setting for this website.
Maybe you should learn about or change your browser.


For some crazy reason, FireFox 2 has now removed this option - I had to go poking around in about:config to turn it back on. :(

Re:practical, perhaps? (0)

Anonymous Coward | more than 7 years ago | (#17290878)

Typically, you can set the browser to reject, accept, or accept for sessions, specific cookies. It not possible, as far as I know, to set the browser to reject all cookies from a specific domain or specific page, no matter where those cookies originate.

so, to recap, any modern browser can accept or reject specific cookies, and remember those preferences. What does not yet happen is the rejection of cookies from entire site. On a trivial basis, this means that any cookie from 2o7.com will be rejected, and I do not have to individually reject those cookies. On a more expanded view, any cookie with 2o7 in the name will be rejected. On the grandest scale, and cookie that tries to be set when I navigate to microsoft.com will be rejected out of hand.

If there is a way to make this happen, let us know.

Re:practical, perhaps? (1)

blindcoder (606653) | more than 7 years ago | (#17291056)

You can do this in Mozilla. Same dialogue as before, click on 'Manage Cookies'. Don't know about the new FF, but in my Mozilla, it's there.

Re:practical, perhaps? (2, Informative)

Yazeran (313637) | more than 7 years ago | (#17289816)


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.


Well just use Firefox with the Adblock and Flashblock extensions (ok addblock does not fix flash things, but once learned ignores most image advertizing.). Flashblock replaces any flash thing with a window frame with the same size but does not run the flash, and i think it does not even download it untill you bress the run button on the window frame.

In my opinion Addblock and Flashblock are the two most important reasons to use Firefox.

Yours Yazeran

Plan: To go to Mars one day with a hammer.

Re:practical, perhaps? (1)

M. Baranczak (726671) | more than 7 years ago | (#17289994)

In my opinion Adblock and Flashblock are the two most important reasons to use Firefox.
Mine too. You don't even realize how annoying those Flash ads are until you use FlashBlock for a few months, then go use a browser that doesn't have it.

Firefox could do better (2, Insightful)

brunes69 (86786) | more than 7 years ago | (#17290870)

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.

Re:practical, perhaps? (3, Interesting)

nekokoneko (904809) | more than 7 years ago | (#17289828)

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.

Actually, Konqueror does that if you set it up to ask what to do when you receive a cookie. I fiddled around with Firefox and couldn't find a way to do it, but maybe messing around with Network.cookie.cookieBehavior [mozillazine.org] and Network.cookie.p3p [mozillazine.org]

Re:practical, perhaps? (1)

McNihil (612243) | more than 7 years ago | (#17290298)

Or you can use "Permit Cookies" with FireFox and still read it without getting/giving any cookies if you want ;-)

Re:practical, perhaps? (1)

Arkhan (240130) | more than 7 years ago | (#17290684)

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

This is easily configurable behavior in IE6 (possibly earlier - I can't recall). Tools->Internet Options->Privacy->Advanced.

I keep mine set to third-party reject, first-party prompt, always accept session cookies. When I hit a site with a first party cookie, I get a little popup that says: "<sitename> wants to store a cookie on your computer" with choices "Accept Cookie", "Reject Cookie", "Cancel", and a checkbox to say "Always apply the same decision for this site".

Voila. Corporate stuff gets one click of the "always apply..." checkbox and then one click on Accept. Nearly every other site gets one click on "always apply..." and then one click on Reject.

Works like a champ. I wish everyone configured this way.

Re:practical, perhaps? (1)

Crayon Kid (700279) | more than 7 years ago | (#17291072)

Trust me, you DON'T want a popup dialogue for every cookie. There are Firefox extensions (such as Cookie Button) which let you customize cookie setting per-site. Together with a default of "enforce session expiration for this site", all is well.

You can't really browse the web with cookies completely disabled. I have extensions that can block both cookies and JavaScript completely. I can live without JS, but I've discovered I can't with blocking all cookies by default. So now the default is session. It's ok, really -- I get the functionality and the likes of doubleclick.net don't get to match my id from one session to another.

Yikes... (-1, Offtopic)

Anonymous Coward | more than 7 years ago | (#17289564)

Holy Fuck. This is chilling 0.o ...

How old is this article? (5, Insightful)

Dekortage (697532) | more than 7 years ago | (#17289604)

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?

Re:How old is this article? (0)

Anonymous Coward | more than 7 years ago | (#17290132)

Those comments apply to the 'security reference guide', not to the article.

Easiest pen-test I ever ran (0)

Anonymous Coward | more than 7 years ago | (#17289678)

Sitting in the project room with the devs working on a high-profile web app for controlling business internet service (can't be more specific, sorry :) Fire up ethereal; watch admin cookie go by in plain, copy & paste into local browser - boom! 0wnxx0red :))

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.

One simple rule to follow (1)

D4rk Fx (862399) | more than 7 years ago | (#17289720)

There's only one simple rule to follow. The client can never be trusted, and all information should be verified server side.

Cookie on cookie misuse link (4, Insightful)

blindcoder (606653) | more than 7 years ago | (#17289728)

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?

Re:Cookie on cookie misuse link (4, Informative)

J0nne (924579) | more than 7 years ago | (#17290032)

Other things they do is prohibit tabbed browsing by using javascript to open an image from a thumbnail to a new window.

I can't believe how common that still mistake still is.
It's not like it's hard to use the following instead:
<a href="image.jpg" onclick="popup(this.href);return false;">link</a>...

Re:Cookie on cookie misuse link (1)

blindcoder (606653) | more than 7 years ago | (#17290324)

or just use the target parameter like everyone else.

Re:Cookie on cookie misuse link (1)

LanMan04 (790429) | more than 7 years ago | (#17290938)

or just use the target parameter like everyone else.
Depricated! Not valid XHTML!

Re:Cookie on cookie misuse link (1)

blindcoder (606653) | more than 7 years ago | (#17291010)

care to enlighten us on the correct way or do you intend to let us die dumb?

Re:Cookie on cookie misuse link (0)

Anonymous Coward | more than 7 years ago | (#17290614)

Now try opening that image in a new tab by Ctrl-clicking. Please put a little thought into your click handlers.

White-list the only way (0)

Anonymous Coward | more than 7 years ago | (#17290174)

It's almost scary looking at your cookie list after some surfing. That's why I have allowed cookies only from certain hosts.

Re:Cookie on cookie misuse link (0)

Anonymous Coward | more than 7 years ago | (#17290354)

How is tabbed browsing prohibited? I click a thumbnail and the image opens in a new tab. What else should I expect it to do?

Re:Cookie on cookie misuse link (2, Insightful)

blindcoder (606653) | more than 7 years ago | (#17290496)

if I click on the image, I expect it to open in the same or a new window. If I click with both mousebuttons, I expect it to open in a new tab.
this is not possible with javascript 'links' which may or may not do things as you would expect and certainly destroy any usage patterns you have achieved and do so without a valid reason.

I love the start of this article (3, Insightful)

fullphaser (939696) | more than 7 years ago | (#17289742)

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.

Re:I love the start of this article (1)

Shados (741919) | more than 7 years ago | (#17290410)

the problem isn't even javascript or cookies. Its that making web sites was marketed as something easy, when in practice, web apps are significantly more difficult to make than desktop applications (at least if you don't half ass them). So you have a ton of people claiming to be web experts, that don't know how all these technologies work... The technologies are decent at what they do, as long as the average skill of those who use them is greater than your typical 6th grader...

Re:I love the start of this article (1)

fullphaser (939696) | more than 7 years ago | (#17290454)

Even then what are you going to do, we are always taught to never trust our users, so I think the thing with this cookie business is just on the same level, cookies are just another method of attack, if you rely solely on them, as an experienced web app we should know if you are going to have cookies you are going to need another form of verification than just the cookie. So pointing a finger at any one single source is ridiculous, distrust the user all the way through

Maybe (2, Informative)

RAMMS+EIN (578166) | more than 7 years ago | (#17289776)

``"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?

Worse and worse (3, Informative)

Dracos (107777) | more than 7 years ago | (#17289778)

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.

Re:Worse and worse (1)

i.r.id10t (595143) | more than 7 years ago | (#17289846)

Blank your cookie file, login, etc. to the sites you want to have cookies on, close browser, make cookies.txt readonly, enjoy.

Re:Worse and worse (4, Informative)

afidel (530433) | more than 7 years ago | (#17290054)

That's because your browser is pre-downloading the content from those sites, so yeah they are going to send their normal cookies. Turn off the preload feature and problem solved.

Re:Worse and worse (1)

Dracos (107777) | more than 7 years ago | (#17290638)

I keep a somewhat comprehensive (18,000 line) hosts file on my machine, and have for a few years now. I don't get barraged with as many cookies (or banners) as most people.

This cookies-in-the-results behavior isn't a pre-fetch issue. It started well after I switched (from Mozilla) to Firefox 1.5.x in August, maybe in the last month or so.

Other key features for cookie blocking are to block cookies from domains other than the window's URI, and block cookies returned from non text/* or application/* mime types (images, I'm looking at you).

It took me a while to get FilterSetG to block urchin.js, but I think I finally managed to.

Use AJAX? (1)

bb5ch39t (786551) | more than 7 years ago | (#17289824)

I'm just asking. But it seems to me that if a Web site were designed to use AJAX, then the entire "session" would be a single communications, so no cookies would be needed to "track" the user interaction.

Or am I full of you-know-what again?

Re:Use AJAX? (1)

Shados (741919) | more than 7 years ago | (#17290116)

ajax doesn't allow you to keep a live connection or something. It still does standard HTTP requests and such. So you're still living in a disconnected model. It doesn't help, unless you're using a fancy framework that will handle things for you: but then its the framework that helps, not ajax.

Re:Use AJAX? (1)

iwan-nl (832236) | more than 7 years ago | (#17290306)

Good AJAX sites don't work like that. It breaks the browser's navigation and refresh buttons and it doesn't degrade gracefully.

The Real Danger of Improper Cookie Use (1, Funny)

MrCopilot (871878) | more than 7 years ago | (#17289904)

The Real Danger of Improper Cookie Use:

Two Words: Crumby Milk

Thank You and Tip your Servers.

The Dangers of Improper Cookie Use (0, Flamebait)

aquatone282 (905179) | more than 7 years ago | (#17289910)

. . . about an extra 5 - 10 pounds around the waistline, in my experience.

Obligatory Simpsons reference.... (5, Funny)

Illusion2269 (959341) | more than 7 years ago | (#17289960)

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!

OMG cookie misuse! (1)

suv4x4 (956391) | more than 7 years ago | (#17290024)

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.

What's the big deal? (1)

smooth wombat (796938) | more than 7 years ago | (#17290040)

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.

Deleting Cookies Automatically (1)

Kelson (129150) | more than 7 years ago | (#17290400)

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.

Re:What's the big deal? (0)

Anonymous Coward | more than 7 years ago | (#17290404)

In this case, deleting the cookie wouldnt protect anyone... The site in question uses the email field of a cookie as authorization to a specific account. Even if you delete your cookies, an attacker can still get into your account because they only have update their own cookie with your email address...

Sigh... (1)

alisson (1040324) | more than 7 years ago | (#17290052)

So used to Fark, that I thought it meant the pastry for a moment...

So.. what's the solution? (1)

sherriw (794536) | more than 7 years ago | (#17290106)

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

Re:So.. what's the solution? (-1, Offtopic)

Anonymous Coward | more than 7 years ago | (#17290276)

Cookies made with a laxative will be a boon to prevent stealing in the future.

Re:So.. what's the solution? (1)

Carnildo (712617) | more than 7 years ago | (#17290744)

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


1) Make the session ID a random value so it can't be guessed
2) On the backend server, tie the session ID to a given access time and IP range
3) Invalidate the session ID and force a re-login if a request with that ID comes too long after the last access, or from a different IP range.

Re:So.. what's the solution? (1)

davidbrit2 (775091) | more than 7 years ago | (#17290856)

The typical way to do this is by storing a completely random, meaningless sequence of characters (often a hash of some random data) generated at login into the cookie, and keeping track of these hashes and their associated sessions on the server. You can know all the personal information you want about someone, but none of it will help you determine what their session ID hash is, since there's no direct correlation between the two.

Now, there's still the issue of packet sniffing or XSS to steal someone's session ID cookie, but there are some preventive measures for this too. For example, the server could also track the IP address that the session ID hash is associated with, and refuse access to a client that tries to use it from a different address. I'm sure there are many more clever approaches too, not the least of which is ssl encryption.

Re:So.. what's the solution? (1)

Trails (629752) | more than 7 years ago | (#17290898)

One should ensure that a given session ID is not used across multiple c-class ip addresses (e.g. it should always come from x.x.x.* where * can change throughout the session). The reason why I say c-class and not full ip address is that the ip address of AOL users can sometimes rotate mid-session (more info [wikipedia.org] ).

For example: you get an HTTP request from 66.35.250.150 (using /.'s ip for example purposes). You assign it a session ID and service the request.

Now you get a second HTTP request, with the same session ID, from 212.58.228.155 (BBC's ip, used for example purposes). This request must be blocked, and the session killed, since the session has potentially been comprimised.

More "Cookie Monster" Hysteria (5, Informative)

Doc Ruby (173196) | more than 7 years ago | (#17290166)

The "friendly" article does start off sensibly, mentioning that "Cookies are not programs, they can't read your personal data, and they don't cause spam.". OK, main scary cookie myths put aside.

FTFA:
This value pair is my personal identification code that can be used to track my movements across the internet and build a profile about my surfing habits. This is possible because a cookie can be read at any time by the domain that owns it. As a result, when I visit Slashdot.org, doubleclick.net will attempt to read its cookie that is on my computer. This will provide doubleclick.net with my id value, and their database will be updated. In other words, they now know that I like to visit Informit.com and Slashdot.org. Already their profile on my surfing habits can tell them I am probably a computer geek.


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.

Re:More "Cookie Monster" Hysteria (1)

VGPowerlord (621254) | more than 7 years ago | (#17290632)

It's not really a good idea calling them CGI parameters, as they're sent with every request whether or not there's a CGI script at the other end. This is what goes in web server logs and why your web server logs list things like Referrer and Browser.

Re:More "Cookie Monster" Hysteria (1)

Doc Ruby (173196) | more than 7 years ago | (#17290880)

It's "Common Gateway Interface". Even when there's no CGI script to consume them, they're part of the CGI environment generated by the HTTP server. And "CGI" is a familiar term, especially to people who could use interpretation of this hysterical article.

want a cookie (0, Offtopic)

erbbysam (964606) | more than 7 years ago | (#17290236)

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.

Cookie Dangers... (0, Flamebait)

neax (961176) | more than 7 years ago | (#17290326)

"A Cookie is a Sometimes Food". Do not overuse; may cause drowsiness, fatigue or a fat ass.

Cookies (4, Informative)

KermodeBear (738243) | more than 7 years ago | (#17290492)

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.

Let's discuss something new (3, Informative)

claes (25551) | more than 7 years ago | (#17290536)

Firefox 2 includes the new WHATWG-specified client-side persistent storage [whatwg.org] . However, some argue it is critically flawed [dreamhost.com] . Learn the arguments now and we can discuss this further on Slashdot in 2010!

Re:Let's discuss something new (1)

Pichu0102 (916292) | more than 7 years ago | (#17290710)

Are we allowed to use those arguments we learned when the dupe comes round, or do we have to wait until 2010?

Re:Let's discuss something new (1)

claes (25551) | more than 7 years ago | (#17291090)

You better wait. In 2007 we will argue about Google and Ipod every day, Slashdot will be too busy for dupes on persistent storage until 2010.

Is it a telling comment (1)

dmatos (232892) | more than 7 years ago | (#17290736)

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.

Stupid article.... no mention of session cookies.. (1)

BarnabyWilde (948425) | more than 7 years ago | (#17290774)

...outdated

Cookie Expiry (1)

ebob9 (726509) | more than 7 years ago | (#17290888)

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.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?