evercookie is a javascript API available that produces
extremely persistent cookies in a browser. Its goal
is to identify a client even after they've removed standard
cookies, Flash cookies (Local Shared Objects or LSOs), and
others.
evercookie accomplishes this by storing the cookie data in
several types of storage mechanisms that are available on
the local browser. Additionally, if evercookie has found the
user has removed any of the types of cookies in question, it
recreates them using each mechanism available.
Specifically, when creating a new cookie, it uses the
following storage mechanisms when available:
- Standard HTTP Cookies
- HTTP Strict Transport Security (HSTS) Pinning
- Local Shared Objects (Flash Cookies)
- Silverlight Isolated Storage
- Storing cookies in RGB values of auto-generated, force-cached
PNGs using HTML5 Canvas tag to read pixels (cookies) back out
- Storing cookies in Web History
- Storing cookies in HTTP ETags
- Storing cookies in Web cache
- window.name caching
- Internet Explorer userData storage
- HTML5 Session Storage
- HTML5 Local Storage
- HTML5 Global Storage
- HTML5 Database Storage via SQLite
- HTML5 IndexedDB
- Java JNLP PersistenceService
- Java CVE-2013-0422 exploit (applet sandbox escaping)
TODO: adding support for:
- Caching in HTTP Authentication
- Using Java to produce a unique key based off of NIC info
- Google Gears
Got a crazy idea to improve this? Email me!
EXAMPLE
Cookie found:uid = currently not set
Click to create an evercookie. Don't worry, the cookie is a
random number between 1 and 1000, not enough for me to track
you, just enough to test evercookies.
Now, try deleting this "uid" cookie anywhere possible, then
or
evercookie is written in JavaScript and contains portions
in Java, SWF/ActionScript (Flash) and C# (Silverlight).
Some backend pieces in PHP, but also available in Node.js and Django.
Get the latest source from github: http://github.com/samyk/evercookie
FAQ
What is the point of evercookie?
Evercookie is designed to make persistent data just that, persistent. By
storing the same data in several locations that a client can access, if
any of the data is ever lost (for example, by clearing cookies), the data
can be recovered and then reset and reused.
Simply think of it as cookies that just won't go away.
PRIVACY CONCERN! How do I stop websites from doing this?
Great question. So far, I've found that using Private Browsing
in Safari will stop ALL evercookie methods after a browser restart.
What if the user deletes their cookies?
That's the great thing about evercookie. With all the methods available,
currently thirteen, it only takes one cookie to remain for most, if not all,
of them to be reset again.
For example, if the user deletes their standard HTTP cookies, LSO data,
and all HTML5 storage, the PNG cookie and history cookies will still
exist. Once either of those are discovered, all of the others will
come back (assuming the browser supports them).
Why not use EFF's Panopticlick?
Panopticlick is an awesome idea, however the uniqueness really only
helps in consumer machines and typically not systems running in a
business or corporation. Typically those systems are virtually
identical and provide no difference in information where a home
user's laptop would. Evercookie is meant to be able to store the
same unique data a normal cookie would.
Does this work cross-browser?
If a user gets cookied on one browser and switches to another browser,
as long as they still have the Flash Local Shared Object cookie, the
Silverlight Isolated Storage, the Java JNLP PersistenceService or the
Java CVE-2013-0422 exploit cookie, the cookie should reproduce in both
browsers.
Does the client have to install anything?
No, the client simply uses the website without even knowing about the
persistent data being set, just as they would use a website with standard
HTTP cookies.
Does the server have to install anything?
The server must at least have access to the JavaScript evercookie file.
Additionally, to use Local Shared Object (Flash Cookies) storage, the
evercookie.swf file must be present, and to use the auto-generated PNG
caching, standard caching and ETag storage mechanisms, PHP must be
installed and evercookie_(png|etag|cache).php must be on the server.
All of these are available in the download.
Is evercookie open source?
Yes, evercookie is open source. The code is in readable format without
any obfuscation. Additionally, the PHP files are open source as is the
FLA (Flash) code used to generate the SWF Flash object. You can compile
the Flash object yourself or use the pre-compiled version (evercookie.swf).
How does the PNG caching work?
When evercookie sets a cookie, it accesses evercookie_png.php with a special
HTTP cookie, different than the one used for standard session data. This
special cookie is read by the PHP file, and if found, generates a PNG file
where all the RGB values are set to the equivalent of the session data to
be stored. Additionally, the PNG is sent back to the client browser with
the request to cache the file for 20 years.
When evercookie retrieves this data, it deletes the special HTTP cookie,
then makes the same request to the same file without any user information.
When the PHP script sees it has no information to generate a PNG with, it
returns a forged HTTP response of "304 Not Modified" which forces the web
browser to access its local cache. The browser then produces the cached
image and then applies it to an HTML5 Canvas tag. Once applied, evercookie
reads each pixel of the Canvas tag, extracting the RGB values, and thus
producing the initial cookie data that was stored.
How does the Web History storage work
When evercookie sets a cookie, assuming the Web History caching is enabled,
it Base64 encodes the data to be stored. Let's assume this data is "bcde"
in Base64. Evercookie then accesses the following URLs in the background:
google.com/evercookie/cache/b
google.com/evercookie/cache/bc
google.com/evercookie/cache/bcd
google.com/evercookie/cache/bcde
google.com/evercookie/cache/bcde-
These URLs are now stored in history.
When checking for a cookie, evercookie loops through all the possible Base64
characters on google.com/evercookie/cache/, starting with "a" and moving up,
but only for a single character. Once it sees a URL that was accessed, it
attempts to brute force the next letter. This is actually extremely fast
because no requests are made to theserver. The history lookups are simply
locally in JavaScript using the CSS History Knocker. Evercookie knows it has
reached the end of the string as soon as it finds a URL that ends in "-".
USAGE
<script type="text/javascript" src="evercookie.js"></script>
<script>
var ec = new evercookie();
// set a cookie "id" to "12345"
// usage: ec.set(key, value)
ec.set("id", "12345");
// retrieve a cookie called "id" (simply)
ec.get("id", function(value) { alert("Cookie value is " + value) });
// or use a more advanced callback function for getting our cookie
// the cookie value is the first param
// an object containing the different storage methods
// and returned cookie values is the second parameter
function getCookie(best_candidate, all_candidates)
{
alert("The retrieved cookie is: " + best_candidate + "\n" +
"You can see what each storage mechanism returned " +
"by looping through the all_candidates object.");
for (var item in all_candidates)
document.write("Storage mechanism " + item +
" returned: " + all_candidates[item] + "<br>");
}
ec.get("id", getCookie);
// we look for "candidates" based off the number of "cookies" that
// come back matching since it's possible for mismatching cookies.
// the best candidate is most likely the correct one
</script>
