Quote:

Front-end persistence is to permanently store data in the front end, making it difficult to delete or recover data after deletion. Stored data can be understood as a kind of “zombie data”. Here is a front-end persistence method — Evercookie.

I. Introduction to EverCookie

Evercookie is a set of jsApi developed by Samy Kamkar (American white hat hacker and security researcher). Its purpose is to persist cookies. Even if users clear standard cookies, Flash cookies, etc., they can still get the set data. And restore the cookie that was cleared (narrow, essentially restoring all dimensions, a rewrite action).

Ii. Principle of Evercookie:

The principle of Evercookie is very simple, that is, data is written into each dimension of the browser, and then read out from each dimension when it is obtained. No matter how the user cleans it, as long as there is data in one dimension, the data can be obtained. The advantages are as follows: 1. The storage dimension is very large, and it is difficult for users to clean it. 2. When fetching data, it will restore the cleared data, which is really a zombie cookie.

The following describes the dimensions of storage and the ways and ideas of reading data:

Evercookie stores data in the following dimensions:

1. Standard HTTP Cookie:

Evercookie will store data in document. Cookie, when obtaining directly can be obtained, there is nothing to say, this part of the data is relatively easy to clear, such as browser to clear cookies, JS script Settings, etc., share about cookie two points:

  • HTTP requests have their own cookies in the local domain and all cookies in the root domain. This is the source of CSRF.
  • Js setting cookies by default in the current domain and the current path, cookies are generally used across paths, be sure to set the path field;

2. The Flash cookies:

Evercookie provides a flash file, when the use of data will be stored in the flash local object, only delete the corresponding flash storage file can be cleared, the flash file decomcompiled, obtained AS source code:

shared = sharedobject.getlocal("evercookie"); if (everdata) { var newdata = everdata.split("="); var str = shared.data.cookie; var results = str.split("&"); var i = 0; while (i < results.length) { var elem = results[i].split("="); if (elem[0] ! = newdata[0]) { everdata = everdata + ("&" + results[i]); } i++; } shared.data.cookie = everdata.replace("\\", "\\\\"); shared.flush(); } flash.external.ExternalInterface.call("_evercookie_flash_var", shared.data.cookie);Copy the code

When storing data, call the interface of swfObject to store it, you can see the JS source code:

