Introducing the Invulnerable Evercookie 332
An anonymous reader writes "Using eight different techniques and locations, a 'security' guy has developed a cookie that is very, very hard to delete. If just one copy of the cookie remains, the other locations are rebuilt. My favorite storage location is in 'RGB values of auto-generated, force-cached PNGs using HTML5 Canvas tag to read pixels (cookies) back out' — awesome."
Not hard to beat at first glance. (Score:4, Informative)
evercookie is written in JavaScript and additionally uses a SWF (Flash) object for the Local Shared Objects and PHP for the server-side generation of cached PNGs.
[...]
If a user gets cookied on one browser and switches to another browser as long as they still have the Local Shared Object cookie, the cookie will reproduce in both browsers.
Well, the site's EXAMPLE failed on my box. That's NoScript at work. If you use BetterPrivacy (another FF extension), it removes the LSO at browser shutdown.
YMMV
Re:Not hard to beat at first glance. (Score:3, Informative)
Failed for me too.
The text displayed, an error was generated, then "The page cannot be displayed"
Internet Explorer cannot open the Internet site http://samy.pl/evercookie/ [samy.pl]. Operation aborted
Re:Remember? (Score:5, Informative)
Well, html is unable to save session information. So you need cookies for that. There is no other reliable and non-user-unfriendly alternative.
When you 'log in', you are given a cookie, which the page reads and uses to identify you. That's one of the more common 'useful' uses for cookies.
Cookies can also store small amounts of data in them (ever been to a website which tells you "Pick Language" and then lets you "[ ] Always remember this choice"? That's also a cookie.
And last but not least, they're good at identifying you so that other adverts (on other sites) note the cookie and are able to link your presence on Site A to the one on Site B then data-mine
Re:Not hard to beat at first glance. (Score:3, Informative)
... soon to be followed by the evercookiemonster by same "security" guy, right?
http://farm1.static.flickr.com/119/299000164_4d7398dbf6.jpg?v=0 [flickr.com]
Re:"That's the great thing about evercookie" (Score:3, Informative)
No kidding. It was bad enough in the days when there were all sorts of cookies throwing illegal characters (wildcards, normally path-related characters, etc) in the filename to prevent deletion. Particularly when the "cookie" itself didn't actually have data, they just tried to stick every bit of info into the fucking filename.
And of course there have been all the programs that hide "registration" data - or even, sometimes, "never work again" flags - somewhere deep in randomly-named registry keys as pure numeric values to be next-to-impossible to hunt down unless you know precisely what you're looking for. I remember one of these that had a bomb in it designed to fuck up the program if you changed your system clock more than a few hours (non-permanent license, paranoid schizophrenic fucktards at the company afraid that people would reset their clock to keep the program running...Hi SPSS!) Boy was my coworker surprised when she went overseas and tried to resync her laptop to local time.
But just wait, pretty soon someone's going to take the Everlasting Gobstopper Cookie, add in a more malicious payload, and we're off to the races. There's no possible justification for this project.
Re:"That's the great thing about evercookie" (Score:5, Informative)
it's not his research either. this has already been observed in the wild and already reported by ars technica.
http://arstechnica.com/tech-policy/news/2010/08/ad-firm-sued-for-allegedly-re-creating-deleted-cookies.ars
the advertisement company got already sued for it.
force-cached PNG's (Score:2, Informative)
So basically if you clear your cache, as well as your cookies/LSO's all should be well. At least at the end of the browser session.
Another YAYdiots to the Mozilla Developers, for scrapping one of the best features in FF: Clearing the History window on exit. So sad you need an extra extension now what, as this story demonstrates again, should be an integral and visible part of any browser.
At least Linux users can... (Score:5, Informative)
Re:Do these people have no concept of web design? (Score:3, Informative)
Programmers don't always equate to good designers. And good designers probably aren't good programmers. (Exceptions exist, but true for the most part).
Otherwise, we wouldn't have terms like "programmer art".
Re:The PNG thing isn't that unexpected (Score:3, Informative)
That's something different.
Re:Not hard to beat at first glance. (Score:2, Informative)
Use PrefBar [mozdev.org].
Cost: One horizontal toolbar's worth of vertical space.
Benefit: User-configurable single-click access to toggle checkboxes that control not only Javashit, Flash, and Java, but also automatic geolocation reporting, image loading (tired of seeing 10 copies of an almost-NSFW 300x480 .gif of bouncing boobs that some idiot used as a .sig when all you want to do is read about how his turbocharger install went?), colors (hate that web designer who put red text on a blue swirly background?), cookies, send-Referrrer-ID, a dropdown to select a user-agent (lookin' at you ExpertSexChange, who hides the answer from everyone but the Google Crawler), and more.
Re:At least Linux users can... (Score:1, Informative)
So can Windows users. The command might look a little different, but still completely doable.
Re:Not hard to beat at first glance. (Score:1, Informative)
NoScript (and NotScript, which I use in Chromium these days) should have an option to tenp-allow JS from the domain you're on automaticaly. I think it would get n00b-proof for non-techies to use it.
It (NoScript) does.
You can Temp allow all, or just temp allow certain domains. Close your browser and they are blocked again on your next visit.
Re:Not hard to beat at first glance. (Score:4, Informative)
running browser in Sandboxie would also do the trick
Doesn't work as advertised (Score:2, Informative)
Re:Not hard to beat at first glance. (Score:4, Informative)
Thanks for the reminder. Last time I looked into sandboxie, it did not support 64 bit operating systems, which is does now. Using it is a lot easier on the CPU and more convenient than creating a VM with a Web browser in it and rolling it back when done for that session.
With Unity mode on VMWare Workstation or the equivalent on Windows 7 and XP Mode, keeping a Web browser in a sandbox isn't that much work, especially if one is having to use a backlevel version of IE for some websites that force IE6, and even does JS/VBScript checks to check for a changed UserAgent field.
Re:Not hard to beat at first glance. (Score:3, Informative)
evercookie is written in JavaScript and additionally uses a SWF (Flash) object for the Local Shared Objects and PHP for the server-side generation of cached PNGs. [...] If a user gets cookied on one browser and switches to another browser as long as they still have the Local Shared Object cookie, the cookie will reproduce in both browsers. Well, the site's EXAMPLE failed on my box. That's NoScript at work.
Same here. But what if this script were used by a website for which you need or want to enable scripting?
If you use BetterPrivacy (another FF extension), it removes the LSO at browser shutdown.
Which helps, but doesn't solve the problem, since the cookie is also stored in a cached PNG's RGB values and in your browser history, and in a bunch of HTML5 related storage options that your browser may or may not support and betterprivacy may or may not have been updated to take care of.
Re:Not hard to beat at first glance. (Score:3, Informative)
Firefox 4 Beta 6 with AdBlock+ and changing %homepath%\Application Data\Macromedia from folder to a system file stops this. You do have to set Firefox to clear all browsing data upon exit. Tested also flushing the browser data while browser being open and it works as well. The site can't keep 'evercookies' on my machine. However changing Macromedia folder from folder to file will break a few websites that use heavily flash.
Re:Not hard to beat at first glance. (Score:3, Informative)
Not having NoScript, but FlashBlock, some interesting observations - that indicate a bug in FF even.
The cookie stored in the history data is not updated. I haven't poked through my history but guess I have several stored there now, and evercookie only reads the first it finds. Hence that's the oldest one always. A bug in the storage algorithm.
More seriously, it seems there is data leaking from Private Browsing to normal browsing mode, while Private Browsing shouldn't leave any traces of the session. When in Private Browsing the history storage fails (FF doesn't keep history so it should fail), the rest works fine.
However when switching back from Private to normal mode (with the evercookie web site still open in a tab, reopening when switching to normal mode), the pngData mechanism still shows the last cookie ID from the Private browsing session! If private is as private as it should be, this should not be possible. I'm not in the mood to start poking deeper, not too familiar with JS anyway, I bet there are /.ers that can do that much better than me. This to me appears to be a bug in FF (version 3.6.10 for me).
Re:Not hard to beat at first glance. (Score:3, Informative)
Actually it doesn't perfectly support 64 bit [sandboxie.com], but it will run and probably do a good enough job. You might also want to try Shadow Defender [shadowdefender.com]. It has fully supported 64 bit for a long time. It is paid software, but I think there are some free versions floating around if you have a parrot on your shoulder.
Re:force-cached PNG's (Score:3, Informative)