一、從SOP到CORS
SOP就是Same Origin Policy同源策略，指一個域的文檔或腳本，不能獲取或修改另一個域的文檔的屬性。也就是Ajax不能跨域訪問，我們之前的Web資源訪問的根本策略都是建立在SOP上的。它導(dǎo)致很多web開發(fā)者很痛苦，后來搞出很多跨域，比如JSONP和flash socket。如下圖所示：
后來出現(xiàn)了CORS-CrossOrigin Resources Sharing，也即跨源資源共享，它定義了一種和交互的方式來確定是否允許跨域請求。它是一個妥協(xié)，有更大的靈活性，但比起簡單地允許所有這些的要求來說更加安全。簡言之，CORS就是為了讓AJAX可以實現(xiàn)可控的跨域訪問而生的。具體可以參見我的這篇文章《安全：CORS(跨域資源共享)簡介》。示意如下圖所示：
現(xiàn)在W3C的官方文檔目前還是工作草案，但是正在朝著W3C推薦的方向前進。不過目前許多現(xiàn)代瀏覽器都提供了對它的支持。
服務(wù)器端對于CORS的支持，主要就是通過設(shè)置-Control-Allow-Origin來進行的。如果瀏覽器檢測到相應(yīng)的設(shè)置，就可以允許Ajax進行跨域的訪問。例如：
Access–Control-Allow-Origin: http://blog.csdn.net
應(yīng)用CORS的系統(tǒng)目前包括Face.com、GoogleCloudStorage API等，主要是為開放平臺向第三方提供訪問的能力。
二、CORS帶來的風險
CORS非常有用，可以共享許多內(nèi)容，不過這里存在風險。因為它完全是一個盲目的協(xié)議，只是通過HTTP頭來控制。
它的風險包括：
1、HTTP頭只能說明請求來自一個特定的域，但是并不能保證這個事實。因為HTTP頭可以被偽造。
所以未經(jīng)身份驗證的跨域請求應(yīng)該永遠不會被信任。如果一些重要的功能需要暴露或者返回敏感信息，應(yīng)該需要驗證 ID。
2、第三方有可能被
舉一個場景，通過跨域請求訪問，F(xiàn)riendFeed請求tweets、提交tweets并且執(zhí)行一些用戶操作，Twitter提供響應(yīng)。兩者都互相相信對方，所以FriendFeed并不驗證獲取數(shù)據(jù)的有效性，Twitter也針對Twitter開放了大部分的功能。
但是當如果Twitter被入侵后：
FriendFeed總是從Twitter獲取數(shù)據(jù)，沒有經(jīng)過編碼或者驗證就在頁面上顯示這些信息。但是Twitter被入侵后，這些數(shù)據(jù)就可能是有害的。
或者FriendFeed被入侵時：
Twitter響應(yīng)FriendFeed的請求，例如發(fā)表Tweets、更換用戶名甚至刪除賬戶。當FriendFeed被入侵后，攻擊者可以利用這些請求來篡改用戶數(shù)據(jù)。
所以對于請求方來說驗證接收的數(shù)據(jù)有效性和服務(wù)方僅暴露最少最功能是非常重要的。
3、惡意跨域請求
即便頁面只允許來自某個信任網(wǎng)站的請求，但是它也會收到大量來自其他域的跨域請求。。這些請求有時可能會被用于執(zhí)行應(yīng)用層面的攻擊，并不應(yīng)該被應(yīng)用來處理。
例如，考慮一個搜索頁面。當通過'%'參數(shù)請求時搜索服務(wù)器會返回所有的記錄，這可能是一個計算繁重的要求。要擊垮這個網(wǎng)站，攻擊者可以利用XSS漏洞將Javascript腳本注入某個公共論壇中，當用戶訪問這個論壇時，使用它的瀏覽器重復(fù)執(zhí)行這個到服務(wù)器的搜索請求。或者即使不采用跨域請求，使用一個目標地址包含請求參數(shù)的也可以達到同樣的目的。如果可能的話，攻擊者甚至可以創(chuàng)建一個WebWorker執(zhí)行這種攻擊。這會消耗服務(wù)器大量的資源。
有效的解決辦法是通過多種條件屏蔽掉非法的請求，例如HTTP頭、參數(shù)等。
4、內(nèi)部信息泄漏
假定一個內(nèi)部站點開啟了CORS，如果內(nèi)部網(wǎng)絡(luò)的用戶訪問了惡意網(wǎng)站，惡意網(wǎng)站可以通過COR(跨域請求)來獲取到內(nèi)部站點的內(nèi)容。
5、針對用戶的攻擊
上面都是針對服務(wù)器的攻擊，風險5則針對用戶。比方說，攻擊者已經(jīng)確定了你可以全域訪問的productsearch.php頁面上存在SQL注入漏洞。 攻擊者并不是直接從它們的系統(tǒng)中獲取數(shù)據(jù)，他們可能會編寫一個JavaScript數(shù)據(jù)采集腳本，并在自己的網(wǎng)站或者存在XSS問題的網(wǎng)站上插入這段腳本。當受害者訪問含有這種惡意JavaScript腳本的網(wǎng)站時，它的瀏覽器將執(zhí)行針對“productsearch.php”的，采集所有的數(shù)據(jù)并發(fā)攻擊者。檢查服務(wù)器日志顯示是受害人執(zhí)行了攻擊，因為除了來自Referrer的HTTP頭一般沒有其他日志記錄。受害者并不能說他的系統(tǒng)被攻破，因為沒有任何任何惡意軟件或系統(tǒng)泄漏的痕跡。
三、攻擊工具
Shell of the Future是一個反向WebShell，它利用HTML5的跨站請求來劫持會話。
四、防御之道
1、不信任未經(jīng)身份驗證的跨域請求，應(yīng)該首先驗證Session ID或者Cookie。
2、對于請求方來說驗證接收的數(shù)據(jù)有效性，服務(wù)方僅暴露最少最必須的功能。
3、通過多種條件屏蔽掉非法的請求，例如HTTP頭、參數(shù)等。