this.evercookie_lso = function (name, value) { var div = document.getElementById("swfcontainer"), flashvars = {}, params = {}, attributes = {}; if (div===null || div === undefined || ! div.length) { div = document.createElement("div"); div.setAttribute("id", "swfcontainer"); document.body.appendChild(div); } if (value ! == undefined) { flashvars.everdata = name + "=" + value; } params.swliveconnect = "true"; attributes.id = "myswf"; attributes.name = "myswf"; // Write to flash swfObject.embedswf (_ec_baseurl + _ec_asseturi + _EC_SWF_file_name, "swfContainer ", "1", "1", "9.0.0", false, flashvars, params, attributes); };Copy the code

And will use flash after flash loading. External. Your externalinterface.call (” _evercookie_flash_var “, Shared.data. cookie) calls the javascript method under window _evercookie_flash_var to pass data to JS, which in js case reads flash data.

var _global_lso;
function _evercookie_flash_var(cookie) {
    _global_lso = cookie;

    // remove the flash object now
    var swf = document.getElementById("myswf");
    if (swf && swf.parentNode) {
        swf.parentNode.removeChild(swf);
    }
}

window._evercookie_flash_var = _evercookie_flash_var;Copy the code

 

3. LocalStorage: localStorage is a new feature of HTML5, can permanently store data in the local, access to no window limit, the same domain can be obtained, you can call localStorage interface to clear, browser directly clear cache data can also clear;

4. SessionStorage: similar to localStorage, the life cycle is the current dialogue, the browser closed after opening again disappear;

5. GlobalStorage: similar to localStorage, it is permanently stored locally and is supported only by Firefox48 or later.

6. OpenDatabase: HTML5 WebSQL database, can be understood as a strengthening of Local Storage and Session Storage, used to manipulate a large number of structured data, due to various browser implementation reasons, WebSQL specification has been abandoned;

7.IndexedDB: a built-in database that stores data permanently. Compared to WebSQL, IndexedDB is more like a NoSQL database, while WebSQL is more like a relational database that uses SQL to query data.

8. Image cache data storage:

Evercookie makes use of the image cache for storage, a brief introduction:

  1. Write data according to the key to construct an HTTP request, the value through the document.cookie to the background;
  2. The background generates a PNG image of 200 pixels (maximum 600 characters) according to the value passed in the cookie in the way of generating one pixel for every three digits, and sets the cache to the front end;
  3. When reading data, the same HTTP request is constructed according to the key, and the cached picture is obtained and the corresponding pixels are parsed out by canvas to recover data.

It can be seen that the maximum data supported by an EverCookieJS image storage is 600 characters. Secondly, this method must be parsed using canvas, which requires compatibility. This is obviously a way to clear the browser cache directly.

9. The ETag storage:

ETag storage also depends on the background. The main idea is that IF the server responds to a request for the first time by setting the ETag, the browser will automatically set an if-none-match for the second time, so IF the data value is stored in the ETag, When fetching data, go directly to the background of the link IF- none-match field, similar to the PNG image cache above.

10. Web Cache: Look at the idea of evercookie is an enhancement of HTTP cookies, equivalent to setting an expiration time for cookies through the background, the script provided by Evercookie feels wrong.

11. Silvelright client storage:

Silvelright is also a local storage method that can store data directly locally, similar to Flash, which can be accessed across browsers, requiring silverlight plug-in installation. Evercookie provides a compilation file that can be used to access data through Sliverlight. Sliverlighr is not familiar with evercookie.

12. Java application local storage: Through the use of JNLP call Java Applet ability to store data in a local file, a large amount of code is not detailed analysis, decomcompiled JAR package and class file, put in the file can be interested to see.

13.IE userData storage:

UserData is a storage method unique to Internet Explorer. It can store data locally using XML or HTML tags. Generally, IE5 or higher is supported

<! DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <style> .userData{ behavior: url(#default#userdata) } </style> </head> <body> <div id="userData" class="userData"></div> </body> <script> var persistDom = document.getElementById("userData"); function set(name, value){ persistDom.setAttribute(name, value); persistDom.save(name); } function get(name){ persistDom.load(name); return persistDom.getAttribute(name) } set("devinn", 1990); window.console && console.log(get("devinn")); //1990 </script> </html>Copy the code

14. Window. Name:

Window. name is a special property of window that can be set. It has two characteristics:

  • Window. name will not disappear after refreshing the page.
  • Iframe jumps from one SRC to another to fetch contentWindow.name unchanged;

Evercookie takes advantage of the above, as long as the page is not refreshed, the page will not change randomly clean (strange is put in the iframe clear cache can clear TT).

Window. name is often used for cross-domain communication.

Iframe SRC SRC window.name does not change when jumping from a.html to b.html. So if a domain page wants to fetch data across domains, you can set an iframe to point SRC to the domain page that wants to fetch data (this page puts the data to be passed in window.name, ps: SRC = “SRC”; SRC = “SRC”; SRC = “SRC”; SRC = “SRC”; SRC = “SRC”; SRC = “SRC”;

There are two key points for cross-domain acquisition:

  • Must be placed in iframe;
  • You must use the name attribute (consoled contentWindow, several other attributes failed);

15.<a> tag history access state store:

The <a> tag in the browser has a feature that the state of the same browser will become the “visited” state after being visited. Generally, the state will disappear only after the browser browsing history is cleared. Evercookie takes advantage of this for storage.

Here’s the idea:

  1. Construct the tag and default visited style (A: Visited) as the access verification value;
  2. Construct HTTP requests that address the set key and each character of the value (multiple HTTP, number is the length of the value);
  3. Write data makes one access to the HTTP request above by constructing iframe;
  4. Read data with a key and a character to construct a link to give tag href, get tag style and default visited style
  5. Directly assign the HTTP request to the href of the tag, get if the style is the default visited style, this HTTP request has been visited, solve the character;

Note: The value set in 2 is an encode value, the last step to solve the character assembly after decode to obtain the original value, the implementation of Evercookie is very interesting, interested can take a look.

16. HSTS storage:

HSTS is generally used to prevent man-in-the-middle attacks. In simple terms, if the HTTP response of a domain name is set to strict-transport-security, the browser will directly convert the HTTP request to HTTPS when the domain name sends another HTTP request (you can set prelist, The first request can also be converted to HTTPS directly on the browser side.

  1. Apply for multiple domain names (e.g. 32), construct the service, set (port note set to 443 or 80), clear, query;
  2. Set the value to a binary integer, for example, 1101. The bit of 1 is sent to the corresponding first domain name. Set strict-transport-security, and the bit of 0 is cleared.
  3. The server returns whether it is HTTP or not. The corresponding bit is set to 0, and the corresponding binary value is the obtained result.

Go straight to the implementation:

<? php //header('Access-Control-Allow-Origin: *'); $is_ssl = ! empty($_SERVER['HTTPS']) && $_SERVER['HTTPS'] ! == 'off' || $_SERVER['SERVER_PORT'] == 443; if(isset($_GET['SET'])){ if($is_ssl){ header('Strict-Transport-Security: max-age=31536000'); header('Content-type: image/png'); echo base64_decode('iVBORw0KGgoAAAANSUhEUgAAAAgAAAAJCAIAAACAMfp5AAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8YQUAAAAJcEhZcwAADsMAAA7DA cdvqGQAAAAYSURBVBhXY/z//z8DNsAEpTHAkJJgYAAAo0sDD8axyJQAAAAASUVORK5CYII='); }else{ $redirect = "https://".$_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI']; header("Location: $redirect"); } die(); } if(isset($_GET['DEL'])){ if($is_ssl){ header('Strict-Transport-Security: max-age=0'); }else{ $redirect = "https://".$_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI']; header("Location: $redirect"); } die(); } if($is_ssl){ header('Content-type: image/png'); // some white pixel echo base64_decode('iVBORw0KGgoAAAANSUhEUgAAAAgAAAAJCAIAAACAMfp5AAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8YQUAAAAJcEhZcwAADsMAAA7DA cdvqGQAAAAYSURBVBhXY/z//z8DNsAEpTHAkJJgYAAAo0sDD8axyJQAAAAASUVORK5CYII='); die(); }else{ header('X-PHP-Response-Code: 404', true, 404); }? >Copy the code

The disadvantages of HSTS storage mode are large. You need to apply for multiple domain names and send multiple requests. Evercookie turns off HSTS storage by default.

 

Evercookie reads data:

The idea of Evercookie is not to return results directly after obtaining data from any dimension, but to take out all the set dimensions for optimal solution search, which can prevent data anomalies caused by tampering of part of the data; There is also a problem, because a lot of data acquisition is asynchronous, such as database, e-tag, etc., so the data acquisition is not immediate, there is a part of the waiting time.

Iii. Application:

Using Evercookie for persistence keeps our data resident in the browser. Not only can it collect all kinds of browser data, but more importantly, it can be resurrected even after the user has cleaned browser cookies. For example, it can be used to establish a long-term effective identity identifier for the browser, and analyze the user’s historical information by using the identifier report data to determine whether an operation is benign or malicious, which plays a great role in the front-end risk control system.

Iv. Summary:

Evercookie simply means to store data and fetch data. There is not much in it. What is more brilliant is the dimension and method of accessing data, all kinds of strange tricks. At the same time, it should be noted that some methods, such as HSTS, will bring a lot of overhead, data acquisition is an asynchronous process and there will be time overhead, so try to adjust the application according to the business scenario.