HTML5的安全風險詳析

關於HTML5存在的安全風險你瞭解多少?下面YJBYS小編為大家詳細解析一下HTML5的安全風險!希望對大家有所幫助!

　　一、CORS攻擊

CORS-CrossOrigin Resources Sharing，也即跨源資源共享，它定義了一種瀏覽器和伺服器互動的方式來確定是否允許跨域請求。它是一個妥協，有更大的靈活性，但比起簡單地允許所有這些的要求來說更加安全。簡言之，CORS就是為了讓AJAX可以實現可控的跨域訪問而生的。

　　一、從SOP到CORS

SOP就是Same Origin Policy同源策略，指一個域的文件或指令碼，不能獲取或修改另一個域的文件的屬性。也就是Ajax不能跨域訪問，我們之前的Web資源訪問的根本策略都是建立在SOP上的。它導致很多web開發者很痛苦，後來搞出很多跨域方案，比如JSONP和flash socket。如下圖所示：

後來出現了CORS-CrossOrigin Resources Sharing，也即跨源資源共享，它定義了一種瀏覽器和伺服器互動的方式來確定是否允許跨域請求。它是一個妥協，有更大的靈活性，但比起簡單地允許所有這些的要求來說更加安全。簡言之，CORS就是為了讓AJAX可以實現可控的跨域訪問而生的。示意如下圖所示：

現在W3C的官方文件目前還是工作草案，但是正在朝著W3C推薦的方向前進。不過目前許多現代瀏覽器都提供了對它的支援。

伺服器端對於CORS的支援，主要就是通過設定Access-Control-Allow-Origin來進行的。如果瀏覽器檢測到相應的設定，就可以允許Ajax進行跨域的訪問。例如：

Access–Control-Allow-Origin

應用CORS的系統目前包括、GoogleCloudStorage API等，主要是為開放平臺向第三方提供訪問的能力。

　　二、CORS帶來的風險

CORS非常有用，可以共享許多內容，不過這裡存在風險。因為它完全是一個盲目的協議，只是通過HTTP頭來控制。

它的風險包括：

1、HTTP頭只能說明請求來自一個特定的域，但是並不能保證這個事實。因為HTTP頭可以被偽造。

所以未經身份驗證的跨域請求應該永遠不會被信任。如果一些重要的功能需要暴露或者返回敏感資訊，應該需要驗證Session ID。

2、第三方有可能被入侵

舉一個場景，FriendFeed通過跨域請求訪問Twitter，FriendFeed請求tweets、提交tweets並且執行一些使用者操作，Twitter提供響應。兩者都互相相信對方，所以FriendFeed並不驗證獲取資料的有效性，Twitter也針對Twitter開放了大部分的功能。

但是當如果Twitter被入侵後：

FriendFeed總是從Twitter獲取資料，沒有經過編碼或者驗證就在頁面上顯示這些資訊。但是Twitter被入侵後，這些資料就可能是有害的。

或者FriendFeed被入侵時：

Twitter響應FriendFeed的請求，例如發表Tweets、更換使用者名稱甚至刪除賬戶。當FriendFeed被入侵後，攻擊者可以利用這些請求來篡改使用者資料。

所以對於請求方來說驗證接收的資料有效性和服務方僅暴露最少最必須的功能是非常重要的。

3、惡意跨域請求

即便頁面只允許來自某個信任網站的請求，但是它也會收到大量來自其他域的跨域請求。.這些請求有時可能會被用於執行應用層面的DDOS攻擊，並不應該被應用來處理。

例如，考慮一個搜尋頁面。當通過'%'引數請求時搜尋伺服器會返回所有的記錄，這可能是一個計算繁重的要求。要擊垮這個網站，攻擊者可以利用XSS漏洞將JavaScript指令碼注入某個公共論壇中，當用戶訪問這個論壇時，使用它的瀏覽器重複執行這個到伺服器的搜尋請求。或者即使不採用跨域請求，使用一個目標地址包含請求引數的影象元素也可以達到同樣的目的。如果可能的話，攻擊者甚至可以建立一個WebWorker執行這種攻擊。這會消耗伺服器大量的資源。

有效的解決辦法是通過多種條件遮蔽掉非法的請求，例如HTTP頭、引數等。

4、內部資訊洩漏

假定一個內部站點開啟了CORS，如果內部網路的使用者訪問了惡意網站，惡意網站可以通過COR(跨域請求)來獲取到內部站點的內容。

5、針對使用者的攻擊

