在HTML5本地儲存出現以前，WEB資料儲存的方法已經有很多，比如HTTP Cookie，IE userData，Flash Cookie，Google Gears。其實再說細點，瀏覽WEB的歷史記錄也算是本地儲存的一種方式。到目前為止，HTML5本地儲存方式已經獲得了廣泛的支援，其中支援的瀏覽器包括：IE 8+、FF 3.5+、Safari 4+、Chrome 4+、Opera 10.5+，手機平臺包括iPhone 2+和Android 2+。最新的HTML5本地儲存規範文件，可以線上檢視
http://dev.w3.org/html5/webstorage/

      HTML5本地儲存的前身就是Cookie，通過使用localStorage物件將WEB資料持久留存在本地。相比較而言，HTML5本地儲存中每個域的儲存大小預設是5M，比起Cookie的4K要大的多。而且儲存和讀取資料的程式碼極為簡練：

      那麼現在我們是否可以簡單的認為，HTML5儲存已經可以代替Cookie儲存了呢？還有這種新的儲存方式在實際應用中帶來了哪些新的安全風險呢？帶著這些疑問我們來進行下面的討論。

      （1） 是否可以代替Cookie

      瀏覽器使用Cookie進行身份驗證已經好多年，既然現在localStorage儲存空間那麼大，是否可以把身份驗證的資料直接移植過來呢？目前來看，把身份驗證資料使用localStorage進行儲存還不太成熟。我們知道，通常可以使用XSS漏洞來獲取到Cookie，然後用這個Cookie進行身份驗證登入。後來為了防止通過XSS獲取Cookie資料，瀏覽器支援了使用HTTPONLY來保護Cookie不被XSS攻擊獲取到。而目前localStorage儲存沒有對XSS攻擊有任何抵禦機制，一旦出現XSS漏洞，那麼儲存在localStorage裡的資料就極易被獲取到。
如果一個網站存在XSS漏洞，那麼攻擊者注入如下程式碼，就可以獲取使用localStorage儲存在本地的所有資訊。

 
      攻擊者也可以簡單的使用localStorage.removeItem(key)和localStorage.clear()對儲存資料進行清空。

     （2） 不要儲存敏感資訊

      從（1）中知道，從遠端攻擊角度來看，localStorage儲存的資料容易被XSS攻擊獲取，所以不宜把身份驗證資訊或敏感資訊用localStorage儲存。而從本地攻擊角度來看， localStorage自身的儲存方式和儲存時效並不宜儲存敏感資訊。

      五大瀏覽器現在都已經支援以localStorage方式進行儲存，其中Chrome,Opera,Safari這三款瀏覽器中都有了檢視本地儲存的功能模組。但是不同瀏覽器對localStorage儲存方式還是略有不同的。以下是五大瀏覽器localStorage儲存方式：

      
      通過上面的描述可以看出，除了Opera瀏覽器採用BASE64加密外（BASE64也是可以輕鬆解密的），其他瀏覽器均採用明文儲存資料。

      另一方面，在資料儲存的時效上，localStorage並不會像Cookie那樣可以設定資料存活的時限，只要使用者不主動刪除，localStorage儲存的資料將會永久存在。

      根據以上對儲存方式和儲存時效的分析，建議不要使用localStorage方式儲存敏感資訊，那怕這些資訊進行過加密。

     （3） 嚴格過濾輸入輸出

      對於本地儲存，為了方便載入資料，常常會把資料儲存在本地，等再次載入時，直接從本地讀取資料顯示在網頁上。在某些情況下，在localStorage儲存中寫入或讀取資料的時候，如果資料沒有經過輸入輸出嚴格過濾，那麼這些資料極可能被作為HTML程式碼進行解析，從而產生XSS攻擊。

      Twitter就發生過localStorage XSS漏洞。此漏洞觸發的條件是，在Twitter的個人主頁上執行以下儲存程式碼後，每次再打開個人主頁時就會彈出/xss/框。

      從這段程式碼可以看出，Twitter會使用localStorage方法把一些個人資料儲存到本地，每次載入個人主頁面的時候就會從本地儲存獲取資料，然後由於Twitter忽略了對去除資料的嚴格過濾，導致儲存的程式碼會被當作HMTL編碼執行，進而發生跨站攻擊。

      有關Twitter localStorage XSS 漏洞詳的細資訊可以檢視：http://www.wooyun.org/bugs/ wooyun-2010-03075。雖然Twitter這個漏洞利用起來非常困難，但它再一次告訴我們：本著一切輸入輸出都是有害的原則，要對資料進行嚴格的輸入輸出過濾。

     （4） 容易遭受跨目錄攻擊

      localStroage儲存方式不會像Cookie儲存一樣可以指定域中的路徑，在localStroage儲存方式中沒有域路徑的概念。也就是說，如果同一個域下的任意路徑存在XSS漏洞，整個域下儲存的資料在知道儲存名稱的情況下都可以被獲取到。

      假設下面兩個連結是使用localStorage來儲存資料：

      使用者xisigr和xhack各自的blog連結雖然屬於同一個域，但卻有不同的路徑，一個路徑為xisigr，另一個路徑為xhack。假設xisigr使用者發現自己的路徑下存在儲存型XSS漏洞，那麼就可以在自己的blog中加入獲取資料程式碼，其中核心程式碼為localStorage.getItem(“name”)。xhack使用者並不需要登入blog,他只要訪問http://h.example.com/xisigr，本地儲存資料就會被獲取到。

     （5） 容易遭受DNS欺騙攻擊

      Google在沒有使用HTML5本地儲存前，是使用Google Gears方式來進行本地儲存的。那時Google Gears就遭到過DNS欺騙攻擊。Google Gears支援離線儲存，可以把Gmail,WordPresss這樣的網站資料以SQLite資料庫的形式儲存下來，以後使用者就可以對儲存的網站資料進行離線讀取或刪除操作。如果攻擊者發動DNS欺騙攻擊，那麼就可以注入本地資料庫，獲取資料或者留下永久的後門，造成對使用者持久的危害。Google Gears所遭受的DNS欺騙攻擊方式在HTML5本地儲存上也是同樣有效的。

     （6） 惡意程式碼棲息的溫床

      在第六點中給出“惡意程式碼棲息的溫床”這個小標題有些誇大的效果。其實這裡想說的是，HTML5本地儲存在空間上和時間上都將成為今後儲存的趨勢，料想“惡意程式碼們”自然會大雁南飛轉移棲息到這張溫床上。

      那麼，何為HTML5本地儲存的空間和時間呢？空間這裡指的是儲存空間，比起Cookie 4K空間的微小來說，HTML5的localStroage方法預設就可以使瀏覽器儲存5M空間可以說是博大，而Safari瀏覽器可以支援到500M更加讓HTML5儲存霸氣外露。時間上，隨著HTML5技術日漸成熟，除了各大瀏覽器廠商爭先在自己的產品中支援HTML5外，一些大應用軟體廠商也對其信賴有加。比如2011年11月Adobe宣佈放棄手機上的FLASH， 而由HTML5全面取而代之。隨著時間的推移，HTML5大步流星的前行速度也會越來越快，也會使得用到HTML5本地儲存的應用會越來越多。
 上面從理論上分析了 “惡意程式碼棲息的溫床”的可能性。而從實際技術上的可行性也非常簡單。下面是在本地留後門的核心程式碼：

     以上分析，均出自天融信TopLAB前沿安全實驗室的研究，希望藉此文讓HTML5的本地儲存安全問題得到大家的廣泛重視。HTML5非常精彩，但也存在風險，我們要做的工作還很多。