HTML5安全風險詳析之一：CORS攻擊

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

1、從SOP到CORS

SOP就是Same Origin Policy同源策略，指一個域的文檔或腳本，不能獲取或修改另外一個域的文檔的屬性。也就是Ajax不能跨域訪問，咱們以前的Web資源訪問的根本策略都是創建在SOP上的。它致使不少web開發者很痛苦，後來搞出不少跨域方案，好比JSONP和flash socket。以下圖所示：

後來出現了CORS-CrossOrigin Resources Sharing，也即跨源資源共享，它定義了一種瀏覽器和服務器交互的方式來肯定是否容許跨域請求。它是一個妥協，有更大的靈活性，但比起簡單地容許全部這些的要求來講更加安全。簡言之，CORS就是爲了讓AJAX能夠實現可控的跨域訪問而生的。具體能夠參見個人這篇文章《HTML5安全：CORS（跨域資源共享）簡介》。示意以下圖所示：

如今W3C的官方文檔目前仍是工做草案，可是正在朝着W3C推薦的方向前進。不過目前許多現代瀏覽器都提供了對它的支持。

服務器端對於CORS的支持，主要就是經過設置Access-Control-Allow-Origin來進行的。若是瀏覽器檢測到相應的設置，就能夠容許Ajax進行跨域的訪問。例如：

Access–Control-Allow-Origin: http://blog.csdn.net

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

2、CORS帶來的風險

CORS很是有用，能夠共享許多內容，不過這裏存在風險。由於它徹底是一個盲目的協議，只是經過HTTP頭來控制。

它的風險包括：

一、HTTP頭只能說明請求來自一個特定的域，可是並不能保證這個事實。由於HTTP頭能夠被僞造。

因此未經身份驗證的跨域請求應該永遠不會被信任。若是一些重要的功能須要暴露或者返回敏感信息，應該須要驗證Session ID。

二、第三方有可能被入侵

舉一個場景，FriendFeed經過跨域請求訪問Twitter，FriendFeed請求tweets、提交tweets而且執行一些用戶操做，Twitter提供響應。二者都互相相信對方，因此FriendFeed並不驗證獲取數據的有效性，Twitter也針對Twitter開放了大部分的功能。

可是當若是Twitter被入侵後：

FriendFeed老是從Twitter獲取數據，沒有通過編碼或者驗證就在頁面上顯示這些信息。可是Twitter被入侵後，這些數據就多是有害的。

或者FriendFeed被入侵時：

Twitter響應FriendFeed的請求，例如發表Tweets、更換用戶名甚至刪除帳戶。當FriendFeed被入侵後，攻擊者能夠利用這些請求來篡改用戶數據。

因此對於請求方來講驗證接收的數據有效性和服務方僅暴露最少最必須的功能是很是重要的。

三、惡意跨域請求

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

例如，考慮一個搜索頁面。當經過'%'參數請求時搜索服務器會返回全部的記錄，這多是一個計算繁重的要求。要擊垮這個網站，攻擊者能夠利用XSS漏洞將Javascript腳本注入某個公共論壇中，當用戶訪問這個論壇時，使用它的瀏覽器重複執行這個到服務器的搜索請求。或者即便不採用跨域請求，使用一個目標地址包含請求參數的圖像元素也能夠達到一樣的目的。若是可能的話，攻擊者甚至能夠建立一個WebWorker執行這種攻擊。這會消耗服務器大量的資源。

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

四、內部信息泄漏

假定一個內部站點開啓了CORS，若是內部網絡的用戶訪問了惡意網站，惡意網站能夠經過COR（跨域請求）來獲取到內部站點的內容。

五、針對用戶的攻擊

上面都是針對服務器的攻擊，風險5則針對用戶。比方說，攻擊者已經肯定了你能夠全域訪問的productsearch.php頁面上存在SQL注入漏洞。 攻擊者並非直接從它們的系統數據庫中獲取數據，他們可能會編寫一個JavaScript數據採集腳本，並在本身的網站或者存在XSS問題的網站上插入這段腳本。當受害者訪問含有這種惡意JavaScript腳本的網站時，它的瀏覽器將執行鍼對「productsearch.php」的SQL注入攻擊，採集全部的數據併發送給攻擊者。檢查服務器日誌顯示是受害人執行了攻擊，由於除了來自Referrer的HTTP頭通常沒有其餘日誌記錄。受害者並不能說他的系統被攻破，由於沒有任何任何惡意軟件或系統泄漏的痕跡。

3、攻擊工具

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

4、防護之道

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

二、對於請求方來講驗證接收的數據有效性，服務方僅暴露最少最必須的功能。

三、經過多種條件屏蔽掉非法的請求，例如HTTP頭、參數等。