上面都是針對伺服器的攻擊，風險5則針對使用者。比方說，攻擊者已經確定了你可以全域訪問的頁面上存在SQL注入漏洞。 攻擊者並不是直接從它們的系統資料庫中獲取資料，他們可能會編寫一個JavaScript資料採集指令碼，並在自己的網站或者存在XSS問題的網站上插入這段指令碼。當受害者訪問含有這種惡意JavaScript指令碼的網站時，它的瀏覽器將執行鍼對“”的SQL注入攻擊，採集所有的資料併發送給攻擊者。檢查伺服器日誌顯示是受害人執行了攻擊，因為除了來自Referrer的HTTP頭一般沒有其他日誌記錄。受害者並不能說他的`系統被攻破，因為沒有任何任何惡意軟體或系統洩漏的痕跡。

　　三、攻擊工具

　　四、防禦之道

1、不信任未經身份驗證的跨域請求，應該首先驗證Session ID或者Cookie。

2、對於請求方來說驗證接收的資料有效性，服務方僅暴露最少最必須的功能。

3、通過多種條件遮蔽掉非法的請求，例如HTTP頭、引數等。

　　二、Web Storage攻擊

HTML5支援WebStorage，開發者可以為應用建立本地儲存，儲存一些有用的資訊。例如LocalStorage可以長期儲存，而且存放空間很大，一般是5M，極大的解決了之前只能用Cookie來儲存資料的容量小、存取不便、容易被清除的問題。這個功能為客戶端提供了極大的靈活性。

　　一、WebStorage簡介

HTML5支援WebStorage，開發者可以為應用建立本地儲存，儲存一些有用的資訊。例如LocalStorage可以長期儲存，而且存放空間很大，一般是5M，極大的解決了之前只能用Cookie來儲存資料的容量小、存取不便、容易被清除的問題。這個功能為客戶端提供了極大的靈活性。

　　二、攻擊方式

LocalStorage的API都是通過JavaScript提供的，這樣攻擊者可以通過XSS攻擊竊取資訊，例如使用者token或者資料。攻擊者可以用下面的指令碼遍歷本地儲存。

if(th){

for(I in localStorage) {

(i);

(tem(i));

}

}

同時要提一句，LocalStorage並不是唯一暴露本地資訊的方式。我們現在很多開發者有一個不好的習慣，為了方便，把很多關鍵資訊放在全域性變數裡，例如使用者名稱、密碼、郵箱等等。資料不放在合適的作用域裡會帶來嚴重的安全問題，例如我們可以用下面的指令碼遍歷全域性變數來獲取資訊。

for(iin window) {

obj=window[i];

if(obj!=null||obj!=undefined)

var type =typeof(obj);

if(type=="object"||type=="string") {

(“Name:”+i);

try {

my = JSON.stringify(obj);

(my);

} catch(ex) {}

}

}

　　三、攻擊工具

HTML5dump的定義是“JavaScriptthat dump all HTML5 local storage”，它也能輸出HTML5 SessionStorage、全域性變數、LocalStorage和本地資料庫儲存。

Shell of the Future是一個反向WebShell處理器，它利用HTML5的跨站請求來劫持會話。

　　四、防禦之道

對於WebStorage攻擊的防禦措施是：

1、資料放在合適的作用域裡

例如使用者sessionID就不要用LocalStorage儲存，而需要放在sessionStorage裡。而使用者資料不要儲存在全域性變數裡，而應該放在臨時變數或者區域性變數裡。

2、不要儲存敏感的資訊

因為我們總也無法知道頁面上是否會存在一些安全性的問題，一定不要將重要的資料儲存在WebStorage裡。

　　三、WebSQL攻擊

資料庫安全一直是後端人員廣泛關注和需要預防的問題。但是自從HTML5引入本地資料庫和WebSQL之後，前端開發對於資料庫的安全也必須要有所瞭解和警惕。WebSQL的安全問題通常表現為兩個部分。

　　一、WebSQL安全風險簡介

資料庫安全一直是後端人員廣泛關注和需要預防的問題。但是自從HTML5引入本地資料庫和WebSQL之後，前端開發對於資料庫的安全也必須要有所瞭解和警惕。WebSQL的安全問題通常表現為兩個部分：

第一種是SQL注入：和本地資料庫一樣，攻擊者可以通過SQL注入點來進行資料庫攻擊。

另外一方面，如果Web App有XSS漏洞，那麼本地資料很容易洩漏，可以想想本地資料庫裡儲存了使用者最近交易記錄或者私信的情況。

　　二、WebSQL安全風險詳析

1、SQL注入

例如我們有一個URL為http:/，它接收了一個id引數來進行本地資料庫查詢並輸出，對應的SQL語句為“select name from user where id = 1”。

但是針對這個簡單的SQL查詢，攻擊者可以構造一個虛假的輸入資料“1 or 1 = 1”，那麼我們的SQL語句將變為“select name from user where id = 1 or 1 = 1”。這就相當糟糕了，因為1=1這個條件總是成立的，那麼這條語句將遍歷資料庫user表裡的所有記錄並進行輸出。

利用這種方式，攻擊者可以構造多種攻擊的SQL語句，來操縱使用者的本地資料庫記錄。

2、XSS與資料庫操縱

在有XSS漏洞的情況下，攻擊者獲取本地資料需要如下幾個步驟：

1)獲取JavaScript資料庫物件

2)獲取SQLite上的表結構

3)獲取資料表名

4)操作資料

例如如下指令碼完整的實現了上面的步驟，我在Chrome控制檯裡執行即可得到使用者本地資料庫的表名，利用這個表名攻擊者可以用任何SQL語句來完成攻擊。

var dbo;

var table;

var usertable;

for(i in window) {

obj = window[i];

try {

if(=="Database"){

dbo = obj;

saction(function(tx){

uteSql('SELECT name FROM sqlite_master WHERE type='table'', [], function(tx,results) {

table = results;

},null);

});

}

} catch(ex) {}

}

if(th > 1)

usertable = (1);

　　三、防禦之道

針對WebSQL攻擊，我們有如下方法預防：

1) 檢查輸入型別，過濾危險字元

我們需要保證輸入型別符合預期，例如上面的id引數一定是數字型別;同時過濾掉危險的關鍵字和符號，像PHP裡addslashes這個函式的作用一樣。

2) 在SQL語句中使用引數形式

SQL語句是可以用引數形式的，例如

executeSql("SELECTname FROM stud WHERE id=" + input_id)

這種字串拼接的形式並不安全，可以換為

executeSql("SELECTname FROM stud WHERE id=?“, [input_id]);)

這樣能保證引數的輸入符合設定的型別。

3)謹慎對待每一次SQL操作