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存儲在本地的全部信息。 數據庫
攻擊者也能夠簡單的使用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本地存儲的應用會愈來愈多。
上面從理論上分析了,「惡意代碼棲息的溫牀」的可能性。從實際技術上的可行性也是很是簡單。下面是在本地留後門的核心代碼: 瀏覽器