HTML5 Security Analysis: Local Storage

HTML5 Security Analysis: Local Storage

In the previous article HTML5 cross-origin message sending security analysis, we discussed cross-origin message transmission in html5. This article will show you another feature-local storage.

Local Storage

Local storage is also one of the new HTML5 features. It was first on Mozilla 1.5 and gradually accepted by HTML5 standards. Through the localStorage and sessionStorage objects in JavaScript, we can use this new feature of html5. Based on key-value matching, these JavaScript objects allow us to store, retrieve, and delete data.

In HTML5, local storage is a window attribute, including localStorage and sessionStorage. The difference between the two can be clearly identified by name. The former is always local, the latter is only accompanied by the session. Once the window is closed, it is useless. The two are used in the same way.

The following is an HTML5 application example. Using the new HTML5 local storage feature, we can use the "Show Data" button to retrieve Data stored in the database.

Let's take A look at the source of this Site. Assume that http: // localhost: 8383/is "application A". Sort it out:

Name: Application AOrigin: http://localhost:8383/

Click Show Data.

 

Expected results: we can access the data stored in the database by application.

Now I try to access the data stored in the database by application A from different sources.

Suppose this is application B, and the details are as follows:

Name: Application BOrigin: http://localhost/

Note that application B and application A have different port numbers and belong to different origins.

Click "Show Data.

 

When I click "Show Data", I obviously feel that the webpage does not respond because the applications are different from each other.

To make the experiment accurate, we will confirm it again. We run the same source application C as application.

Name: Application COrigin: http://localhost:8383/

Click "Show Data" and observe the results.

 

Well, we can access data from application C because it is the same as application.

Conclusion: The same code is used in the preceding applications, but some of them are different from each other. Inserting data into the database of application A fails because application B is different from application. The application C is the same source and accessed successfully.

Next, let's take a look at the potential attacks on HTML5 local storage.

Sensitive Data Storage

Developers may store sensitive data in their databases and are likely to find API keys or other sensitive data. If there is no physical access device, we can use the XSS vulnerability for exploitation. The following example describes how the localStorage object stores data. You can use a function to add a key-value pair as a parameter.

localStorage.setItem(“data”, “mydata”);

, We can see that Chrome stores the data path

 

Read data

localStorage.getItem(“data”);

Continue to read the data from the SQLite Database

 

 

Script Injection

The data in SQLite is not well filtered, which may cause script attacks. Let's take a simple example.

Store some data and then perform retrieval.

 

 

If the data is not properly filtered, the stored XSS vulnerability may occur. In the message box, enter

 

Click "Show Data" to view the result.

 

As we can see, a warning box is displayed on the webpage.

Summary

This article discusses how HTML5 local storage features work and how same-source policy restrictions are applied to data storage. Finally, let's take a look at the possible attacks. Let's look forward to the next article.