Follow Slashdot blog updates by subscribing to our blog RSS feed

 



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:
  • Old News (Score:5, Funny)

    by MyLongNickName ( 822545 ) on Monday December 18, 2006 @02:28PM (#17289382) Journal
    Cookie misuse has been chronicled here [bbc.co.uk]
  • by Anonymous Coward on Monday December 18, 2006 @02:28PM (#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: (Score:2, Funny)

      by Anonymous Coward
      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!
      • 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.
    • by Kelson ( 129150 ) * on Monday December 18, 2006 @03:01PM (#17289880) Homepage Journal
      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!

    • by BLACKtactx ( 1015407 ) on Monday December 18, 2006 @03:46PM (#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.
    • by fm6 ( 162816 ) on Monday December 18, 2006 @05:34PM (#17292160) Homepage Journal

      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.

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

      You kids and your web...

      I want my gopher sites back.
    • by sco08y ( 615665 )
      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.

      Screw the web, I'm posting over a gopher gateway.
  • Obligatory (Score:2, Informative)

    Me Like Cookies! - Cookie Monster
  • If you think that's bad try going to a page like this [scriptingmagic.com] with IE after copying and pasting sensitive information.
    • Re: (Score:3, Funny)

      by geobeck ( 924637 )

      From that site:

      Did you know that by default Internet Explorer allows any website to obtain the current contents of your clipboard? This isn't a bug, Microsoft considers it a feature.

      Damn Microsoft for removing features in IE7!

  • 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.
    • 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?
      • 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.
      • 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.
    • by Xzzy ( 111297 ) <sether@@@tru7h...org> on Monday December 18, 2006 @02:57PM (#17289820) Homepage
      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.
    • by jgc7 ( 910200 ) on Monday December 18, 2006 @04:00PM (#17290722) Homepage
      > 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.

      • Security is not absolute, and there's lots of ways to get a cookie besides having root somewhere along a person's network uplinks. Security IS about making things harder for people, and I controversially (though pretty firmly) believe that locking a cookie down to an IP address is a great idea. It may not work as well for people behind a large corporate network, or a rooted machine behind the same NAT as a victim user, but sending a request out from a specific IP address is usually a big step to overcome
    • bingo. that's why i store the IP address along with the session ID in the database.
      That has the convenient side effect of making your site not work for AOL users or anyone else behind a balanced proxy
    • why not send a few random characters in a hidden field as an nounce and a md5sum of the session ID and the nounce, then you can stop most sesion hijacks as well. Give the nonce and checksum a reasonable sounding name and no one would connect the dots.
    • Great, another site I can't visit when I'm at The Client From Hell. TCFH, among other endearing practices, sets DHCP leases to expire every fifteen minutes. As you might imagine, this makes downloading large patches or updates "eventful"...
  • by fermion ( 181285 ) on Monday December 18, 2006 @02:36PM (#17289526) Homepage Journal
    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: (Score:2, Informative)

      by blindcoder ( 606653 )
      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: (Score:3, Interesting)

        by FireFury03 ( 653718 )
        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: (Score:3, Informative)

          by aaronl ( 43811 )
          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: (Score:3, Informative)

      by Yazeran ( 313637 )

      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
      • 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 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 trackin
        • Re: (Score:3, Insightful)

          by schwaang ( 667808 )
          Not only that, but site list is sorted without grouping by domain. So o.nytimes.com is far away in the list from video.nytimes.com. That's just lame.
      • Re: (Score:3, Informative)

        by evilviper ( 135110 )
        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.
    • Re: (Score:3, Interesting)

      by nekokoneko ( 904809 )

      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.c [mozillazine.org]

    • by Arkhan ( 240130 )
      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 cook

    • 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,
    • Re: (Score:3, Funny)

      by PCM2 ( 4486 )
      Sort of like trying to find a windows virus filter only to find that the virus filter has infected you.

      Where the hell do you live? Soviet Russia?

  • by Dekortage ( 697532 ) on Monday December 18, 2006 @02:41PM (#17289604) Homepage

    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?

  • by blindcoder ( 606653 ) <slashdot@wegwerf.anderdonau.de> on Monday December 18, 2006 @02:49PM (#17289728) Homepage
    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?
    • 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>...
      • I can't believe how common that still mistake still is.
        It's not like it's hard to use the following instead:
        link [slashdot.org]
        You do know that window.popup() works in IE only, right?
        • by J0nne ( 924579 )

          I didn't know IE had a built-in function called popup (I use Firefox for everything). popup(element) in my example would be a custom function that uses window.open to open the href attribute of the anchor.

          I just used that example for clarity, and to make a point that it pisses me off too that some web developers don't want to go through the trouble of providing a real link to images while there's no technical reason to not do that.

          Besides, I wouldn't even write the thing inline, but use something like

  • by fullphaser ( 939696 ) on Monday December 18, 2006 @02:51PM (#17289742) Homepage
    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.
    • by Shados ( 741919 )
      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...
    • You can't just say they are dangerous and to stop accepting them in general,

      Yes I can.

      and you can't just tell the web designer to stop using them, for the primary reason that it isn't practical.

      Yes I can, and yes it is.

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

    • 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 (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 Dracos ( 107777 )

      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

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

      It already is...

      For images, you have Adblock.

      For cookies, it's "Cookie Button" https://addons.mozilla.org/firefox/1247/ [mozilla.org]

      Or in the status bar: https://addons.mozilla.org/firefox/1328/ [mozilla.org]

  • The Real Danger of Improper Cookie Use:

    Two Words: Crumby Milk

    Thank You and Tip your Servers.

  • by Illusion2269 ( 959341 ) on Monday December 18, 2006 @03:07PM (#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!
  • 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 ad
    • 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
  • 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.
    • 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.
      • 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.
        • Since you know what CGI stands for, perhaps you should read the description of it as well. Emphasis added by me.

          The Common Gateway Interface, or CGI, is a standard for external gateway programs to interface with information servers such as HTTP servers.

          Webservers don't create the CGI environment unless they're calling a CGI script. Some webserver modules duplicate the CGI environment as well: SSI and PHP as examples.

          The referrer is an HTTP header, specifically the Referer [w3.org] header. I also mentioned Browser

    • ``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.''

      Or by exploiting your browser cache. For example, by sending you a file that causes a unique i
    • 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.

      I think the article was just addressing the fact that web usage across totally different sites (including Slashdot) is tracked (w/ the help of cookies) by the likes of doubleclick. That in itself is of interest, and many users still don't realize that it goes on. If that's news to a reader of t

      • Except blocking them won't help their privacy, for the reasons I mentioned. Because it's not just DoubleClick. And it's not just cookies.

        The article addressed several things, some of which were wrong. Hence my post.
        • TFA points out something many people don't know which materially affects their privacy. The fact that there are other ways of gathering the same data does not negate the fact that cookies are actively used for that purpose, nor is it "hysteria" to point out such use of cookies. Hence my reply to your post.
  • 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.
    • Re:Cookies (Score:5, Informative)

      by The MAZZTer ( 911996 ) <(megazzt) (at) (gmail.com)> 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.

    • Explain to him why he should use a salt in his data:

      http://en.wikipedia.org/wiki/Syntactic_sugar#Synta ctic_salt [wikipedia.org]

      Really, it's not *that* hard, people...
  • 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!
    • Are we allowed to use those arguments we learned when the dupe comes round, or do we have to wait until 2010?
      • by claes ( 25551 )
        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.
  • 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

A morsel of genuine history is a thing so rare as to be always valuable. -- Thomas Jefferson

Working...