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操作