在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，HTML5的本地存儲是使用localStorage對象將WEB數據持久化在本地。相比較而言HTML5本地存儲中每個域的存儲大小默認是5M，比起Cookie的4K要大的多。而且存儲和讀取數據的代碼極為簡練：
存儲數據Window.localStorage.setItem（key，value）
讀取數據Window.localStorage.getItem（key）
刪除數據項Window.localStorage.removeItem（key）
刪除所有數據Window.localStorage.clear（）
那么現在我們是否可以簡單的認為，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/框。
localStorage.setItem（“：USER：”，‘{“name”：{“value”：{“store”：{“recentFollowers”：{“value”：“name”}}}}}’）;
從這段代碼可以看出，Twitter會使用localStorage方法把一些個人數據存儲到本地，每次加載個人主頁面的時候就會從本地存儲取數據，然后由于Twitter忽略了對去除數據的嚴格過濾導致存儲的代碼會被當作HMTL編碼執行，進而發生跨站攻擊。
Twitter localStorage XSS 漏洞詳細信息可以查看：http://www.wooyun.org/bugs/ wooyun-2010-03075。雖然Twitter這個漏洞利用起來非常困難，但它再一次告訴我們本著一切輸入輸出都是有害的原則，要對數據進行嚴格的輸入輸出過濾。
（4） 容易遭受跨目錄攻擊
localStroage存儲方式不會像Cookie存儲一樣可以指定域中的路徑，在localStroage存儲方式中沒有域路徑的概念。也就是說，如果一個域下的任意路徑存在XSS漏洞，整個域下存儲的數據，在知道存儲名稱的情況下，都可以被獲取到。
假設下面兩個鏈接是使用localStorage來存儲數據：
http://h.example.com/xisigr
http://h.example.com/xhack
用戶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本地存儲的應用會越來越多。
上面從理論上分析了，“惡意代碼棲息的溫床”的可能性。從實際技術上的可行性也是非常簡單。下面是在本地留后門的核心代碼：
保存shellcode
function setShellCodz（codz）{
window.localStorage.setItem（“shellcodz”， codz）;}
執行shellcode
function getShellCodz（）{
eval（window.localStorage.getItem（“shellcodz”））;}
刪除shellcode
function delShellCodz（）{
window.localStorage.removeItem（“shellcodz”）;}
推薦閱讀
Tango或命名為Windows Phone 7.5 Refresh
Tango主要面向硬件性能不是很強大的低端手機。上周有報道稱，Tango將對手機硬件做出限制，例如規定RAM的大小為256MB。此外，微軟還計劃向采用WindowsPhone7.5“Mango”系統的中高端手機引入更多功能。 新浪科技訊 北>>>詳細閱讀
本文標題：HTML5本地存儲的安全性問題探討
地址：http://m.sdlzkt.com/a/xie/20111230/157684.html
網友點評
精彩導讀
科技快報
品牌展示