Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Security

The Dangers of Improper Cookie Use 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."
This discussion has been archived. No new comments can be posted.

The Dangers of Improper Cookie Use

Comments Filter:
  • Obligatory (Score:2, Informative)

    by Archangel Michael ( 180766 ) on Monday December 18, 2006 @02:29PM (#17289418) Journal
    Me Like Cookies! - Cookie Monster
  • by brunascle ( 994197 ) on Monday December 18, 2006 @02:31PM (#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.
  • Maybe (Score:3, Informative)

    by RAMMS+EIN ( 578166 ) on Monday December 18, 2006 @02:53PM (#17289776) Homepage Journal
    ``"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 (Score:4, Informative)

    by Dracos ( 107777 ) on Monday December 18, 2006 @02:53PM (#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.

  • by blindcoder ( 606653 ) <slashdot@wegwerf.anderdonau.de> on Monday December 18, 2006 @02:55PM (#17289798) Homepage
    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.
  • by Yazeran ( 313637 ) on Monday December 18, 2006 @02:57PM (#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.
  • by J0nne ( 924579 ) on Monday December 18, 2006 @03:13PM (#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:Worse and worse (Score:5, Informative)

    by afidel ( 530433 ) on Monday December 18, 2006 @03:14PM (#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.
  • by Doc Ruby ( 173196 ) on Monday December 18, 2006 @03:21PM (#17290166) Homepage Journal
    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.
  • Cookies (Score:5, Informative)

    by KermodeBear ( 738243 ) on Monday December 18, 2006 @03:44PM (#17290492) Homepage
    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.
  • by claes ( 25551 ) on Monday December 18, 2006 @03:47PM (#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!
  • by Anonymous Coward on Monday December 18, 2006 @03:59PM (#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.

  • by aaronl ( 43811 ) on Monday December 18, 2006 @06:39PM (#17293310) Homepage
    On my Firefox 2 (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20060601 Firefox/2.0 (Ubuntu-edgy)), I definitely have that option. It's in Preferences, Privacy, "Keep Until: ask me every time".
  • Re:Cookies (Score:5, Informative)

    by The MAZZTer ( 911996 ) <.moc.liamg. .ta. .tzzagem.> on Monday December 18, 2006 @06:53PM (#17293538) Homepage

    If I see a nonsensical combination of upper and lower case letters, numbers, and punctuation, especially if it has one or two equal signs tacked onto the end, I immediately think "base64!".

    Firefox allows base64 encoding for data: urls, and we can use this to make a quick-n-dirty base64 decoder. Just type data:text/plain;base64, (including the comma) into the address bar and paste the string on the end, and hit enter to see the decoded string (if it's plaintext).

    Base64 is not encryption and it should not be used where encryption is needed (or in this case, a secure DATABASE). Base64 is a way to represent binary data in plaintext without having to worry about data corruption due to non-binary safe programs.

  • by evilviper ( 135110 ) on Monday December 18, 2006 @07:39PM (#17294146) Journal
    In my opinion Addblock and Flashblock are the two most important reasons to use Firefox.

    If you use NoScript (which you should to stop dangerous and irritating javascript code), you don't need Flashblock.

This file will self-destruct in five minutes.

Working...