在上一篇文章《HTML5跨域消息發(fā)送安全性分析》中，我們討論了在HTML5下的跨域消息傳遞。本文將帶你去了解另外一個特性——本地存儲。

本地存儲

本地存儲也是HTML5的新特性之一，最開始是在Mozilla 1.5上的，后來漸漸被HTML5規(guī)范接受。通過JavaScript的localStorage和sessionStorage對象，我們可以使用HTML5的這個新特性。基于鍵值值匹配，這些JavaScript對象允許我們存儲，檢索和刪除數(shù)據(jù)。

在HTML5中，本地存儲是一個window的屬性，包括localStorage和sessionStorage，從名字應(yīng)該可以很清楚的辨認二者的區(qū)別，前者是一直存在本地的，后者只是伴隨著session，窗口一旦關(guān)閉就沒了，二者用法完全相同。

下面是一個HTML5應(yīng)用程序示例，使用HTML5新的本地存儲特性，我們可以使用 “Show Data”按鈕檢索存儲在數(shù)據(jù)庫中的數(shù)據(jù)。

我們先來看看這個站點的源，假設(shè)http://localhost:8383/為“應(yīng)用程序A”，整理一下：

Name: Application A

Origin: http://localhost:8383/

單擊“Show Data”按鈕

預(yù)期結(jié)果：我們能夠訪問應(yīng)用程序A存儲在數(shù)據(jù)庫中的數(shù)據(jù)。

現(xiàn)在嘗試通過不同源來訪問應(yīng)用程序A存儲在數(shù)據(jù)庫中的數(shù)據(jù)。

假設(shè)這是應(yīng)用程序B，下面為詳情：

Name: Application B

Origin: http://localhost/

注意了，應(yīng)用程序B與應(yīng)用程序A端口號不同，屬于不同源。

點擊“Show Data”按鈕。

當我點擊“Show Data”按鈕的時候，明顯感覺到網(wǎng)頁沒有反應(yīng)，這是因為應(yīng)用程序不同源。

為了實驗準確，我們再次進行確認。我們運行與應(yīng)用程序A同源的應(yīng)用程序C

Name: Application C

Origin: http://localhost:8383/

點擊“Show Data”按鈕，觀察結(jié)果

很好，我們能夠從應(yīng)用程序C訪問到數(shù)據(jù)，因為它與應(yīng)用程序A同源。

結(jié)論，在上面的幾個應(yīng)用程序中都使用相同的代碼，但有些不同源。將數(shù)據(jù)插入應(yīng)用程序A的數(shù)據(jù)庫中，由于應(yīng)用程序B與應(yīng)用程序A不同源，所以訪問失敗。而應(yīng)用程序C同源，成功訪問。

接下來，我們來看看HTML5本地存儲可能遭受的攻擊

敏感數(shù)據(jù)存儲

開發(fā)者可能在其數(shù)據(jù)庫中存儲敏感數(shù)據(jù)，很可能被找出API KEY或者其他敏感數(shù)據(jù)。如果沒有物理訪問設(shè)備，我們可以使用XSS漏洞進行利用。下面這個例子描述了localStorage對象如何存儲數(shù)據(jù)，我們可以使用函數(shù)添加鍵值對作為參數(shù)。

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

下圖中，我們可以看到Chrome將數(shù)據(jù)存儲的路徑

讀取數(shù)據(jù)

localStorage.getItem(“data”);

繼續(xù)從SQLite數(shù)據(jù)庫讀取這些數(shù)據(jù)

腳本注入

沒有很好過濾SQLite中的數(shù)據(jù)，可能會導(dǎo)致腳本攻擊，下面我們來看一個簡單的例子。

先存儲一些數(shù)據(jù)，然后進行檢索。

如果這些數(shù)據(jù)沒有被很好的過濾，這可能會導(dǎo)致存儲XSS漏洞。這一次我們在消息框中輸入

<img src=’X’ onerror=alert(1);> 

點擊“Show Data”按鈕，看看結(jié)果

如我們所見，網(wǎng)頁彈出警告框。

總結(jié)

本文討論了HTML5本地存儲特性是如何工作的，以及同源策略限制是如何應(yīng)用于數(shù)據(jù)存儲的。最后我們對其中可能發(fā)生的攻擊進行了解，期待下一篇文章吧。