瀏覽器同源策略安全研究綜述?

羅 武 ,沈晴霓 ,吳中海 ,吳鵬飛 ,董春濤 ,夏玉堂

1(北京大學(xué) 信息科學(xué)技術(shù)學(xué)院,北京 100871)

2(北京大學(xué) 軟件與微電子學(xué)院,北京 100871)

3(軟件工程國(guó)家工程研究中心(北京大學(xué)),北京 100871)

瀏覽器的出現(xiàn),源自于互聯(lián)網(wǎng)的發(fā)展.20 世紀(jì)80 年代的互聯(lián)網(wǎng)內(nèi)容只有純文本和純文件,1989 年提出的萬(wàn)維網(wǎng)為互聯(lián)網(wǎng)增加了內(nèi)容布局、文本裝飾與媒體等資源.豐富的互聯(lián)網(wǎng)內(nèi)容催生了瀏覽器的出現(xiàn),早期的瀏覽器包括了Cello,Mosaic 以及當(dāng)時(shí)最受歡迎的Netscape Navigator.隨著網(wǎng)頁(yè)動(dòng)態(tài)性與面向用戶(hù)的需求,Netscape Navigator 于1994 年增加了“magic cookie”來(lái)區(qū)分用戶(hù),并且在1995 年提出了改變網(wǎng)絡(luò)世界的兩個(gè)新特性:JavaScript 和文檔對(duì)象模型(document object model,簡(jiǎn)稱(chēng)DOM).DOM 的提出,使得網(wǎng)頁(yè)JavaScript 代碼能夠利用對(duì)應(yīng)API 來(lái)訪問(wèn)HTML 文檔的所有元素與屬性、文檔交互觸發(fā)的事件以及cookie 等資源.同時(shí),互聯(lián)網(wǎng)內(nèi)容的發(fā)展,使得HTML 文檔能夠更進(jìn)一步地引入額外的資源,如其他網(wǎng)頁(yè)文檔或者媒體,這些資源又有自己對(duì)應(yīng)的cookie,DOM 與JavaScript 等元素.JavaScript 與HTML 文檔的發(fā)展,使得瀏覽器必須要提供一種方法來(lái)安全地實(shí)現(xiàn)代碼與資源之間的交互.

瀏覽器的同源策略(same-origin policy,簡(jiǎn)稱(chēng) SOP)被提出來(lái)定義瀏覽器加載的互聯(lián)網(wǎng)資源的安全邊界.Netscape 的工程師們?cè)?995 年發(fā)行的NetscapeNavigator 2 瀏覽器中實(shí)現(xiàn)了同源策略.2011 年發(fā)布的RFC6454標(biāo)準(zhǔn)明確了同源策略中“源”(origin)的定義[1],此后的W3C 標(biāo)準(zhǔn)[2]與HTML5 標(biāo)準(zhǔn)[3]也對(duì)同源策略進(jìn)行了描述與定義.同源策略逐漸成為瀏覽器的基礎(chǔ)訪問(wèn)控制策略,諸如Chrome,Firefox,Safari 與Edge 等主流瀏覽器都實(shí)現(xiàn)了同源策略[4,5].

同源策略將瀏覽器加載的所有資源都用一個(gè)稱(chēng)為“源”(origin)的字符串定義,該字符串由資源的協(xié)議(scheme)、服務(wù)器主機(jī)(host)和端口(port)組成,并且確保一個(gè)網(wǎng)頁(yè)中的代碼只能訪問(wèn)具有相同源的互聯(lián)網(wǎng)資源.同源策略的策略實(shí)施發(fā)生在網(wǎng)頁(yè)文檔(稱(chēng)之為frame)訪問(wèn)Web 資源前,這些資源包括其他frame 的cookie,DOM與JavaScript 以及Web 服務(wù)器的網(wǎng)絡(luò)響應(yīng)等.考慮用戶(hù)訪問(wèn)了一個(gè)銀行網(wǎng)站并在該網(wǎng)站上登錄了自己賬號(hào),銀行網(wǎng)站由于廣告等其他需求可能包含了來(lái)自第三方的 frame.在沒(méi)有同源策略的情況下,第三方 frame 的JavaScript 代碼將能夠在用戶(hù)不知情的情況下直接訪問(wèn)銀行網(wǎng)站的資源,比如獲取用戶(hù)的銀行卡信息與余額,甚至執(zhí)行轉(zhuǎn)賬操作.而實(shí)施了同源策略的瀏覽器將會(huì)在第三方frame 訪問(wèn)銀行網(wǎng)站資源前進(jìn)行同源檢查,由于主客體屬于不同源,瀏覽器將會(huì)拒絕該訪問(wèn).同源策略的檢查將能保證一個(gè)Web 應(yīng)用的資源(包含該Web 應(yīng)用上用戶(hù)的隱私數(shù)據(jù))不會(huì)被其他(不同源)Web 應(yīng)用所訪問(wèn),從而實(shí)現(xiàn)基于源的Web 資源隔離.

同源策略的重要性,使得其從誕生到現(xiàn)在一直都被認(rèn)為是瀏覽器安全的基石.但是,同源策略在互聯(lián)網(wǎng)演化過(guò)程中也暴露出來(lái)了諸多安全問(wèn)題,包括同源策略規(guī)則不足所引起的安全威脅、跨域與跨源機(jī)制的安全威脅以及內(nèi)存攻擊下的同源策略安全等.

同源策略的規(guī)則是瀏覽器安全中最受關(guān)注的部分之一,完備而有效的同源策略規(guī)則是Web 應(yīng)用安全與用戶(hù)隱私安全的基礎(chǔ).然而隨著Web 的發(fā)展,Web 應(yīng)用提出了更多的需求,這使得同源策略規(guī)則在提供這些便利性的同時(shí)損失了部分安全性.同源策略允許一個(gè)frame 引入與執(zhí)行第三方腳本,并且第三方腳本被視為與該frame相同的源而具備相同權(quán)限[6?8];同源策略賦予同源不同frame 相同的權(quán)限,但由于不同的URL 路徑、在網(wǎng)頁(yè)中的不同位置以及不同的歷史行為,同源的不同frame 也需要被賦予不同權(quán)限[9,10];同源策略還允許發(fā)送任意跨源網(wǎng)絡(luò)請(qǐng)求,Web 服務(wù)器端不充分的網(wǎng)絡(luò)請(qǐng)求授權(quán)檢查將會(huì)導(dǎo)致資源泄漏[11,12].攻擊者可以利用這些同源策略規(guī)則的不足來(lái)訪問(wèn)超出其權(quán)限之外的資源.

跨域與跨源通信機(jī)制是Web 應(yīng)用之間實(shí)現(xiàn)資源共享的主要方式,但也是攻擊者用來(lái)繞過(guò)同源策略限制以惡意訪問(wèn)跨域或跨源資源的突破口之一.瀏覽器所提供的跨域與跨源通信API 包含了document.domain 與postMessage.除此之外,Web 應(yīng)用還可以利用JSON-P 與跨域資源共享(cross-origin resource sharing,簡(jiǎn)稱(chēng)CORS)機(jī)制來(lái)完成跨域與跨源通信.利用這些API 與協(xié)議的脆弱性[13?16],攻擊者將可以繞過(guò)同源策略的限制來(lái)訪問(wèn)跨源的資源.

內(nèi)存攻擊是破壞軟件安全的重要攻擊手段,瀏覽器作為軟件也不可避免地面臨著內(nèi)存攻擊.瀏覽器引入了JavaScript 引擎(包括解釋器與即時(shí)編譯器)來(lái)執(zhí)行網(wǎng)頁(yè)的JavaScript 代碼.JavaScript 代碼相當(dāng)于JavaScript 引擎的輸入,惡意的輸入有可能利用JavaScript 引擎中的漏洞,從而實(shí)現(xiàn)惡意代碼注入[17?19]、代碼重用攻擊[20,21]以及僅數(shù)據(jù)攻擊[22,23].成功發(fā)起基于內(nèi)存的攻擊,意味著瀏覽器的功能受到破壞,攻擊者將能繞過(guò)或者欺騙同源策略來(lái)直接訪問(wèn)跨源資源.

如何解決這些安全問(wèn)題,已經(jīng)成為了學(xué)術(shù)界的研究熱點(diǎn).本文重點(diǎn)分析了現(xiàn)有瀏覽器同源策略安全的研究進(jìn)展,深入討論了同源策略規(guī)則的不足與應(yīng)對(duì)方案;分析了跨域與跨源通信機(jī)制所引起的安全威脅與防御方案;并進(jìn)一步討論了內(nèi)存攻擊情況下的同源策略安全;最后,結(jié)合同源策略當(dāng)前面臨的安全問(wèn)題,展望了該機(jī)制的未來(lái)發(fā)展方向.

1 同源策略概述

1.1 術(shù)語(yǔ)定義

網(wǎng)頁(yè)資源的多樣性,使得瀏覽器環(huán)境中存在大量的術(shù)語(yǔ),為便于描述,表1 中總結(jié)了與同源策略相關(guān)的訪問(wèn)控制主客體術(shù)語(yǔ)定義.

Table 1 Descriptions for related terms表1 相關(guān)術(shù)語(yǔ)描述

1.2 同源策略規(guī)則

同源策略是瀏覽器安全的基礎(chǔ)安全策略[5].瀏覽器為每個(gè)加載的frame 設(shè)置一個(gè)稱(chēng)為“源”的屬性.區(qū)別于網(wǎng)站(site)與域名(domain),源是一個(gè)三元組:〈scheme,host,port〉.其中,scheme 是指網(wǎng)址的協(xié)議,如http 或https 等;host是指服務(wù)器主機(jī)在因特網(wǎng)上的域名,與domain 不同,host 涵蓋了子域名,如abc.xyz.com;port 是指服務(wù)器提供網(wǎng)站服務(wù)的端口,如8080.

同源策略的檢測(cè)要求是“同源”,即主體與客體所在frame 的源的三元組需要完全一致.例如,frame https://abc.xyz.com:8080/index.html 與http://abc.xyz.com:8080/index.html,https://xyz.com:8080/index.xyz.com:80/index.html 等f(wàn)rame 分別在協(xié)議、域名與端口上不一致,故而不能訪問(wèn)這些frame 的資源.

同源策略的目標(biāo)在于實(shí)現(xiàn)基于源的Web 資源隔離,以避免一個(gè)惡意Web 應(yīng)用獲取或修改其他不同源應(yīng)用的資源或其上的用戶(hù)隱私數(shù)據(jù).圖1 描述了同源策略的基本規(guī)則.同源策略的規(guī)則與客體資源類(lèi)型有關(guān),具體來(lái)說(shuō)(如圖1 中數(shù)字標(biāo)注所示).

(1) DOM 對(duì)象、JavaScript 對(duì)象、cookie、本地存儲(chǔ)與會(huì)話存儲(chǔ):JavaScript 代碼不能訪問(wèn)不同源網(wǎng)頁(yè)的該類(lèi)資源,如圖1 中來(lái)自alice.com 與bob.com 的兩個(gè)frame 無(wú)法訪問(wèn)對(duì)方的該類(lèi)資源.

(2) 網(wǎng)絡(luò)請(qǐng)求與網(wǎng)絡(luò)響應(yīng):同源策略不限制JavaScript 代碼發(fā)送網(wǎng)絡(luò)請(qǐng)求,但是只有來(lái)自同源的服務(wù)器返回的網(wǎng)絡(luò)響應(yīng)才能被讀取.如圖1 所示,來(lái)自https://alice.com 的frame 中的JavaScript 代碼能夠向https://bob.com 的服務(wù)器發(fā)送數(shù)據(jù),但是該服務(wù)器返回的數(shù)據(jù)不能被alice.com 網(wǎng)頁(yè)讀取.

(3) 第三方資源:一個(gè)網(wǎng)頁(yè)可以嵌入第三方資源,包括JavaScript 腳本、層疊樣式表(cascading style sheets,簡(jiǎn)稱(chēng)CSS)與圖片等.同源策略視網(wǎng)頁(yè)本身的源為這些資源的源.在圖1 中,來(lái)自https://alice.com 的frame 通過(guò)〈scriptsrc=“https://bob.com/script.js”〉標(biāo)簽來(lái)引入來(lái)自bob.com 的第三方腳本,該腳本能夠以alice.com 的身份來(lái)執(zhí)行,但其腳本內(nèi)容對(duì)于alice.com 里的JavaScript 代碼來(lái)說(shuō)是不可讀的.

Fig.1 Rules of same-origin policy圖1 同源策略規(guī)則

2 同源策略安全研究方向

2.1 威脅模型

2.1.1 研究場(chǎng)景

隨著Web 的發(fā)展,瀏覽器已經(jīng)逐漸演化為一個(gè)多主體的操作環(huán)境.通常來(lái)說(shuō),每個(gè)網(wǎng)站包含服務(wù)器程序與在用戶(hù)瀏覽器中運(yùn)行的frame.Frame 可以認(rèn)為是含有代碼和數(shù)據(jù)的主體.代碼包括frame 的HTML 與JavaScript代碼,而數(shù)據(jù)資源包括運(yùn)行時(shí)的JavaScript 對(duì)象、DOM 對(duì)象、cookie 及本地存儲(chǔ)等.作為網(wǎng)頁(yè)代碼的執(zhí)行環(huán)境,瀏覽器實(shí)施了同源策略來(lái)控制frame 代碼對(duì)數(shù)據(jù)資源的訪問(wèn).同源策略研究的威脅模型包含了以下3 類(lèi)角色.

?受害者網(wǎng)站:受害者網(wǎng)站誠(chéng)實(shí)地按照指定的隱私與安全協(xié)議執(zhí)行其業(yè)務(wù)邏輯,用戶(hù)在該網(wǎng)站具備有對(duì)應(yīng)的賬號(hào),從而具備相應(yīng)的隱私數(shù)據(jù)(如銀行網(wǎng)站中的賬單與余額等)及私有操作(如銀行網(wǎng)站中的轉(zhuǎn)賬操作).

?攻擊者:攻擊者在因特網(wǎng)上擁有一個(gè)合法的域名,攻擊者在該域名上布置了相應(yīng)的惡意網(wǎng)頁(yè)來(lái)訪問(wèn)受害者網(wǎng)站(包括服務(wù)器與客戶(hù)端網(wǎng)頁(yè))的資源、或者向受害者網(wǎng)站的frame 提供惡意的第三方JavaScript腳本.攻擊者網(wǎng)站應(yīng)當(dāng)與受害者網(wǎng)站是不同源的,因此理應(yīng)受到同源策略的保護(hù).

?(受害者)用戶(hù):用戶(hù)被誘導(dǎo)在某一時(shí)刻使用其瀏覽器訪問(wèn)了攻擊者網(wǎng)頁(yè)或者含有攻擊者腳本的受害者網(wǎng)頁(yè),使得攻擊者的代碼在用戶(hù)瀏覽器中運(yùn)行.

如圖2 所示,攻擊者的惡意代碼獲取用戶(hù)在受害者網(wǎng)站上資源的研究場(chǎng)景有3 種.

(1) 用戶(hù)在其瀏覽器上訪問(wèn)了攻擊者網(wǎng)站網(wǎng)頁(yè)(如圖2 中attacker.com)與受害者網(wǎng)站網(wǎng)頁(yè)(如圖2 中victim.com),當(dāng)攻擊者和受害者網(wǎng)頁(yè)位于同一個(gè)瀏覽實(shí)例(browsing instance)[24,25]時(shí),攻擊者代碼將能夠獲得受害者網(wǎng)站網(wǎng)頁(yè)的引用;若同源策略被破壞,攻擊者代碼將能通過(guò)該引用來(lái)訪問(wèn)受害者網(wǎng)站網(wǎng)頁(yè)的資源,包括DOM,JavaScript 與cookie 等,若用戶(hù)已經(jīng)在受害者網(wǎng)站網(wǎng)頁(yè)中登錄,攻擊者代碼將能獲取用戶(hù)在受害者網(wǎng)站中的隱私數(shù)據(jù)與執(zhí)行私有操作.

(2) 用戶(hù)在其瀏覽器上訪問(wèn)了攻擊者網(wǎng)站網(wǎng)頁(yè),攻擊者意圖偽裝成用戶(hù)向受害者網(wǎng)站服務(wù)器發(fā)送惡意的網(wǎng)絡(luò)請(qǐng)求;該場(chǎng)景要求用戶(hù)事先在受害者網(wǎng)頁(yè)中進(jìn)行了登錄,并且在攻擊發(fā)生時(shí),用戶(hù)在受害者網(wǎng)站中的cookie 沒(méi)有過(guò)期.

(3) 用戶(hù)在其瀏覽器上訪問(wèn)了受害者網(wǎng)站網(wǎng)頁(yè),受害者網(wǎng)站網(wǎng)頁(yè)錯(cuò)誤地引用了攻擊者網(wǎng)站的資源,如引用了攻擊者網(wǎng)站的第三方JavaScript 腳本來(lái)完成諸如廣告、網(wǎng)站分析等功能.

Fig.2 Threat model for researches on same-origin policy,including three roles and three attack scenarios圖2 同源策略研究的威脅模型,包括3 類(lèi)角色與3 種攻擊場(chǎng)景

特別地,第1 類(lèi)場(chǎng)景需要攻擊者網(wǎng)頁(yè)與受害者網(wǎng)頁(yè)處于同一瀏覽實(shí)例中,存在兩種途徑來(lái)實(shí)現(xiàn)該目標(biāo).

?攻擊者網(wǎng)頁(yè)內(nèi)嵌(或彈出)受害者網(wǎng)頁(yè):攻擊者通過(guò)釣魚(yú)攻擊等方式,使得受害者用戶(hù)訪問(wèn)了攻擊者域名下的某個(gè)網(wǎng)址,該惡意網(wǎng)址對(duì)應(yīng)的攻擊者網(wǎng)頁(yè)利用HTML 中的iframe 標(biāo)簽或window.open API 嵌入了受害者網(wǎng)頁(yè)作為子frame.注意:攻擊者可以將子frame 設(shè)置為不可見(jiàn),使得受害者用戶(hù)無(wú)法直觀觀察到.

?受害者網(wǎng)頁(yè)內(nèi)嵌(或彈出)攻擊者網(wǎng)頁(yè):用戶(hù)正常地訪問(wèn)了受害者網(wǎng)站的網(wǎng)址,該受害者網(wǎng)頁(yè)為完成諸如用戶(hù)追蹤與分析、網(wǎng)頁(yè)性能分析等任務(wù),主動(dòng)嵌入了攻擊者網(wǎng)頁(yè)作為第三方frame.

2.1.2 敵手模型

根據(jù)以上研究場(chǎng)景,當(dāng)攻擊者的惡意代碼在受害者用戶(hù)的瀏覽器中執(zhí)行時(shí),攻擊者將嘗試?yán)@過(guò)同源策略來(lái)訪問(wèn)用戶(hù)在不同源的受害者網(wǎng)站中的資源.根據(jù)攻擊者所具備的攻擊能力,我們定義兩種不同的敵手模型.

(1) 策略攻擊者:攻擊者了解瀏覽器同源策略的規(guī)則,嘗試找到同源策略規(guī)則中未覆蓋到的行為或者利用現(xiàn)有跨源/跨域通信機(jī)制來(lái)繞過(guò)同源策略,以成功訪問(wèn)受害者網(wǎng)頁(yè)的資源.若用戶(hù)在受害者網(wǎng)頁(yè)中進(jìn)行了登錄,或者在攻擊發(fā)生時(shí)用戶(hù)的cookie 沒(méi)有過(guò)期,策略攻擊者將能夠訪問(wèn)用戶(hù)在受害者網(wǎng)頁(yè)中的隱私數(shù)據(jù),甚至偽裝為用戶(hù)向受害者網(wǎng)站服務(wù)器發(fā)送惡意請(qǐng)求(如轉(zhuǎn)賬).

(2) 內(nèi)存攻擊者:攻擊者了解瀏覽器中的JavaScript 引擎的原理,并且該JavaScript 引擎中存在漏洞,使得攻擊者能夠具備有操作內(nèi)存的權(quán)限,如修改瀏覽器的內(nèi)存數(shù)據(jù),甚至于發(fā)起代碼注入或者代碼重用攻擊來(lái)以瀏覽器的身份執(zhí)行任意代碼.內(nèi)存攻擊者可以認(rèn)為能夠攻擊瀏覽器,在這種情況下,瀏覽器的同源策略很容易被繞過(guò).

注意,本文僅考慮針對(duì)瀏覽器同源策略安全的相關(guān)攻防機(jī)制,因此并不考慮由于受害者網(wǎng)站網(wǎng)頁(yè)代碼的漏洞(如跨站腳本攻擊XSS[26?29])所導(dǎo)致的跨源資源訪問(wèn)與數(shù)據(jù)泄漏.特別的,由于操作系統(tǒng)所提供的進(jìn)程間內(nèi)存隔離,本文敵手模型中的內(nèi)存攻擊者必須要求攻擊者代碼與受害者網(wǎng)頁(yè)位于同一個(gè)進(jìn)程內(nèi).攻擊者通過(guò)發(fā)起內(nèi)存攻擊來(lái)控制該進(jìn)程,進(jìn)而繞過(guò)或欺騙同源策略來(lái)訪問(wèn)受害者網(wǎng)頁(yè)資源.根據(jù)瀏覽器的多進(jìn)程模型[24,25],網(wǎng)頁(yè)代碼在渲染進(jìn)程(renderer process)中執(zhí)行,并且利用操作系統(tǒng)提供的沙箱機(jī)制對(duì)渲染進(jìn)程進(jìn)行限制,包括提供獨(dú)立的命名空間甚至限制允許調(diào)用的系統(tǒng)調(diào)用.因此,渲染進(jìn)程將不得不通過(guò)IPC 消息與位于后臺(tái)的瀏覽器內(nèi)核進(jìn)程(browser kernel process)通信來(lái)完成特權(quán)操作,如操作文件系統(tǒng)、網(wǎng)絡(luò)以及傳感器等.然而,瀏覽器的多進(jìn)程模型仍然把屬于同一個(gè)瀏覽實(shí)例的frame 放置在同一個(gè)渲染進(jìn)程中.據(jù)此,內(nèi)存攻擊者通常存在于圖2 所示的第1類(lèi)研究場(chǎng)景中.

2.2 研究方向

瀏覽器中,不同主體之間數(shù)據(jù)的隱私保護(hù)與代碼的隔離執(zhí)行歸功于同源策略.同源策略實(shí)施的有效性極大地影響瀏覽器的安全,因而大量的研究者們對(duì)同源策略進(jìn)行了研究.我們研究與分析了近年來(lái)與Web 相關(guān)領(lǐng)域的頂級(jí)會(huì)議(S&P、CCS、UsenixSecurity、NDSS、OSDI 以及WWW 等)上與同源策略有關(guān)的論文,這些研究現(xiàn)狀可以分為以下3 部分.

(1) 同源策略規(guī)則不足及應(yīng)對(duì)(見(jiàn)第3 節(jié)):在策略攻擊者存在的情況下,考慮同源策略規(guī)則有可能存在的不足與缺陷,分析這些不足可能導(dǎo)致的后果,并給出相應(yīng)的彌補(bǔ)方案.例如,同源策略無(wú)法處理第三方腳本的安全威脅、無(wú)法限制同源不同frame 的權(quán)限、與其他瀏覽器機(jī)制協(xié)作時(shí)還會(huì)為不同源的frame賦予過(guò)多權(quán)限等.

(2) 跨域/跨源通信支持安全威脅及應(yīng)對(duì)(見(jiàn)第4 節(jié)):這一類(lèi)研究方向考慮瀏覽器允許的跨域/跨源通信機(jī)制,針對(duì)這些合法的通信方式進(jìn)行安全分析,發(fā)現(xiàn)其中存在的安全威脅并提供相應(yīng)的防御方案.

(3) 內(nèi)存攻擊下的同源策略安全(見(jiàn)第5 節(jié)):這一類(lèi)研究方向考慮在瀏覽器中發(fā)起內(nèi)存攻擊的可能性,并基于此給出相應(yīng)的內(nèi)存攻擊方案與防御措施.在內(nèi)存攻擊者存在的情況下,同源策略將無(wú)法實(shí)施有效的資源訪問(wèn)控制,需要借助一些內(nèi)存防御方案來(lái)進(jìn)行抵御.

我們分析總結(jié)了這3 類(lèi)同源策略安全研究方向的攻擊者類(lèi)型、攻擊原理、防御機(jī)制以及代表性研究工作,表2 給出了總結(jié)分析結(jié)果.

Table 2 Three research directions of same-origin policy security表2 同源策略安全的3 類(lèi)研究方向

3 同源策略規(guī)則不足及應(yīng)對(duì)

瀏覽器同源策略的目的是實(shí)現(xiàn)基于源的資源隔離,這些資源涵蓋了JavaScript 與DOM 對(duì)象、cookie、本地存儲(chǔ)以及服務(wù)器返回的網(wǎng)絡(luò)響應(yīng)等.同源策略規(guī)則的不足,將使得攻擊者能夠繞過(guò)同源策略來(lái)非法獲取不同源的資源.同源策略規(guī)則的不足體現(xiàn)在以下3 個(gè)方面.

(1) 同一frame 中第三方腳本的過(guò)度授權(quán):一個(gè)frame 中可能包含了第三方腳本.同源策略用承載它們的frame(稱(chēng)之為宿主frame)的源來(lái)判斷這些第三方腳本可以訪問(wèn)的資源,這使得惡意的第三方腳本能夠自由地訪問(wèn)宿主frame 所在源的任意資源.

(2) 同源不同frame 的過(guò)度授權(quán):同源策略為處于同一個(gè)源下的所有frame 賦予相同的權(quán)限,然而,有些Web 應(yīng)用的特性,使得同源不同frame 需要進(jìn)行必須的隔離.例如在博客網(wǎng)站中,xyz.com/a/與xyz.com/b/分別代表了兩個(gè)用戶(hù)a和b的主頁(yè),對(duì)它們進(jìn)行資源隔離是有必要的,而同源策略并不能適應(yīng)這些場(chǎng)景.

(3) 不同源frame 的過(guò)度授權(quán):目前,瀏覽器在發(fā)送網(wǎng)絡(luò)請(qǐng)求時(shí),會(huì)默認(rèn)將用戶(hù)的cookie 攜帶到網(wǎng)絡(luò)請(qǐng)求中,一個(gè)惡意frame 可以通過(guò)利用cookie 機(jī)制來(lái)修改不同源服務(wù)器的狀態(tài),甚至是獲取不同源的資源.

本節(jié)將對(duì)以上3 類(lèi)問(wèn)題的現(xiàn)有研究工作進(jìn)行總結(jié)分析,包括相應(yīng)的攻擊場(chǎng)景、安全威脅與防御方案.

3.1 第三方腳本的過(guò)度授權(quán)與防御

當(dāng)Web 應(yīng)用程序的開(kāi)發(fā)人員決定引入來(lái)自第三方提供者的JavaScript 腳本時(shí),同源策略不允許第三方腳本被宿主frame 讀取,但是允許它以宿主frame 的權(quán)限來(lái)執(zhí)行(見(jiàn)第1.2 節(jié)).一方面來(lái)說(shuō),惡意的第三方腳本提供者可以直接訪問(wèn)宿主frame 的所有資源,包括偷取敏感數(shù)據(jù)或修改網(wǎng)頁(yè)內(nèi)容;另一方面來(lái)說(shuō),非惡意的但是存在漏洞的第三方腳本為攻擊者攻擊宿主frame 提供了便利:攻擊者可以以第三方腳本為跳板來(lái)實(shí)現(xiàn)對(duì)宿主frame 的攻擊.本小節(jié)將首先介紹宿主frame 引入第三方腳本的目的與第三方腳本的分類(lèi),然后分析第三方腳本過(guò)度授權(quán)所帶來(lái)的安全威脅,最后總結(jié)討論現(xiàn)有防御方案的優(yōu)缺點(diǎn).

3.1.1 用途與分類(lèi)

為了豐富功能與增強(qiáng)交互性,Web 應(yīng)用廣泛集成第三方腳本到其自身的網(wǎng)頁(yè)中.Yue 等人[34]發(fā)現(xiàn):96.9%的網(wǎng)站包含來(lái)自其他源的腳本,平均每個(gè)網(wǎng)站包含 3.1 個(gè)第三方腳本.Nikiforakis 等人[6]更進(jìn)一步地統(tǒng)計(jì)了Alexatop 10k 網(wǎng)站中10 個(gè)被引入最多的第三方腳本,并記錄了這些第三方腳本提供的服務(wù),以及在前10k 個(gè)Alexa 網(wǎng)站中的使用率.如表3 所示,主流的第三方腳本通常提供了諸如Web 分析(如Google Analytics 和addthis)、動(dòng)態(tài)廣告(如GoogleAdSense)、社交網(wǎng)絡(luò)(如Facebook 和Twitter)與用戶(hù)追蹤(如Quantserve)等服務(wù).有些第三方腳本還提供了編程庫(kù)(如jQuery)與密碼算法庫(kù)(如CryptoJS)等服務(wù).

Table 3 Ten most popular third-party scripts used by Alexa top 10 000 Internet websites[6]表3 Alexa top 10 000 網(wǎng)站中10 大最受歡迎的第三方腳本[6]

3.1.2 安全威脅

一個(gè)frame 引入大量的第三方腳本,意味著該frame 具有更大的攻擊面.我們首先來(lái)總結(jié)分析由引入第三方腳本所帶來(lái)的對(duì)宿主frame 的新的攻擊向量,包括以下3 種.

(1) 第1 類(lèi)是第三方腳本劫持.

即網(wǎng)頁(yè)開(kāi)發(fā)者在編寫(xiě)宿主frame 時(shí)可能出現(xiàn)編寫(xiě)錯(cuò)誤,攻擊者可以利用這些編寫(xiě)錯(cuò)誤來(lái)使宿主frame 加載與運(yùn)行攻擊者的第三方腳本,進(jìn)而攻擊宿主frame.Nikiforakis 等人[6]于2012 年對(duì)Alexa top10k 的網(wǎng)站進(jìn)行了分析,發(fā)現(xiàn)88.45%的網(wǎng)站至少包含一個(gè)第三方腳本,最壞情況下有網(wǎng)站從295 個(gè)第三方服務(wù)器中加載了腳本,并且有0.27%的第三方腳本是通過(guò)IP 地址引入的.這意味著攻擊者可以采取以下方式來(lái)使得宿主frame 運(yùn)行其惡意代碼.

?若宿主frame 通過(guò)使用localhost 來(lái)引入第三方腳本,并且用戶(hù)機(jī)器為多用戶(hù)時(shí),惡意用戶(hù)可以創(chuàng)建搭載在本地的Web 服務(wù)器來(lái)攻擊;

?若宿主frame 通過(guò)使用私有IP 地址來(lái)引入第三方腳本,位于內(nèi)網(wǎng)內(nèi)的攻擊者可以創(chuàng)建對(duì)應(yīng)的Web 服務(wù)器來(lái)發(fā)起攻擊;

?若宿主frame 引入第三方腳本的域名或IP 地址已經(jīng)過(guò)期,攻擊者可以注冊(cè)該過(guò)期域名/IP 來(lái)發(fā)起攻擊;

?若開(kāi)發(fā)者在編寫(xiě)第三方腳本域名時(shí)出現(xiàn)編寫(xiě)錯(cuò)誤,如將 googlesyndication.com 錯(cuò)誤書(shū)寫(xiě)為googlesyndicatio.com,攻擊者可以注冊(cè)該錯(cuò)誤的域名來(lái)發(fā)起攻擊.

(2) 第2 類(lèi)是利用第三方腳本的漏洞.

即攻擊者可以直接攻擊第三方腳本來(lái)達(dá)到攻擊宿主frame 的目標(biāo).Stock 等人[35]于2015 年對(duì)FireFox 瀏覽器進(jìn)行修改,以增加網(wǎng)頁(yè)的數(shù)據(jù)流檢測(cè).攻擊者可以利用跨站腳本攻擊來(lái)將惡意的數(shù)據(jù)轉(zhuǎn)變?yōu)镴avaScript 代碼來(lái)在宿主frame 中執(zhí)行.根據(jù)其實(shí)驗(yàn)數(shù)據(jù),在Alexatop10k 網(wǎng)站中檢測(cè)到1 273 個(gè)導(dǎo)致跨站腳本攻擊的漏洞,而其中有273 個(gè)漏洞來(lái)自于第三方腳本、165 個(gè)漏洞來(lái)自于第三方腳本與宿主frame 自身代碼的組合.Lauinger 等人[36]于2017 年對(duì)Alexatop 75k 網(wǎng)站中所包含的11 141 726 個(gè)第三方腳本進(jìn)行了分析,通過(guò)爬取脆弱性數(shù)據(jù)庫(kù)、Github 評(píng)論與releasenote 等數(shù)據(jù)來(lái)判斷第三方腳本是否存在脆弱性.實(shí)驗(yàn)結(jié)果發(fā)現(xiàn),37%的網(wǎng)站至少包含一個(gè)已知漏洞版本的第三方腳本.此外,有些網(wǎng)站還使用了很早版本的第三方腳本,這些過(guò)時(shí)的版本與最新版本的平均滯后時(shí)間為1 177 天.新的版本可能包含了對(duì)之前版本漏洞的修復(fù)或者增加一些機(jī)制來(lái)增強(qiáng)腳本的安全性,使用過(guò)時(shí)的第三方腳本為攻擊者提供了額外的攻擊向量來(lái)攻擊宿主frame.同時(shí),由于瀏覽器同源策略賦予了第三方腳本與宿主frame 相同的訪問(wèn)權(quán)限,攻擊者可以攻擊這些脆弱的第三方腳本來(lái)訪問(wèn)宿主frame 所在源中的資源.

(3) 第3 類(lèi)是利用第三方腳本的間接引用特性.

即第三方腳本可以繼續(xù)引入其他腳本,而宿主frame 開(kāi)發(fā)者通常并沒(méi)有意識(shí)到這些外部腳本的存在.Kumar等人[37]于2017 年對(duì)Alexatop 1000k 的網(wǎng)站進(jìn)行了分析,他們將宿主frame 明確引入的第三方腳本稱(chēng)之為顯式依賴(lài)(explicit trust),而由這些第三方腳本引入的除該第三方之外的源的腳本稱(chēng)為隱式依賴(lài)(implicittrust).實(shí)驗(yàn)結(jié)果表明,9%的網(wǎng)站加載了隱式依賴(lài)的外部腳本,而top 100k 的網(wǎng)站中有13%運(yùn)行了隱式依賴(lài)的外部腳本.Ikram等人[8]除了分析Alexatop 200k 網(wǎng)站中的隱式依賴(lài)腳本外,還更近一步地對(duì)這些隱式的第三方提供商進(jìn)行分類(lèi).借助于現(xiàn)有的VirusTotal 工具并設(shè)定合適的閾值,Ikram 等人發(fā)現(xiàn):1.2%的隱式第三方是可疑的,且73%的網(wǎng)站從這些可疑的隱式第三方中加載了資源.這些現(xiàn)有的實(shí)驗(yàn)數(shù)據(jù)意味著攻擊者可以不用直接去攻擊一個(gè)frame 或者其顯式依賴(lài),而是通過(guò)攻擊一些隱式的第三方腳本提供商來(lái)完成攻擊.

上述3 類(lèi)威脅場(chǎng)景對(duì)宿主frame 所造成的攻擊后果包括實(shí)現(xiàn)用戶(hù)追蹤、數(shù)據(jù)泄漏與篡改、阻止HTTPS 部署以及破壞宿主frame 業(yè)務(wù)邏輯等.Zhou 等人[7]開(kāi)發(fā)了ScriptInspector,一個(gè)修改后的瀏覽器,用來(lái)攔截、記錄與檢查第三方腳本對(duì)關(guān)鍵資源的訪問(wèn).通過(guò)對(duì)Alexatop 200 US 網(wǎng)站的實(shí)驗(yàn),發(fā)現(xiàn)幾乎所有的第三方腳本訪問(wèn)了瀏覽器的基本屬性,包括navigator、screen 以及DOM 中的根節(jié)點(diǎn)(document 與body),第三方腳本可以利用這些屬性來(lái)實(shí)現(xiàn)瀏覽器指紋功能[38?42],進(jìn)而完成用戶(hù)追蹤而破壞用戶(hù)隱私.Zhou 等人還發(fā)現(xiàn):大部分的第三方腳本都發(fā)送了網(wǎng)絡(luò)請(qǐng)求,并且有些網(wǎng)絡(luò)請(qǐng)求還發(fā)送給了其他源的服務(wù)器,這可能會(huì)造成數(shù)據(jù)泄漏.一些廣告和社交第三方腳本還存在對(duì)宿主frame 的內(nèi)容進(jìn)行了修改與讀取的情況,如Zhou 等人的實(shí)驗(yàn)中發(fā)現(xiàn),有腳本讀取了用戶(hù)購(gòu)物車(chē)信息;Kumar 等人[37]的實(shí)驗(yàn)發(fā)現(xiàn),在前100 萬(wàn)個(gè)只使用HTTP 協(xié)議的網(wǎng)站中,有55%的HTTP 網(wǎng)站依賴(lài)于不支持HTTPS 訪問(wèn)的內(nèi)容,由于瀏覽器不會(huì)執(zhí)行通過(guò)HTTP 協(xié)議加載到HTTPSframe 中的內(nèi)容,這些網(wǎng)站因而不能遷移為HTTPS 部署;Patra 等人[43]還發(fā)現(xiàn),宿主frame 自身的腳本與第三方腳本有可能存在沖突,由于宿主frame 中的所有腳本具有同樣的JavaScript 作用域,第三方腳本可以聲明在宿主frame 中已經(jīng)存在的全局變量.當(dāng)宿主frame 之后調(diào)用該變量時(shí),JavaScript 引擎將會(huì)使用最新加載的腳本所定義的變量,之前的變量將會(huì)被覆蓋,這有可能直接影響宿主frame 自身的業(yè)務(wù)邏輯.

3.1.3 防御方案

應(yīng)對(duì)第三方腳本安全威脅的主要方案是:將宿主frame 本身的腳本與第三方腳本運(yùn)行在不同的作用域下,以實(shí)現(xiàn)第三方腳本與宿主frame 的隔離.根據(jù)隔離機(jī)制方案的不同,我們將其劃分為以下4 類(lèi).

(1) 第1 類(lèi)是基于語(yǔ)言的防御機(jī)制.

即利用JavaScript 語(yǔ)言的特性來(lái)實(shí)現(xiàn)腳本之間的隔離與資源共享.在該方向上的防御機(jī)制包括Jate[44]、JSand[45]、ScriptProtect[46]、BrowserShield[47]、Caja[48]、GateKeeper[49]等.圖3(a)展示了Tran 等設(shè)計(jì)的Jate 系統(tǒng)[44].該系統(tǒng)首先利用一個(gè)網(wǎng)絡(luò)代理來(lái)將在網(wǎng)頁(yè)中包含一個(gè)Jate庫(kù)并對(duì)第三方腳本進(jìn)行重寫(xiě).Jate庫(kù)利用JavaScript的“with(scope){?}”語(yǔ)句使得第三方腳本的所有變量不能超過(guò)scope 變量的作用域,因而第三方腳本無(wú)法直接訪問(wèn)宿主frame 的其他變量.為支持第三方腳本對(duì)宿主frame 的正常操作,Jate 利用JavaScript 的對(duì)象代理(proxy)機(jī)制為宿主frame 中的相關(guān)變量創(chuàng)建代理對(duì)象,并在第三方腳本重寫(xiě)時(shí),允許對(duì)這些代理對(duì)象的訪問(wèn).同時(shí),由于對(duì)象代理機(jī)制允許設(shè)置回調(diào)函數(shù),宿主frame 可以實(shí)施對(duì)應(yīng)的策略:當(dāng)一個(gè)代理對(duì)象被調(diào)用時(shí),該對(duì)象上的策略回調(diào)函數(shù)將會(huì)被調(diào)用,用來(lái)判斷第三方腳本是否被授權(quán)來(lái)訪問(wèn)宿主frame 的對(duì)象,如圖3(a)中允許對(duì)window 對(duì)象的引用,但拒絕對(duì)data 對(duì)象的引用.其實(shí)驗(yàn)表明,Jate 機(jī)制引入了接近20%的開(kāi)銷(xiāo).

Fig.3 Examples for the type 1 and type 2 defense mechanisms圖3 第1 類(lèi)與第2 類(lèi)防御機(jī)制示例

(2) 第2 類(lèi)是基于Worker 的防御機(jī)制.

即利用瀏覽器提供的WebWorker 來(lái)實(shí)現(xiàn)宿主frame 與第三方腳本的隔離.由于JavaScript 的單線程性質(zhì),frame 中比較耗時(shí)的操作將會(huì)很大程度上影響到網(wǎng)頁(yè)瀏覽體驗(yàn).WebWorker 機(jī)制使得JavaScript 可以請(qǐng)求瀏覽器創(chuàng)建新的線程來(lái)運(yùn)行指定代碼.瀏覽器為WebWorker 中的代碼與宿主frame 其他代碼創(chuàng)建不同的作用域而實(shí)現(xiàn)隔離.Ingram 等據(jù)此設(shè)計(jì)了TreeHouse 系統(tǒng)[30].如圖3(b)所示,該系統(tǒng)將第三方腳本放置在WebWorker 中,并創(chuàng)建虛擬DOM 來(lái)允許第三方腳本對(duì)特定DOM 的合法訪問(wèn).第三方腳本與宿主frame 之間的交互需要通過(guò)消息通信機(jī)制來(lái)實(shí)現(xiàn).

(3) 第3 類(lèi)是基于frame 的防御機(jī)制.

即利用瀏覽器的同源策略來(lái)實(shí)現(xiàn)宿主 frame 與第三方腳本的強(qiáng)隔離.在該方向上的防御機(jī)制包括AdJail[50]、Pivot[51]、Mashic[52]、MashupOS[53]等.舉例來(lái)說(shuō),Louw 等人提出了AdJail[50]系統(tǒng),來(lái)將第三方腳本放置在一個(gè)具有唯一源的frame 中.根據(jù)同源策略,運(yùn)行在另一個(gè)源中的第三方腳本將無(wú)法直接訪問(wèn)原來(lái)宿主frame 的數(shù)據(jù).為了保留第三方腳本對(duì)宿主frame 某些資源的訪問(wèn),AdJail 系統(tǒng)利用消息通信機(jī)制來(lái)實(shí)現(xiàn)資源共享.Mickens 等人更進(jìn)一步地提出了Pivot 系統(tǒng)[51].類(lèi)似于AdJail,第三方腳本被放置在不同源的frame 中來(lái)實(shí)現(xiàn)隔離.然而,AdJail 的資源共享由于利用消息通信機(jī)制使得其必須是異步操作,Pivot 利用JavaScript 語(yǔ)言中的generator 特性來(lái)對(duì)消息通信進(jìn)行封裝,實(shí)現(xiàn)同步的資源共享.

(4) 第4 類(lèi)是基于JavaScript 引擎的防御機(jī)制.

即通過(guò)對(duì)JavaScript 引擎進(jìn)行修改以實(shí)現(xiàn)宿主frame 與第三方腳本的隔離.Dong 等人提出了基于JavaScript引擎的防御機(jī)制AdSentry 系統(tǒng)[54].AdSentry 在瀏覽器中運(yùn)行了一個(gè)影子JavaScript 引擎.第三方腳本將運(yùn)行在該影子JavaScript 引擎中,從而實(shí)現(xiàn)與宿主frame 的隔離.第三方腳本與宿主frame 的資源共享也需要利用消息通信機(jī)制來(lái)實(shí)現(xiàn).Meyerovich 等人與Acker 等人先后提出了ConScript[55]與WebJail[56]來(lái)限制第三方資源.具體來(lái)說(shuō),通過(guò)在JavaScript 引擎中增加API 來(lái)對(duì)原來(lái)JavaScript 函數(shù)引入新的建議函數(shù)(advice function).當(dāng)建議函數(shù)存在時(shí),JavaScript 引擎將會(huì)調(diào)用建議函數(shù),否則調(diào)用原函數(shù).宿主frame 因此可以利用建議函數(shù)來(lái)限制第三方腳本.

以上4 類(lèi)方案的基本思路歸為兩個(gè)角度.

?實(shí)現(xiàn)語(yǔ)言上的隔離.第1 類(lèi)防御機(jī)制利用JavaScript 語(yǔ)言的特性或者提出新的語(yǔ)言來(lái)實(shí)現(xiàn)隔離.這種方式的優(yōu)勢(shì)在于便于資源共享,但是在可用性上是存在不足的.具體來(lái)說(shuō),這些機(jī)制需要對(duì)JavaScript 所有可能的對(duì)象引用都進(jìn)行限制,JavaScript 語(yǔ)言的復(fù)雜性與動(dòng)態(tài)性使得策略仲裁很難確保完備性.而且JavaScript 與HTML 在不斷地更新,甚至不同瀏覽器在JavaScriptAPI 實(shí)現(xiàn)上還可能有區(qū)別,這必然導(dǎo)致這些機(jī)制很難實(shí)際采用.此外,對(duì)第三方腳本的重寫(xiě)還涉及到動(dòng)態(tài)代碼,如eval 等,這將造成很大的運(yùn)行時(shí)開(kāi)銷(xiāo).

?實(shí)現(xiàn)系統(tǒng)上的隔離.后3 類(lèi)防御機(jī)制能實(shí)現(xiàn)系統(tǒng)上的隔離,其優(yōu)勢(shì)在于JavaScript 與HTML 的復(fù)雜性與更新不會(huì)影響隔離機(jī)制.這些機(jī)制可以粗略地認(rèn)為它們將第三方腳本轉(zhuǎn)變?yōu)榱说谌絝rame,這將導(dǎo)致直接函數(shù)調(diào)用與對(duì)象引用等能力的缺失.為保證第三方腳本的正常操作,這些機(jī)制必須提供額外的消息通信機(jī)制(如postMessage[57])來(lái)允許第三方腳本與宿主frame 之間的資源共享.但使用消息通信機(jī)制會(huì)帶來(lái)一些不足,比如第三方腳本原本的同步操作經(jīng)轉(zhuǎn)變?yōu)榱水惒讲僮?甚至可能需要第三方腳本自己阻塞來(lái)等待響應(yīng)消息的到來(lái)(如Pivot[51]).這種異步操作不僅會(huì)帶來(lái)很大的性能開(kāi)銷(xiāo),還需要考慮是否對(duì)網(wǎng)頁(yè)的業(yè)務(wù)邏輯造成影響.

3.2 同源不同frame的過(guò)度授權(quán)與防御

瀏覽器同源策略的策略實(shí)施依據(jù)為主體與客體的源是否一致,這意味著同源的不同frame 將擁有相同的訪問(wèn)控制權(quán)限,即都能訪問(wèn)該源的任意資源.然而,同源的不同frame 在一些情況下需要賦予不同的權(quán)限.在這些情況下,由于權(quán)限受限的frame 可能通過(guò)訪問(wèn)同源且授權(quán)的frame 來(lái)提升權(quán)限,同源策略將使得這些frame 的權(quán)限控制形同虛設(shè).本小節(jié)將首先分析同源不同frame 需要賦予不同權(quán)限的場(chǎng)景與對(duì)應(yīng)的安全威脅,然后總結(jié)討論現(xiàn)有的一些防御方案的優(yōu)缺點(diǎn).

3.2.1 安全威脅

在一個(gè)網(wǎng)頁(yè)中,同源的兩個(gè)不同的frame 并不一定是完全對(duì)等的,因而需要被賦予不同權(quán)限,主要包括以下3類(lèi)情況.

(1) 第1 類(lèi)是同源但不同URL 路徑的frame.

Moshchuk 等人[58]指出,同源策略無(wú)法實(shí)現(xiàn)在URL 路徑上的隔離.考慮分別來(lái)自于https://www.facebook.com/user1 與https://www.facebook.com/user2 的兩個(gè)同源frame,它們代表著不同用戶(hù)的主頁(yè),但卻無(wú)法實(shí)現(xiàn)權(quán)限上的隔離.Cao 等人[9]認(rèn)為,同源策略需要支持更進(jìn)一步的主體隔離.例如,一個(gè)Web 應(yīng)用包含有一個(gè)良好的frame(a.com/benign)以及一個(gè)可能被攻擊的frame(a.com/malicious),Web 應(yīng)用開(kāi)發(fā)者可以利用HTMLiframe 中的sandbox 關(guān)鍵字來(lái)限制后一個(gè)frame 的權(quán)限,如不允許彈窗或不允許提交表單等.然而,若該被攻擊的frame 具備執(zhí)行JavaScript 代碼的權(quán)限,其可以訪問(wèn)良好的frame 來(lái)實(shí)現(xiàn)彈窗或者提交表單的功能.Singh 等人[13]分析cookie 的訪問(wèn)控制包含URL 路徑,而同源策略忽略URL 路徑的策略實(shí)施機(jī)制將會(huì)破壞cookie 的訪問(wèn)控制.Lerner 等人[31]發(fā)現(xiàn),同源策略對(duì)同源不同frame 的過(guò)度授權(quán)使得存檔管理功能的Web 應(yīng)用受到了新的安全威脅.目前,Internet 上的最大存檔網(wǎng)站(web.archive.org)將其他網(wǎng)站(如http://www.xyz.com)保存在諸如“https://web.archive.org/web/20001110101700/http://www.xyz.com/”的路徑上.被存檔的網(wǎng)站的源是作為URL 路徑中的一個(gè)目錄,這使得任意兩個(gè)被存檔的網(wǎng)站將被認(rèn)為是來(lái)自于同一個(gè)源(https://web.archive.org/).如此,攻擊者網(wǎng)頁(yè)可以事先編寫(xiě)用來(lái)修改受害者網(wǎng)站內(nèi)容的代碼,在網(wǎng)頁(yè)被存檔后,該代碼將修改受害者網(wǎng)頁(yè)內(nèi)容,從而影響諸如利用存檔網(wǎng)站來(lái)進(jìn)行法律取證的行為的正確性.

(2) 第2 類(lèi)是同源但在網(wǎng)頁(yè)中處于不同位置的frame.

Son 等人[14]通過(guò)分析目前網(wǎng)站在使用postMessageAPI[57]上的不足,指出消息接收方需要使用基于frame 的消息過(guò)濾方案.該方案通過(guò)消息監(jiān)聽(tīng)函數(shù)參數(shù)event 中的source 成員變量來(lái)完成更進(jìn)一步的消息過(guò)濾,該變量是發(fā)送消息frame 的引用,代表了其在該網(wǎng)頁(yè)的frame 結(jié)構(gòu)中的位置.因此,即使該網(wǎng)頁(yè)中存在另一個(gè)與消息發(fā)送方同源的其他frame,該frame 同樣不能通過(guò)消息接收方的消息過(guò)濾方案.Barth 等人[59]認(rèn)為:在一個(gè)網(wǎng)頁(yè)中,一個(gè)frame 只能對(duì)其子frame 或者后代frame 的URL 賦值來(lái)重新加載frame(瀏覽器中稱(chēng)這種行為為導(dǎo)航Nagivate),其他兄弟frame 是不具備導(dǎo)航權(quán)限的.然而,不論是基于frame 的消息過(guò)濾方案還是導(dǎo)航機(jī)制,都會(huì)因?yàn)橥床呗缘倪^(guò)度授權(quán)而被破壞.在同源策略的支撐下,一個(gè)不具備合法消息發(fā)送與導(dǎo)航權(quán)限的frame,可以訪問(wèn)相應(yīng)的被授權(quán)的同源frame 來(lái)獲取到對(duì)應(yīng)的權(quán)限.

(3) 第3 類(lèi)是瀏覽器其他安全策略機(jī)制參與下的同源不同frame.

Stefan 等人[60]依據(jù)強(qiáng)制訪問(wèn)控制機(jī)制設(shè)計(jì)了一種增強(qiáng)的安全策略COWL,并被引入為W3C 標(biāo)準(zhǔn)的一部分[61].Frame 需要處理其他源的frame 的敏感數(shù)據(jù),為了保證數(shù)據(jù)隱私,COWL 為處理數(shù)據(jù)的frame 攜帶一個(gè)安全標(biāo)簽來(lái)表明其安全級(jí)別,并對(duì)某些敏感操作(如發(fā)送網(wǎng)絡(luò)請(qǐng)求)進(jìn)行限制.同源的兩個(gè)不同frame 可能因?yàn)闅v史行為的不同具備不同的安全標(biāo)簽,并因此具備不同的訪問(wèn)控制權(quán)限.由于同源策略的過(guò)度授權(quán),除非進(jìn)行類(lèi)似frame 級(jí)別的安全隔離,COWL 的策略實(shí)施將會(huì)被破壞.Somé 等人[10]發(fā)現(xiàn),瀏覽器的內(nèi)容安全策略(content security policy,簡(jiǎn)稱(chēng)CSP)機(jī)制會(huì)被同源策略所破壞.內(nèi)容安全策略允許frame 的開(kāi)發(fā)者通過(guò)設(shè)定HTTP 頭來(lái)指定frame 的合法行為,如僅僅允許加載來(lái)自自身源的資源、不允許可能導(dǎo)致漏洞的eval 操作等.通過(guò)對(duì)Alexatop 10k 網(wǎng)站的內(nèi)容安全策略協(xié)議進(jìn)行分析,Somé 等人發(fā)現(xiàn):在實(shí)施有內(nèi)容安全策略的網(wǎng)站中,存在72%的網(wǎng)頁(yè)包含有同源或同域名的子frame,并且父子frame 的內(nèi)容安全策略是不一致的.內(nèi)容安全策略的不一致,意味著兩個(gè)frame 被賦予了不同的權(quán)限,一個(gè)受限的frame 同樣能夠借助授權(quán)的同源frame 來(lái)進(jìn)行權(quán)限提升.

3.2.2 防御方案

為應(yīng)對(duì)同源不同frame 的過(guò)度授權(quán),研究者們從以下3 個(gè)角度來(lái)設(shè)計(jì)安全防御機(jī)制.

(1) 第1 類(lèi)是細(xì)粒度的同源策略.

即在同源策略基礎(chǔ)上,為主客體增加新的安全屬性來(lái)區(qū)分同源不同frame.特別的,不同URL 路徑的frame可以設(shè)置不同的允許訪問(wèn)列表,從而解決同源策略對(duì)同源不同frame 的過(guò)度授權(quán)問(wèn)題.Moshchuk 等人[58]設(shè)計(jì)了細(xì)粒度的同源策略規(guī)則來(lái)實(shí)施基于內(nèi)容的隔離策略.基于內(nèi)容的隔離策略允許內(nèi)容的所有者指定一個(gè)白名單.在瀏覽器環(huán)境中,Alice 可以將其網(wǎng)頁(yè)http://blog.com/alice/index.html 的白名單設(shè)置為T(mén)rust:list=http://blog.com/alice/*,安全監(jiān)控器將認(rèn)為該網(wǎng)頁(yè)內(nèi)容與來(lái)自于http://blog.com/alice 目錄下的網(wǎng)頁(yè)是同一個(gè)主體,從而允許訪問(wèn),但拒絕來(lái)自于http://blog.com/網(wǎng)頁(yè)的訪問(wèn).除了可以實(shí)現(xiàn)基于URL 路徑的訪問(wèn)控制外,基于內(nèi)容的隔離策略甚至能夠使得兩個(gè)不同源的網(wǎng)頁(yè)被視作同一主體,這將有利于網(wǎng)頁(yè)的資源共享需求.Jayaraman 等人[62]允許Web服務(wù)器根據(jù)內(nèi)容的可信度來(lái)為內(nèi)容設(shè)置安全標(biāo)簽,并且將可信度不同的內(nèi)容放置在不同環(huán)(ring)上.在策略實(shí)施時(shí),同時(shí)確保低特權(quán)的環(huán)的主體不能訪問(wèn)高特權(quán)環(huán)的內(nèi)容.Luo 等人[63]認(rèn)為,基于環(huán)的方案沒(méi)有處理不同主體(如同源不同frame)在發(fā)送網(wǎng)絡(luò)請(qǐng)求等行為上的不同,因此提出了基于能力(capability)的訪問(wèn)控制模型來(lái)加固同源策略.該訪問(wèn)控制模型中,主體的安全屬性是源與能力的集合.能力被定義為安全令牌(token).在策略實(shí)施時(shí),確保只有具有特定token 的主體才能訪問(wèn)對(duì)應(yīng)的資源.主體可以細(xì)粒度到frame 甚至為DOM 元素級(jí)別.Steven 等人[64]、Cox 等人[65]、Karlof 等人[66]與Dong 等人[67]也在不同角度對(duì)同源策略進(jìn)行細(xì)粒度策略增強(qiáng)來(lái)解決同源不同frame 的過(guò)度授權(quán)問(wèn)題.

(2) 第2 類(lèi)是動(dòng)態(tài)的同源策略.

即通過(guò)拋棄掉同源策略對(duì)源的依賴(lài),允許frame 更加靈活地設(shè)置主體或信任的資源,將能夠可配置地解決同源策略對(duì)同源不同frame 的過(guò)度授權(quán)問(wèn)題.Cao 等人[9]提出了一種可配置的源策略(configurable origin policy,簡(jiǎn)稱(chēng)COP)來(lái)替代同源策略.不同于同源策略以源作為訪問(wèn)控制主體的安全屬性,COP 是驗(yàn)證瀏覽器標(biāo)注的可配置的ID.一個(gè)frame 可以自由更改它的ID,并且確保ID 是不可猜測(cè)的,以防惡意frame 將自身主體安全屬性設(shè)置為受害者的ID.瀏覽器在進(jìn)行訪問(wèn)控制時(shí),只有主客體ID 一致時(shí)才允許.若需要對(duì)同源不同frame 進(jìn)行隔離,授權(quán)的frame 只需要設(shè)置新的ID 并確保不將該ID 分享給其他非授權(quán)的frame 即可.同源策略對(duì)同源不同frame的過(guò)度授權(quán)將得以解決.此外,COP 還支持不同源之間的資源共享,這可以通過(guò)分享ID 完成.

(3) 第3 類(lèi)是對(duì)瀏覽器其他安全機(jī)制的安全增強(qiáng).

Stefan 等人[60]提出了COWL 策略來(lái)防止敏感數(shù)據(jù)的泄漏,在該策略中,一個(gè)frame 將根據(jù)接收到的來(lái)自其他frame 的敏感數(shù)據(jù)來(lái)設(shè)置安全標(biāo)簽.考慮到同源策略對(duì)同源不同frame 的過(guò)度授權(quán),Stefan 等人指出:在瀏覽器進(jìn)行同源策略驗(yàn)證時(shí),將同時(shí)檢查主客體的安全標(biāo)簽是否一致,若不一致,則拒絕訪問(wèn).這種兩層的訪問(wèn)控制將不同安全標(biāo)簽的frame 進(jìn)行隔離,從而解決了該場(chǎng)景下的同源不同frame 過(guò)度授權(quán)問(wèn)題.Somé 等人[10]發(fā)現(xiàn),內(nèi)容安全策略機(jī)制會(huì)被同源策略所破壞.從訪問(wèn)控制角度來(lái)說(shuō),這種漏洞存在的原因是同源策略的過(guò)度授權(quán);從部署角度來(lái)說(shuō),是因?yàn)橥痪W(wǎng)站中有不同frame 具備不同的內(nèi)容安全策略標(biāo)簽,因此可以從部署角度來(lái)減輕安全威脅.Pan 等人[68]提出了CSPAutoGen 系統(tǒng).CSPAutoGen 系統(tǒng)通過(guò)訓(xùn)練的手段來(lái)為每個(gè)網(wǎng)站生成對(duì)應(yīng)的模版,根據(jù)模版來(lái)為該網(wǎng)站設(shè)置內(nèi)容安全策略規(guī)則.一個(gè)網(wǎng)站可以利用CSPAutoGen 系統(tǒng)來(lái)為所有frame 設(shè)置相同內(nèi)容安全策略規(guī)則,從而避免由于同源策略導(dǎo)致的過(guò)度授權(quán).此外,許多工作也對(duì)內(nèi)容安全策略策略進(jìn)行了分析[69?71]與不同角度的加固[72,73].

總的來(lái)說(shuō),前兩類(lèi)防御機(jī)制通過(guò)對(duì)同源策略進(jìn)行修改,來(lái)應(yīng)對(duì)同源不同frame 的過(guò)度授權(quán)問(wèn)題.相比而言,第二類(lèi)防御機(jī)制是從根本上解決問(wèn)題,且除了實(shí)施細(xì)粒度的同源策略外,還可以將不同源的frame 合并作為同一個(gè)主體.然而,對(duì)同源策略的安全增強(qiáng),為Web 應(yīng)用開(kāi)發(fā)者提出了新的要求:Web 開(kāi)發(fā)者需要確定資源的可信度而設(shè)置不同主體,這將影響這些新的策略的可行性.第三類(lèi)機(jī)制通常針對(duì)于特定的安全威脅場(chǎng)景,沒(méi)有從根本上來(lái)解決同源不同frame 的過(guò)度授權(quán)問(wèn)題,因此不具備普適性,但是不需要對(duì)同源策略進(jìn)行更改,從而保持向后兼容性.

3.3 不同源frame的過(guò)度授權(quán)與防御

瀏覽器同源策略的目標(biāo)是進(jìn)行源與源之間的隔離,然而為了滿足Web 應(yīng)用的需求,同源策略規(guī)則對(duì)兩類(lèi)特殊跨源資源訪問(wèn)沒(méi)有作出限制:首先,同源策略允許一個(gè)frame 向任意源的Web 服務(wù)器發(fā)送數(shù)據(jù);其次,同源策略允許一個(gè)frame 使用〈script src=“xxx”〉的方式來(lái)執(zhí)行任意源的腳本.研究發(fā)現(xiàn):結(jié)合瀏覽器的cookie 機(jī)制,攻擊者可以利用這兩類(lèi)合法跨源資源請(qǐng)求來(lái)修改與偷取跨源數(shù)據(jù),使得不同源的frame 被過(guò)度授權(quán).本小節(jié)將首先分析不同源frame 被過(guò)度授權(quán)的場(chǎng)景及安全威脅,最后總結(jié)分析現(xiàn)有的安全防御工作.

3.3.1 安全威脅

根據(jù)利用的同源策略規(guī)則的不同,研究者們發(fā)現(xiàn)了不同源frame 可以獲取過(guò)多權(quán)限的兩種攻擊:跨站請(qǐng)求偽造(cross-site request forgery,簡(jiǎn)稱(chēng)CSRF)攻擊與跨站腳本注入(cross-site script inclusion,簡(jiǎn)稱(chēng)XSSI)攻擊.

CSRF 攻擊存在兩種形式,包括preAuth-CSRF(也被稱(chēng)為L(zhǎng)ogin CSRF)攻擊與Auth-CSRF 攻擊.preAuth-CSRF 攻擊由Barth 等人[11]于2008 年提出,該攻擊發(fā)生在用戶(hù)未登錄受害者網(wǎng)站或者cookie 已經(jīng)過(guò)期的情況下.在preAuth-CSRF 攻擊中,用戶(hù)由于無(wú)意或者受到釣魚(yú)攻擊等訪問(wèn)了攻擊者網(wǎng)頁(yè).攻擊者網(wǎng)站(attacker.com)與受害者網(wǎng)站(如google.com)屬于不同的源.當(dāng)用戶(hù)訪問(wèn)攻擊者網(wǎng)頁(yè)時(shí),攻擊者frame 將主動(dòng)向受害者網(wǎng)站發(fā)送一條POST 網(wǎng)絡(luò)請(qǐng)求,并且攜帶上攻擊者自己選擇的賬號(hào)與密碼.受害者網(wǎng)站將在認(rèn)證賬號(hào)密碼后,將與用戶(hù)瀏覽器協(xié)商cookie 來(lái)保存會(huì)話.此后,用戶(hù)可能在cookie 還沒(méi)有過(guò)期前訪問(wèn)了受害者網(wǎng)站的網(wǎng)頁(yè),并且執(zhí)行一系列的操作,如在Google 搜索引擎中進(jìn)行搜索.由于cookie 的存在,受害者網(wǎng)站服務(wù)器將會(huì)錯(cuò)誤地認(rèn)為該搜索行為來(lái)自于攻擊者賬號(hào).因此,攻擊者將能夠事后在自己的瀏覽器上訪問(wèn)受害者網(wǎng)站來(lái)獲取用戶(hù)的歷史搜索信息,從而突破同源策略對(duì)不同源Web 應(yīng)用資源的隔離限制.

與preAuth-CSRF 攻擊不同,Auth-CSRF 攻擊發(fā)生在用戶(hù)曾經(jīng)登錄過(guò)受害者網(wǎng)站并使得瀏覽器保存了對(duì)應(yīng)cookie 的情況下.在Auth-CSRF 攻擊中,用戶(hù)由于無(wú)意或者受到釣魚(yú)攻擊等訪問(wèn)了攻擊者網(wǎng)站(attacker.com),攻擊者frame 將自動(dòng)向受害者網(wǎng)站(如bank.com)的服務(wù)器發(fā)送一個(gè)轉(zhuǎn)賬請(qǐng)求.由于瀏覽器的cookie 機(jī)制會(huì)自動(dòng)為網(wǎng)絡(luò)請(qǐng)求攜帶上cookie,而且用戶(hù)事先登錄過(guò)bank.com 的cookie 還未過(guò)期,bank.com 的服務(wù)器通過(guò)驗(yàn)證cookie將會(huì)認(rèn)為轉(zhuǎn)賬請(qǐng)求來(lái)自于用戶(hù),從而在用戶(hù)不知情情況下實(shí)現(xiàn)用戶(hù)在bank.com 上的轉(zhuǎn)賬.Sudhodanan 等人[74]對(duì)Auth-CSRF 攻擊方式進(jìn)行了總結(jié),并對(duì)Alexa 中的300 個(gè)網(wǎng)站進(jìn)行了檢測(cè),在133 個(gè)可實(shí)施其實(shí)驗(yàn)的網(wǎng)站中,90個(gè)網(wǎng)站(68%)能夠通過(guò)Auth-CSRF 方式進(jìn)行攻擊.

XSSI 攻擊來(lái)源于Grossman 在2006 年提出的JSON 劫持攻擊[75],圖4 描述了該攻擊的場(chǎng)景與利用過(guò)程.具體來(lái)說(shuō),用戶(hù)事先登錄過(guò)受害者網(wǎng)站(email.com),使得用戶(hù)瀏覽器保存了對(duì)應(yīng)的cookie.在cookie 沒(méi)有過(guò)期時(shí),用戶(hù)被欺騙來(lái)訪問(wèn)攻擊者網(wǎng)頁(yè)(attacker.com).攻擊者網(wǎng)頁(yè)的目標(biāo)是為了獲取受害者網(wǎng)站的JSON 文件(email.com/contacts.json),該JSON 文件中包含了用戶(hù)在受害者網(wǎng)站上的聯(lián)系人信息.由于瀏覽器的同源策略,攻擊者網(wǎng)頁(yè)直接通過(guò)JavaScript 的API 來(lái)訪問(wèn)不同源JSON 文件的行為會(huì)被拒絕.而在該JSON 劫持攻擊中,攻擊者網(wǎng)頁(yè)將利用同源策略允許的跨源內(nèi)嵌腳本規(guī)則來(lái)引入受害者網(wǎng)站的JSON 文件.受害者網(wǎng)站服務(wù)器通過(guò)對(duì)cookie 的認(rèn)證而返回用戶(hù)的聯(lián)系人信息.當(dāng)瀏覽器接收到返回的JSON 文件時(shí),將其在攻擊者網(wǎng)頁(yè)中以腳本形式執(zhí)行.由于JSON 在JavaScript 語(yǔ)言中被認(rèn)為是定義一個(gè)數(shù)組,攻擊者網(wǎng)頁(yè)可以事先對(duì)數(shù)組(array)進(jìn)行重載,使得在構(gòu)造數(shù)組時(shí)調(diào)用重載后的代碼,該代碼可以讀取數(shù)組內(nèi)容(即用戶(hù)聯(lián)系人),進(jìn)而發(fā)送給攻擊者服務(wù)器.最終,攻擊者將能夠獲取用戶(hù)在跨源服務(wù)器上的聯(lián)系人信息.Grossman 向Google 報(bào)告了這個(gè)問(wèn)題,Christoph Kern 此后將該攻擊命名為XSSI 攻擊,并在其2007 年出版的書(shū)籍[76]中進(jìn)行了詳細(xì)描述.其他的一些變種XSSI 攻擊[77,78]也隨之提出.

Fig.4 One form of XSSI attack through including remote JSON file[75]圖4 一種通過(guò)包含遠(yuǎn)程JSON 文件的XSSI 攻擊[75]

Lekies 等人[12]發(fā)現(xiàn):XSSI 攻擊可以直接使用受害者網(wǎng)站的JavaScript 腳本,而非JSON 文件,這使得發(fā)起XSSI 攻擊更加便利與通用.Lekies 等人認(rèn)為:目前Web 應(yīng)用在服務(wù)器端不再單一地使用靜態(tài)腳本,相反,服務(wù)器會(huì)根據(jù)登錄的用戶(hù)往腳本中填入不同的信息(稱(chēng)之為動(dòng)態(tài)腳本).通過(guò)對(duì)150 個(gè)網(wǎng)站的實(shí)驗(yàn)分析,Lekies 等人發(fā)現(xiàn):49 個(gè)網(wǎng)站使用了動(dòng)態(tài)腳本,其中攜帶的動(dòng)態(tài)信息包含了用戶(hù)的數(shù)據(jù)(如用戶(hù)名與郵箱地址)以及網(wǎng)頁(yè)與Web應(yīng)用通信的安全令牌等.與JSON 劫持攻擊類(lèi)似,為獲取這些信息,攻擊者可以利用HTML 的script 標(biāo)簽將受害者網(wǎng)站的動(dòng)態(tài)腳本引入到自身的frame 中(圖4 中攻擊行為的步驟2).該動(dòng)態(tài)腳本將在攻擊者frame 中執(zhí)行.根據(jù)用戶(hù)敏感信息在動(dòng)態(tài)腳本中的不同定義方式(如全局變量、數(shù)組等),攻擊者frame 可以通過(guò)事先重載相應(yīng)的JavaScript 函數(shù)(圖4 中攻擊行為的步驟1)、或者事后訪問(wèn)全局變量來(lái)獲取這些敏感信息.利用這些敏感信息,攻擊者可以實(shí)現(xiàn)用戶(hù)追蹤或個(gè)性化的社會(huì)工程.更進(jìn)一步地,Staicu 等人[79]發(fā)現(xiàn):同源策略規(guī)則中,允許嵌入的跨源圖片也能被用來(lái)造成類(lèi)似的隱私泄漏.

為了更直觀地描述CSRF 與XSSI 攻擊,我們總結(jié)了兩種攻擊所利用的同源策略規(guī)則、后果以及相關(guān)工作(見(jiàn)表4).

Table 4 Attacks on accessing cross-origin resources (attacker and victim site are cross-origin)表4 獲取跨源資源的攻擊方式(攻擊者網(wǎng)站與受害者網(wǎng)站不同源)

preAuth-CSRF,Auth-CSRF 與XSSI 攻擊的建立來(lái)自于兩個(gè)不同的角度.

?攻擊時(shí)機(jī):不同于Auth-CSRF 與XSSI 攻擊,preAuth-CSRF 攻擊發(fā)生在用戶(hù)登錄賬號(hào)之前.不同的攻擊時(shí)機(jī)使得攻擊者采用不同的攻擊方式,并且攻擊獲利方式也存在不同,如preAuth-CSRF 需要攻擊者事后登錄自己賬號(hào)來(lái)獲取隱私數(shù)據(jù).

?攻擊后果:攻擊者網(wǎng)頁(yè)利用CSRF 攻擊獲取到的對(duì)不同源資源的訪問(wèn)權(quán)限是有限的.通常而言,CSRF 只允許攻擊者獲取用戶(hù)歷史行為或者修改受害者網(wǎng)站的狀態(tài),并不能允許攻擊者直接讀取用戶(hù)的數(shù)據(jù)(如郵件網(wǎng)站中用戶(hù)的聯(lián)系人等信息).其本質(zhì)原因在于:同源策略規(guī)則允許一個(gè)frame 向任意源網(wǎng)站發(fā)送請(qǐng)求,但不允許獲取跨源網(wǎng)站返回的網(wǎng)絡(luò)響應(yīng).XSSI 更進(jìn)一步地考慮到同源策略規(guī)則允許frame 內(nèi)嵌任意源的腳本,利用這一規(guī)則,將使得攻擊者能夠發(fā)起攻擊來(lái)直接讀取隱私數(shù)據(jù).

3.3.2 防御方案

CSRF 與XSSI 攻擊得以發(fā)生的原因有兩點(diǎn):一是同源策略規(guī)則允許發(fā)送跨源網(wǎng)絡(luò)請(qǐng)求與嵌入跨源腳本,二是瀏覽器cookie 機(jī)制使得攻擊者frame 可以通過(guò)受害者網(wǎng)站服務(wù)器的用戶(hù)認(rèn)證.應(yīng)對(duì)CSRF 與XSSI 攻擊,可以從這兩個(gè)方面著手.

?首先,同源策略規(guī)則的增強(qiáng)可以應(yīng)對(duì)CSRF 與XSSI 攻擊.Barth 等人[11]指出,瀏覽器為同源策略安全增加一個(gè)新的HTTP 頭:Referer.當(dāng)一個(gè)frame 發(fā)起網(wǎng)絡(luò)請(qǐng)求時(shí),瀏覽器將獲取該frame 的URL,并將該URL作為Referer 的值攜帶到網(wǎng)絡(luò)請(qǐng)求中.盡管瀏覽器并未限制跨源網(wǎng)絡(luò)請(qǐng)求,但是Web 服務(wù)器可以根據(jù)Referer 來(lái)進(jìn)行同源檢測(cè),或著判斷跨源網(wǎng)絡(luò)請(qǐng)求是否來(lái)自于其信任的跨源網(wǎng)頁(yè).當(dāng)發(fā)送的frame 不被認(rèn)可時(shí),Web 服務(wù)器將拒絕返回XSSI 攻擊所需的JSON 與JavaScript 文件,或者拒絕執(zhí)行CSRF 攻擊中所要求的操作(如轉(zhuǎn)賬).盡管Referer 對(duì)同源策略進(jìn)行了加強(qiáng),但是卻被認(rèn)為是導(dǎo)致信息泄漏的另一種方式[80,81],其原因在于:一個(gè)網(wǎng)站可以通過(guò)Referer 來(lái)判斷用戶(hù)通過(guò)其他哪些網(wǎng)站對(duì)其進(jìn)行了訪問(wèn),這將有助于建立網(wǎng)站排行與追蹤用戶(hù)行為,但破壞了用戶(hù)隱私.

?其次,對(duì)瀏覽器cookie 機(jī)制的增強(qiáng)可以應(yīng)對(duì)CSRF 與XSSI 攻擊.Barth 等人[11]認(rèn)為,可以通過(guò)安全令牌與cookie 機(jī)制協(xié)作的方式來(lái)應(yīng)對(duì)這些攻擊.具體來(lái)說(shuō),一個(gè)Web 應(yīng)用可以在其所有frame 的URL 鏈接中加入安全令牌.當(dāng)確保安全令牌很難被攻擊者frame 所獲取時(shí),Web 應(yīng)用服務(wù)器可以通過(guò)安全令牌進(jìn)行cookie 驗(yàn)證后的第二次認(rèn)證,用來(lái)判斷網(wǎng)絡(luò)請(qǐng)求是否來(lái)自于所允許的frame.Web 應(yīng)用同樣可以在frame 中使用XMLHttpRequestAPI 來(lái)發(fā)送請(qǐng)求,并且同時(shí)攜帶上自定義的HTTP 頭與相應(yīng)的值.當(dāng)該自定義的HTTP 頭與值不能被攻擊者frame 所獲取時(shí),Web 應(yīng)用服務(wù)器將同樣能夠區(qū)分發(fā)送網(wǎng)絡(luò)請(qǐng)求的frame 是否應(yīng)該被授權(quán).Franken 等人[82,83]發(fā)現(xiàn),目前的瀏覽器與瀏覽器擴(kuò)展中實(shí)現(xiàn)了“阻止第三方cookie”的功能.第三方cookie 是指frame 在網(wǎng)絡(luò)請(qǐng)求中攜帶的跨源的cookie,如CSRF 與XSSI 攻擊中,攻擊者frame 所利用的受害者網(wǎng)站的cookie.瀏覽器自動(dòng)阻止第三方cookie 的特性,將能夠應(yīng)對(duì)CSRF與XSSI 攻擊.Franken 等人設(shè)計(jì)了一個(gè)框架來(lái)評(píng)估瀏覽器與瀏覽器擴(kuò)展阻止第三方cookie 功能的有效性,實(shí)驗(yàn)發(fā)現(xiàn)了現(xiàn)有實(shí)現(xiàn)中的幾個(gè)缺陷,這些缺陷將導(dǎo)致阻止第三方cookie 功能被繞過(guò).

除了防御這些攻擊外,研究者們還提出了一系列的方案來(lái)幫助Web 應(yīng)用檢測(cè)其網(wǎng)頁(yè)中是否存在CSRF 攻擊.Pellegrino 等人[84]提出了一個(gè)基于模型的安全測(cè)試框架Deemon,來(lái)自動(dòng)檢測(cè)CSRF 漏洞.Deemon 能夠動(dòng)態(tài)追蹤Web 應(yīng)用中諸如網(wǎng)絡(luò)交互、服務(wù)器端執(zhí)行與數(shù)據(jù)庫(kù)操作等行為.根據(jù)追蹤到的行為,Deemon 將推斷出Web應(yīng)用對(duì)應(yīng)的模型圖,然后利用推斷的模型圖進(jìn)行圖遍歷,來(lái)識(shí)別脆弱的網(wǎng)絡(luò)請(qǐng)求.這些脆弱的網(wǎng)絡(luò)請(qǐng)求將作為CSRF 漏洞的候選,最后,Deemon 在真實(shí)的Web 應(yīng)用上對(duì)候選CSRF 漏洞進(jìn)行驗(yàn)證.實(shí)驗(yàn)發(fā)現(xiàn)了10 個(gè)著名的開(kāi)源Web 應(yīng)用上的14 個(gè)未知的CSRF 漏洞.Calzavara 等人[85,86]提出了第一種基于機(jī)器學(xué)習(xí)的方法Mitch 來(lái)進(jìn)行CSRF 漏洞檢測(cè).Mitch 將著名網(wǎng)站中的5 828 個(gè)HTTP 請(qǐng)求作為訓(xùn)練集來(lái)運(yùn)行有監(jiān)督的機(jī)器學(xué)習(xí)算法.實(shí)驗(yàn)表明,Mitch 在20 個(gè)主要的網(wǎng)站中檢測(cè)到了35 個(gè)新的CSRF 漏洞以及3 個(gè)已知形式但之前未檢測(cè)到的CSRF 漏洞.這些檢測(cè)工具將有助于提醒Web 應(yīng)用開(kāi)發(fā)者來(lái)進(jìn)行安全加固.

通常而言,檢測(cè)攻擊的防御機(jī)制并不能從根本上防御這兩類(lèi)攻擊,但能幫助Web 應(yīng)用開(kāi)發(fā)者來(lái)進(jìn)行安全加固.而通過(guò)加強(qiáng)同源策略規(guī)則與cookie 機(jī)制的兩類(lèi)方案能應(yīng)對(duì)CSRF 與XSSI 攻擊,但帶來(lái)了一些其他問(wèn)題:前者在網(wǎng)絡(luò)請(qǐng)求中攜帶了網(wǎng)頁(yè)來(lái)源,從而面臨著網(wǎng)頁(yè)隱私泄漏風(fēng)險(xiǎn);后者阻止第三方cookie,但卻對(duì)目前Web 應(yīng)用的用戶(hù)追蹤等其他需求造成了影響.

3.4 方案對(duì)比與討論

同源策略規(guī)則不足主要體現(xiàn)在3 個(gè)方面:同源策略允許第三方腳本以宿主frame 的權(quán)限執(zhí)行,攻擊者因而可以利用第三方腳本來(lái)攻破宿主frame,進(jìn)而突破同源策略的限制(見(jiàn)第3.1 節(jié));新型場(chǎng)景與策略的出現(xiàn),使得同源不同frame 需要被賦予不同的權(quán)限,但同源策略規(guī)則無(wú)法支持這些場(chǎng)景與策略(見(jiàn)第3.2 節(jié));同源策略允許一個(gè)frame 給任意源發(fā)送網(wǎng)絡(luò)請(qǐng)求,導(dǎo)致攻擊者可以利用其他瀏覽器機(jī)制來(lái)訪問(wèn)跨源資源(見(jiàn)第3.3 節(jié)).我們對(duì)這3類(lèi)安全威脅進(jìn)行總結(jié)分析,包括攻擊方式、在當(dāng)前Internet 上發(fā)起攻擊的影響范圍評(píng)估及其代表性研究工作(見(jiàn)表5).

Table 5 Comparison on security threates caused by limitations of same-origin policy表5 同源策略規(guī)則不足所引起的安全威脅對(duì)比

表6 對(duì)應(yīng)對(duì)以上安全威脅的防御機(jī)制進(jìn)行了總結(jié)分析,包括方案目標(biāo)、網(wǎng)頁(yè)加載開(kāi)銷(xiāo)、兼容性與可用性以及是否要求瀏覽器修改.總體而言,這些防御機(jī)制可以歸為兩個(gè)出發(fā)點(diǎn).

?增加強(qiáng)隔離機(jī)制:針對(duì)這些安全威脅,可以通過(guò)在同源策略的基礎(chǔ)上增加強(qiáng)隔離機(jī)制來(lái)進(jìn)行防御,包括應(yīng)對(duì)第三方腳本過(guò)度授權(quán)的4 類(lèi)防御機(jī)制(見(jiàn)第3.1.3 節(jié))、應(yīng)對(duì)同源不同frame 過(guò)度授權(quán)的前兩類(lèi)防御機(jī)制(見(jiàn)第3.2.2 節(jié))以及應(yīng)對(duì)不同源frame 過(guò)度授權(quán)的同源策略增強(qiáng)機(jī)制(見(jiàn)第3.3.2 節(jié)).實(shí)現(xiàn)強(qiáng)隔離的優(yōu)勢(shì)在于普適性,即不需要對(duì)不同的場(chǎng)景與新型策略給出不同的解決方案.但強(qiáng)隔離機(jī)制的實(shí)現(xiàn)意味著需要設(shè)計(jì)合理且安全的資源共享機(jī)制,并將引入額外的開(kāi)銷(xiāo).例如,實(shí)現(xiàn)腳本之間的強(qiáng)隔離機(jī)制TreeHouse 系統(tǒng)帶來(lái)了接近15 倍的網(wǎng)頁(yè)加載開(kāi)銷(xiāo)[30],實(shí)現(xiàn)同源不同frame 之間強(qiáng)隔離的COWL 系統(tǒng)也帶來(lái)了16%的開(kāi)銷(xiāo)[60].這意味著實(shí)現(xiàn)強(qiáng)隔離的防御機(jī)制需要進(jìn)一步優(yōu)化,以保證隔離與資源共享的開(kāi)銷(xiāo)是在可接受的范圍內(nèi).

?實(shí)現(xiàn)權(quán)限控制:產(chǎn)生以上安全威脅的原因之一是新型場(chǎng)景與策略要求更細(xì)粒度的權(quán)限控制.例如,內(nèi)容安全策略作用于frame 上,從而導(dǎo)致同源不同frame 被賦予了不同的權(quán)限[10];但Web 應(yīng)用開(kāi)發(fā)者可以利用CSPAutoGen[68]等系統(tǒng)來(lái)為同源的所有frame 設(shè)置相同的內(nèi)容安全策略規(guī)則,從而消除同源不同frame 權(quán)限的不一致性.此類(lèi)防御方案通常針對(duì)于特定的場(chǎng)景或者策略,并且對(duì)目前Internet 上的網(wǎng)站可能帶來(lái)兼容性問(wèn)題,如CSPAutoGen 系統(tǒng)對(duì)Alexatop 50 網(wǎng)站中的22 個(gè)網(wǎng)站的UI 產(chǎn)生了細(xì)微的變化.然而,這一類(lèi)機(jī)制不需要對(duì)同源策略規(guī)則進(jìn)行變化,因而通常不需要對(duì)瀏覽器進(jìn)行修改或需要網(wǎng)頁(yè)開(kāi)發(fā)者對(duì)編寫(xiě)習(xí)慣進(jìn)行調(diào)整,并能對(duì)新型策略的設(shè)計(jì)與配置提供安全保障.

Table 6 Comparison on defenses against the limitations of same-origin policy表6 針對(duì)同源策略規(guī)則不足的防御方案對(duì)比

3.5 小 結(jié)

同源策略規(guī)則的設(shè)計(jì)在考慮安全性的同時(shí),需要滿足Web 應(yīng)用所需的功能,因而允許了諸如允許發(fā)送跨源網(wǎng)絡(luò)請(qǐng)求與嵌入第三方腳本等操作,從而造成同一個(gè)frame 中第三方腳本的過(guò)度授權(quán)、同源不同frame 的過(guò)度授權(quán)、甚至不同源frame 的過(guò)度授權(quán).這些安全威脅是策略設(shè)計(jì)對(duì)使用便利性的妥協(xié),也意味著安全的瀏覽器環(huán)境必須要求策略設(shè)計(jì)者更合理的策略構(gòu)建以及Web 應(yīng)用開(kāi)發(fā)者更安全的網(wǎng)頁(yè)編寫(xiě).Web 應(yīng)用開(kāi)發(fā)者不應(yīng)盲目依靠同源策略來(lái)確保網(wǎng)站安全,還需要深入了解同源策略規(guī)則,并采取一系列的方案來(lái)應(yīng)對(duì)一些同源策略規(guī)則所帶來(lái)的不足.

4 跨域/跨源通信機(jī)制安全威脅及應(yīng)對(duì)

瀏覽器根據(jù)同源策略來(lái)控制JavaScript 代碼對(duì)資源的訪問(wèn),然而隨著Web 的發(fā)展與Web 應(yīng)用功能的復(fù)雜化,越來(lái)越多的需要寬松的同源策略場(chǎng)景隨之出現(xiàn).這些場(chǎng)景可以分為兩類(lèi):一是同父域名下跨源通信,二是不同域名下的跨域通信.在第1 類(lèi)場(chǎng)景下,一個(gè)域名的所有者需要搭建多種服務(wù)(如郵件、搜索以及新聞等),這些服務(wù)分別搭建在不同的子域名下,但是有可能需要互相交互;在第2 類(lèi)場(chǎng)景下,一個(gè)網(wǎng)站希望借助于第三方的網(wǎng)站來(lái)完成某些特定任務(wù),如用戶(hù)追蹤和性能分析等,該網(wǎng)站需要將某些數(shù)據(jù)分享給第三方網(wǎng)站.

為適應(yīng)Web 應(yīng)用的新型場(chǎng)景,跨域/跨源通信機(jī)制隨之而來(lái).根據(jù)是否需要服務(wù)器端的參與,這些跨域/跨源通信機(jī)制可以分為兩大類(lèi):無(wú)服務(wù)器輔助通信機(jī)制與服務(wù)器輔助通信機(jī)制.無(wú)服務(wù)器輔助通信機(jī)制依賴(lài)于特定的JavaScriptAPI,發(fā)送方通過(guò)調(diào)用document.domain[87]修改自身身份來(lái)實(shí)現(xiàn)同域名下跨源通信,也可以通過(guò)調(diào)用postMessage[57]來(lái)向跨域的接收方發(fā)送需要共享的消息.服務(wù)器輔助通信機(jī)制既可以依賴(lài)于特定的瀏覽器策略——跨域資源共享(CORS)[88],也可以由開(kāi)發(fā)者利用一些HTML 特性來(lái)自定義實(shí)現(xiàn),如JSON-P[89].圖5 總結(jié)了兩大類(lèi)跨域/跨源通信機(jī)制的發(fā)展過(guò)程,本節(jié)將重點(diǎn)對(duì)這兩類(lèi)機(jī)制的現(xiàn)有研究工作進(jìn)行總結(jié)分析.

Fig.5 Cross-domain/cross-origin communication mechanisms圖5 跨域/跨源通信機(jī)制

4.1 無(wú)服務(wù)器輔助通信機(jī)制威脅與應(yīng)對(duì)

4.1.1 document.domain 跨域通信

(1) 機(jī)制概述

網(wǎng)頁(yè)可以通過(guò)對(duì)document.domain 的賦值來(lái)將自身提升為父域名.舉例來(lái)說(shuō),一個(gè)網(wǎng)頁(yè)的URL 為http://mail.xyz.com:8080/index.html,則該網(wǎng)頁(yè)的源為三元組〈http,mail.xyz.com,8080〉,當(dāng)該網(wǎng)頁(yè)執(zhí)行了document.domain=“xyz.com”后,瀏覽器將該網(wǎng)頁(yè)的源更新為三元組〈http,xyz.com,null〉.注意,源中的端口字段被設(shè)置為空(null).當(dāng)目標(biāo)網(wǎng)頁(yè)來(lái)自于父域名(如http://xyz.com:8080/)或者兄弟域名(如http://video.xyz.com:8080/),并且執(zhí)行了document.domain=“xyz.com”時(shí),目標(biāo)網(wǎng)頁(yè)的源更新為三元組〈http,xyz.com,null〉.此時(shí),瀏覽器的同源策略將本網(wǎng)頁(yè)與目標(biāo)網(wǎng)頁(yè)視為同源,從而允許資源訪問(wèn).特別地,一個(gè)網(wǎng)頁(yè)不能設(shè)置document.domain 為頂級(jí)域名,如.com,.org 等,且〈http,xyz.com,8080〉與〈http,xyz.com,null〉不同源.

(2) 安全威脅與應(yīng)對(duì)

使用document.domain 進(jìn)行跨源通信的安全威脅,是同源策略在處理資源訪問(wèn)上的不一致性.Singh 等人[13]闡述了這種不一致性,并據(jù)此構(gòu)造了多種攻擊來(lái)繞過(guò)同源策略的限制.一個(gè)源的資源包含了DOM 和JavaScript對(duì)象、cookie、本地存儲(chǔ)以及用來(lái)發(fā)起網(wǎng)絡(luò)請(qǐng)求與獲取網(wǎng)絡(luò)響應(yīng)的XMLHttpRequestAPI.當(dāng)一個(gè)網(wǎng)頁(yè)使用document.domain 進(jìn)行域名提升后,我們稱(chēng)提升后的源為該網(wǎng)頁(yè)的有效標(biāo)識(shí)(effective ID).在域名提升之后,當(dāng)該網(wǎng)頁(yè)訪問(wèn)其他網(wǎng)頁(yè)的DOM 和JavaScript 對(duì)象時(shí),同源策略將使用有效標(biāo)識(shí)進(jìn)行決策.但是,對(duì)于cookie 和本地存儲(chǔ)的訪問(wèn)以及XMLHttpRequest 的使用,同源策略仍然使用該網(wǎng)頁(yè)初始的源作為訪問(wèn)主體標(biāo)識(shí).基于同源策略在檢查資源訪問(wèn)時(shí)處理有效標(biāo)識(shí)的不一致性,攻擊者網(wǎng)頁(yè)能夠構(gòu)造攻擊來(lái)偷取受害者網(wǎng)頁(yè)的cookie 與本地存儲(chǔ)、獲取受害者網(wǎng)站服務(wù)器數(shù)據(jù)(如獲取用戶(hù)郵箱等)或更改受害者網(wǎng)站服務(wù)器狀態(tài)(如轉(zhuǎn)賬等操作).

圖6 給出了通過(guò)利用這種不一致性來(lái)獲取跨源cookie 與網(wǎng)絡(luò)資源的攻擊.在這一類(lèi)攻擊中,受害者網(wǎng)站(x.a.com)上有一個(gè)網(wǎng)頁(yè)(1.html)使用document.domain 將其有效標(biāo)識(shí)設(shè)置為a.com,這種域名提升將允許1.html訪問(wèn)a.com 的某些資源.然而,當(dāng)攻擊者擁有來(lái)自于y.a.com 的網(wǎng)頁(yè)attacker.html 時(shí),攻擊者將具備發(fā)起此類(lèi)攻擊的條件.具體攻擊過(guò)程如下.

1)attacker.html 向1.html 注入腳本.由于attacker.html 與1.html 的有效標(biāo)識(shí)一致,同源策略將允許attacker.html 訪問(wèn)1.html 的DOM 對(duì)象,從而實(shí)現(xiàn)惡意腳本的注入.

2)注入到1.html 中的惡意腳本發(fā)起攻擊.如圖6(a)所示,惡意腳本可以訪問(wèn)與1.html 同源的2.html,從而可以借助2.html 獲取x.a.com 的cookie,并返回給attacker.html;如圖6(b)所示,惡意腳本可以直接調(diào)用XMLHttpRequestAPI 向x.a.com 服務(wù)器發(fā)送惡意網(wǎng)絡(luò)請(qǐng)求,并成功獲取服務(wù)器返回的網(wǎng)絡(luò)響應(yīng).

Fig.6 Two attacks by using the inconsistency of same-origin policy on document.domain[13]圖6 利用同源策略對(duì)document.domain 機(jī)制的不一致性發(fā)起的兩種攻擊[13]

Singh 等人[13]認(rèn)為,解決這種攻擊的措施是讓同源策略在處理cookie 與XMLHttpRequest 等API 時(shí)也使用有效標(biāo)識(shí).然而,采用這種措施可能會(huì)造成其他的安全問(wèn)題.例如,來(lái)自于y.a.com 的惡意網(wǎng)頁(yè)attacker.html 在提升域名為a.com 后,將能夠獲取a.com 的cookie.考慮到這些安全問(wèn)題的存在,到目前為止,仍然沒(méi)有被廣泛接受的防御方案,而目前的瀏覽器依然受到這一系列攻擊的影響.值得慶幸的是:發(fā)起這類(lèi)攻擊需要攻擊者擁有一個(gè)與受害者網(wǎng)頁(yè)的兄弟域名,這在一定程度上增加了攻擊者發(fā)起攻擊的難度與成本.但不論如何,研究一種不影響可用性且能防御該類(lèi)攻擊的方案是很有必要的.

4.1.2 postMessage 跨源通信

(1) 機(jī)制概述

基于document.domain 的通信機(jī)制要求通信雙方網(wǎng)頁(yè)具備相同的域名后綴,而基于postMessage 的通信機(jī)制沒(méi)有這一限制,從而允許向任意源的網(wǎng)頁(yè)發(fā)送數(shù)據(jù).由于網(wǎng)頁(yè)大量地內(nèi)嵌第三方網(wǎng)頁(yè)用作用戶(hù)追蹤、性能分析等,postMessage 得以廣泛使用[90].

圖7 給出了postMessageAPI 的使用示例.在該示例中,來(lái)自alice.com 的frameA使用iframe 標(biāo)簽內(nèi)嵌了來(lái)自bob.com 的子frameB,因此,frameB的window.parent 將指向frameA的window 對(duì)象.FrameB執(zhí)行了window.parent.postMessage 來(lái)向frameA(由window.parent 指定)發(fā)送跨源消息.postMessage 的第1 個(gè)參數(shù)為消息內(nèi)容,第2 個(gè)參數(shù)為預(yù)期接收者的源.當(dāng)frameA收到消息時(shí),frameA中事先注冊(cè)的消息處理函數(shù)handler(可自定義)將被調(diào)用,其參數(shù)為event,包含3 個(gè)成員:event.source(發(fā)送方的window 對(duì)象),event.data(消息內(nèi)容),event.origin(發(fā)送方的源).FrameA可以使用event.source.postMessage 向frameB返回消息.

Fig.7 Example usage for postMessage communication mechanisms圖7 postMessage 通信機(jī)制的使用示例

(2) 安全威脅與應(yīng)對(duì)

postMessage 在2007 年被提出時(shí),僅僅提供了一個(gè)參數(shù)來(lái)傳輸要發(fā)送的消息內(nèi)容.Barth 等人[59]發(fā)現(xiàn)了postMessage 無(wú)法滿足機(jī)密性要求.如圖8(a)所示,受害者網(wǎng)頁(yè)內(nèi)嵌了一個(gè)第三方網(wǎng)頁(yè),并使用postMessage 來(lái)傳輸數(shù)據(jù),該數(shù)據(jù)可能是用戶(hù)的隱私數(shù)據(jù).例如,受害者網(wǎng)頁(yè)可能借助第三方網(wǎng)頁(yè)來(lái)驗(yàn)證用戶(hù)口令強(qiáng)度,此時(shí)的用戶(hù)口令將使用postMessage 的方式傳輸給第三方網(wǎng)頁(yè).在這種情況下,攻擊者誘導(dǎo)用戶(hù)訪問(wèn)其網(wǎng)頁(yè),該網(wǎng)頁(yè)內(nèi)嵌了受害者網(wǎng)頁(yè),進(jìn)而內(nèi)嵌了第三方網(wǎng)頁(yè).由于第三方網(wǎng)頁(yè)為攻擊者網(wǎng)頁(yè)的孫子網(wǎng)頁(yè),攻擊者網(wǎng)頁(yè)可以對(duì)第三方網(wǎng)頁(yè)進(jìn)行導(dǎo)航(修改window.location.href 變量),導(dǎo)致瀏覽器將第三方網(wǎng)頁(yè)重新加載為攻擊者網(wǎng)頁(yè)(如圖8(b)所示).此時(shí),受害者網(wǎng)頁(yè)通過(guò)postMessage 發(fā)送的秘密數(shù)據(jù)將被重新加載后的攻擊者網(wǎng)頁(yè)所接收,導(dǎo)致秘密數(shù)據(jù)泄漏.

這種針對(duì)postMessage 機(jī)密性的攻擊成功的原因在于,瀏覽器未考慮第三方網(wǎng)頁(yè)被重新加載為攻擊者網(wǎng)頁(yè).Barth 等人[59]建議postMessageAPI 增加第2 個(gè)參數(shù),用來(lái)表明發(fā)送方預(yù)期的接收方的源.當(dāng)瀏覽器將受害者發(fā)送的秘密數(shù)據(jù)提交給第三方網(wǎng)頁(yè)時(shí),瀏覽器判斷第三方網(wǎng)頁(yè)是否仍然屬于原來(lái)的源.在圖8 的攻擊中,由于第三方網(wǎng)頁(yè)被重新加載,其源變化為攻擊者網(wǎng)頁(yè),導(dǎo)致瀏覽器對(duì)源的判斷失敗,瀏覽器將拒絕向該攻擊者網(wǎng)頁(yè)轉(zhuǎn)發(fā)原來(lái)的消息,從而攻擊者無(wú)法獲取到受害者網(wǎng)頁(yè)的秘密數(shù)據(jù).HTML 標(biāo)準(zhǔn)據(jù)此對(duì)postMessageAPI 進(jìn)行了修改而引入了第2 個(gè)參數(shù),目前,瀏覽器已經(jīng)能夠抵抗圖8 所示的攻擊.

Fig.8 Attacks on the confidentiality of postMessage communication mechanisms圖8 針對(duì)postMessage 通信機(jī)制機(jī)密性的攻擊

在此之后,Son 等人[14]發(fā)現(xiàn)了使用postMessageAPI 的另一個(gè)安全威脅.postMessage 涉及到消息發(fā)送方與接收方,接收方需要驗(yàn)證消息是否來(lái)自于合法的發(fā)送方;否則,惡意的消息發(fā)送方(攻擊者網(wǎng)頁(yè))能夠通過(guò)消息來(lái)在接收方(受害者網(wǎng)頁(yè))實(shí)現(xiàn)數(shù)據(jù)注入攻擊.例如,當(dāng)接收方網(wǎng)頁(yè)將消息中的某些字段寫(xiě)入cookie 時(shí),攻擊者可以通過(guò)消息來(lái)篡改接收方網(wǎng)頁(yè)的cookie 內(nèi)容;當(dāng)接收方網(wǎng)頁(yè)將消息中一些字段利用JavaScript 提供的eval 等API來(lái)當(dāng)成代碼執(zhí)行時(shí),攻擊者可以在受害者網(wǎng)頁(yè)中執(zhí)行任意代碼.HTML5 標(biāo)準(zhǔn)中明確指出,消息接收方需要判斷發(fā)送方的源[91].然而,Son 等人[14]對(duì)現(xiàn)有的Alexatop 10000 網(wǎng)頁(yè)進(jìn)行了調(diào)研分析,發(fā)現(xiàn)現(xiàn)有網(wǎng)頁(yè)中存在不足.

?2 245 個(gè)網(wǎng)站上使用了postMessageAPI;1 585 個(gè)網(wǎng)站沒(méi)有對(duì)發(fā)送方進(jìn)行驗(yàn)證.

?261 個(gè)網(wǎng)站對(duì)發(fā)送方的源進(jìn)行了驗(yàn)證,但是驗(yàn)證方式是不安全的.例如,有網(wǎng)站對(duì)發(fā)送方判斷的代碼為if(m.origin.indexOf(“sharethis.com”)!=?1),這使得任意在源中含有sharethis.com 的網(wǎng)頁(yè)發(fā)送的消息都會(huì)被接收方所接受,此時(shí),攻擊者可以通過(guò)注冊(cè)類(lèi)似于sharethis.com.malicious.com 或者evilsharethis.com 等域名來(lái)發(fā)起攻擊.

?在未對(duì)發(fā)送方源進(jìn)行驗(yàn)證或進(jìn)行不安全驗(yàn)證的網(wǎng)站中,84 個(gè)網(wǎng)站允許攻擊者網(wǎng)頁(yè)在接收方網(wǎng)頁(yè)執(zhí)行任意代碼,或者往本地存儲(chǔ)中注入任意內(nèi)容.

針對(duì)這一類(lèi)安全威脅,Son 等人[14]提出了兩種防御方式:第1 種方式要求發(fā)送方與接收方事先構(gòu)造某個(gè)秘密數(shù)據(jù),由于同源策略限制,使得只有與發(fā)送方具備相同源的網(wǎng)頁(yè)能夠訪問(wèn)這個(gè)秘密數(shù)據(jù),接收方消息處理函數(shù)可以通過(guò)驗(yàn)證該秘密數(shù)據(jù)來(lái)判斷發(fā)送方是否為授權(quán)方;第2 種方式要求接收方組合event.origin 與event.source來(lái)驗(yàn)證發(fā)送方身份,合理地組合這兩個(gè)對(duì)象,能夠?qū)崿F(xiàn)接收方只接受某個(gè)特定源的特定網(wǎng)頁(yè)發(fā)送的消息.Weissbacher 等人[92]提出了一個(gè)檢測(cè)這類(lèi)安全威脅的系統(tǒng)ZigZag.通過(guò)透明地在網(wǎng)頁(yè)代碼中插樁,ZigZag 能夠在瀏覽器執(zhí)行過(guò)程中實(shí)時(shí)地執(zhí)行不變量檢測(cè).從這些不變量中,ZigZag 推斷出網(wǎng)頁(yè)代碼的正常行為模型,這些模型捕獲客戶(hù)端Web 應(yīng)用程序組件如何交互(以及與誰(shuí)交互)的基本屬性以及與瀏覽器中的控制流和數(shù)據(jù)值相關(guān)的屬性.使用這些模型,ZigZag 可以自動(dòng)檢測(cè)與這類(lèi)安全威脅高度相關(guān)的模型的偏差.

此外,瀏覽器的事件機(jī)制使得postMessageAPI 存在隱私泄漏的風(fēng)險(xiǎn).Guan 等人[93,94]針對(duì)于這類(lèi)安全威脅給出了具體的攻擊場(chǎng)景與攻擊方案,并且提供了對(duì)應(yīng)的抵抗措施.Guan 等人首先分析了目前的網(wǎng)頁(yè)中一個(gè)普遍的使用范例.當(dāng)網(wǎng)頁(yè)A內(nèi)嵌第三方網(wǎng)頁(yè)B并使用postMessageAPI 進(jìn)行通信時(shí),目前網(wǎng)頁(yè)開(kāi)發(fā)者傾向于在網(wǎng)頁(yè)A中引入B的一個(gè)腳本當(dāng)作第三方庫(kù),這個(gè)第三方庫(kù)將在網(wǎng)頁(yè)A中注冊(cè)消息處理函數(shù)來(lái)完成諸如消息格式解析等任務(wù).據(jù)此,網(wǎng)頁(yè)開(kāi)發(fā)者不需要了解網(wǎng)頁(yè)B的消息通信機(jī)制,使得開(kāi)發(fā)更加便利.然而,當(dāng)網(wǎng)頁(yè)A由于功能需求需要內(nèi)嵌多個(gè)第三方網(wǎng)頁(yè)(如B和C)時(shí),B和C都將在網(wǎng)頁(yè)A中注冊(cè)消息處理函數(shù).當(dāng)網(wǎng)頁(yè)A收到消息時(shí),根據(jù)瀏覽器的事件機(jī)制,所有在網(wǎng)頁(yè)A中注冊(cè)的消息處理函數(shù)都會(huì)被觸發(fā),這意味著網(wǎng)頁(yè)B向A發(fā)送的消息將能夠被C所監(jiān)聽(tīng).當(dāng)消息中存在秘密數(shù)據(jù)如cookie 時(shí),用戶(hù)在B網(wǎng)站上的隱私將可能會(huì)被C所破壞.

Guan 等人[93]將這類(lèi)攻擊稱(chēng)之為DangerNeighbor 攻擊.他們還對(duì)目前top 5000 的網(wǎng)站進(jìn)行了調(diào)研分析,發(fā)現(xiàn)28.8%的網(wǎng)站注冊(cè)了消息處理函數(shù),10.88%的網(wǎng)站注冊(cè)了來(lái)自不同源的多個(gè)處理函數(shù),因而可以認(rèn)為,10.88%的網(wǎng)站可能會(huì)受到DangerNeighbor 攻擊的影響.為抵抗DangerNeighbor 攻擊,發(fā)送方需要發(fā)送加密數(shù)據(jù)而非消息明文;接收方利用JavaScript 函數(shù)的特性,封裝注冊(cè)消息處理函數(shù),同時(shí)封裝的處理函數(shù)負(fù)責(zé)調(diào)用相應(yīng)的原處理函數(shù),而其他處理函數(shù)不被調(diào)用,從而解決DangerNeighbor 攻擊所帶來(lái)的隱私泄漏威脅.

4.2 服務(wù)器輔助通信機(jī)制威脅與應(yīng)對(duì)

4.2.1 JSON-P 跨源通信

(1) 機(jī)制概述

基于JSON-P 的跨源通信機(jī)制的基礎(chǔ)是同源策略允許內(nèi)聯(lián)第三方腳本.如圖9 所示:來(lái)自于alice.com 的網(wǎng)頁(yè)可以借助〈script〉來(lái)內(nèi)聯(lián)一個(gè)跨域的網(wǎng)站bob.com 的腳本data.js,雖然該網(wǎng)頁(yè)無(wú)法讀取data.js 的內(nèi)容,但是同源策略允許data.js 在該網(wǎng)頁(yè)中執(zhí)行.此時(shí),若bob.com 希望把自己的某些數(shù)據(jù)共享,其可以在data.js 中調(diào)用一個(gè)my_callback 函數(shù),其參數(shù)為需要共享的數(shù)據(jù),并且以JSON 的形式存在.當(dāng)alice.com 的網(wǎng)頁(yè)事先定義了my_callback 函數(shù)時(shí),data.js 將調(diào)用該預(yù)先定義的函數(shù),從而網(wǎng)頁(yè)可以獲取到來(lái)自跨源的bob.com 的數(shù)據(jù),實(shí)現(xiàn)跨源或跨域資源共享.特別注意的是:JSON-P 只能支持GET 請(qǐng)求,不能支持POST 等其他請(qǐng)求.

Fig.9 Example usage for JSON-P cross-origin communication mechanisms圖9 JSON-P 跨源通信機(jī)制的使用示例

(2) 安全威脅

基于JSON-P 實(shí)現(xiàn)的跨域機(jī)制依賴(lài)于同源策略對(duì)引入跨域腳本的允許以及服務(wù)器端的輔助,其面對(duì)的一個(gè)最大的安全威脅是如何防止攻擊者網(wǎng)頁(yè)(如https://alice.com/index.html)訪問(wèn)服務(wù)器想要共享的JSON-P 資源(如https://bob.com/data.js).Popescu[15]按照服務(wù)器端共享資源的方式,總結(jié)了惡意獲取JSON-P 資源的幾種途徑.

?如果data.js 中調(diào)用了特定函數(shù)來(lái)返回共享資源(my_callback({‘data’:data})),攻擊者網(wǎng)頁(yè)可以通過(guò)先定義my_callback 函數(shù),再內(nèi)聯(lián)data.js 來(lái)惡意獲取資源.

?如果data.js 中調(diào)用了對(duì)象成員函數(shù)來(lái)返回共享資源(System.TransactionData.Fetch({‘data’:data})),攻擊者可以通過(guò)事先依次定義對(duì)象(System.TransactionData)與對(duì)象成員Fetch 函數(shù)來(lái)惡意獲取資源.

?如果data.js 允許通過(guò)URL 來(lái)指定回調(diào)函數(shù),攻擊者可以通過(guò)自定義函數(shù)來(lái)惡意獲取資源.例如,當(dāng)URL為https://bob.com/data.js?callback=my_callback 時(shí),data.js 將調(diào)用my_callback 函數(shù).此時(shí),攻擊者網(wǎng)頁(yè)可以通過(guò)定義my_callback 函數(shù),再內(nèi)聯(lián)以上URL 的腳本來(lái)獲取資源.

?如果data.js 利用URL 指定的字段并加入數(shù)字來(lái)指定回調(diào)函數(shù),攻擊者可以通過(guò)先遍歷所有可能的回調(diào)函數(shù)名稱(chēng),并定義對(duì)應(yīng)函數(shù)來(lái)獲取資源.

最后,攻擊者網(wǎng)頁(yè)可以通過(guò)網(wǎng)絡(luò)通信來(lái)將獲取的惡意數(shù)據(jù)返回給攻擊者服務(wù)器.此外,Grossman[75]發(fā)現(xiàn),可以攻擊使用JSON-P 機(jī)制的Google 郵件網(wǎng)站.當(dāng)用戶(hù)事先登錄了Google 郵件網(wǎng)站后,瀏覽器中維護(hù)了用戶(hù)對(duì)應(yīng)的cookie.當(dāng)用戶(hù)cookie 沒(méi)有過(guò)期的情況下,用戶(hù)被誘導(dǎo)訪問(wèn)了攻擊者網(wǎng)頁(yè),該攻擊者網(wǎng)頁(yè)嵌入了Google 郵件網(wǎng)站的腳本(如http://mail.google.com/mail/?_url_scrubbed_來(lái)獲取聯(lián)系人列表).由于瀏覽器在發(fā)送網(wǎng)絡(luò)請(qǐng)求時(shí)會(huì)自動(dòng)攜帶對(duì)應(yīng)的cookie,Google 郵件服務(wù)器將會(huì)返回受害者用戶(hù)的聯(lián)系人列表.聯(lián)系人列表在JavaScript 中將會(huì)轉(zhuǎn)為數(shù)組Array,攻擊者網(wǎng)頁(yè)可以通過(guò)事先重載Array 對(duì)象來(lái)讀取聯(lián)系人列表.這種攻擊是XSSI 攻擊(見(jiàn)第3.1.1節(jié))的一個(gè)例子,JSON-P 機(jī)制為發(fā)起XSSI 攻擊創(chuàng)造了條件.

4.2.2 CORS 跨域資源共享

(1) 機(jī)制概述

Web 的Fetch 標(biāo)準(zhǔn)[95]定義了CORS 機(jī)制的基本規(guī)范,來(lái)允許一個(gè)frame 獲取跨源服務(wù)器的網(wǎng)絡(luò)響應(yīng).CORS中定義了兩類(lèi)請(qǐng)求:簡(jiǎn)單請(qǐng)求與非簡(jiǎn)單請(qǐng)求.前者要求請(qǐng)求方法為HEAD,GET 或POST,且HTTP 頭信息為預(yù)先定義的幾種字段(如Accept,Content-Language 等);后者采用諸如PUT,DELETE 之類(lèi)的請(qǐng)求方法,或使用一些其他的HTTP 頭字段.非簡(jiǎn)單請(qǐng)求被認(rèn)為是可能存在安全風(fēng)險(xiǎn)的網(wǎng)絡(luò)請(qǐng)求.

對(duì)于簡(jiǎn)單請(qǐng)求,CORS 要求瀏覽器在發(fā)送網(wǎng)絡(luò)請(qǐng)求時(shí)增加名為ORIGIN 的HTTP 頭,用來(lái)說(shuō)明請(qǐng)求網(wǎng)頁(yè)的源;若目標(biāo)服務(wù)器允許該源訪問(wèn),則在網(wǎng)絡(luò)響應(yīng)中增加Access-Control-Allow-Origin 的HTTP 頭,值為服務(wù)器允許訪問(wèn)網(wǎng)絡(luò)響應(yīng)的源;瀏覽器在收到網(wǎng)絡(luò)響應(yīng)后,僅當(dāng)請(qǐng)求網(wǎng)頁(yè)的源被包含在Access-Control-Allow-Origin 中時(shí),才允許請(qǐng)求網(wǎng)頁(yè)訪問(wèn)網(wǎng)絡(luò)響應(yīng).

非簡(jiǎn)單請(qǐng)求需要事先執(zhí)行預(yù)檢協(xié)議(preflight).在預(yù)檢協(xié)議中,瀏覽器采用OPTIONS 請(qǐng)求方法,其中包含了Access-Control-Request-Method 來(lái)指定跨源請(qǐng)求的請(qǐng)求方法(如PUT)以及Access-Control-Request-Headers 來(lái)表示跨源請(qǐng)求中特殊或者自定義的HTTP 頭字段.服務(wù)器若允許該源訪問(wèn)資源,將返回Access-Control-Allow-Origin,Access-Control-Allow-Methods 與Access-Control-Allow-Headers 來(lái)表示允許資源共享的源、請(qǐng)求方法以及HTTP 頭;當(dāng)瀏覽器發(fā)現(xiàn)服務(wù)器允許時(shí),將執(zhí)行簡(jiǎn)單請(qǐng)求對(duì)應(yīng)的協(xié)議來(lái)讓網(wǎng)頁(yè)訪問(wèn)跨源服務(wù)器數(shù)據(jù).此外,為了提高性能,CORS 機(jī)制還提供了Access-Control-Max-Age 頭字段來(lái)讓瀏覽器緩存預(yù)檢協(xié)議的結(jié)果.

(2) 安全威脅

Chen 等人[16]對(duì)CORS 在現(xiàn)實(shí)世界網(wǎng)頁(yè)中的實(shí)際應(yīng)用進(jìn)行了實(shí)證研究.通過(guò)對(duì)CORS 的設(shè)計(jì)、實(shí)現(xiàn)和部署的分析,他們發(fā)現(xiàn),CORS 受到許多新的安全問(wèn)題的影響.考慮到這些安全風(fēng)險(xiǎn),Chen 等人提出了一些建議來(lái)對(duì)協(xié)議進(jìn)行簡(jiǎn)化和澄清,包括對(duì)簡(jiǎn)單請(qǐng)求也進(jìn)行對(duì)應(yīng)的預(yù)檢、對(duì)簡(jiǎn)單請(qǐng)求攜帶的HTTP 頭與內(nèi)容的格式與編碼等進(jìn)行額外的限制等.其中一些建議已經(jīng)被CORS 規(guī)范和主流瀏覽器采用.

CORS 機(jī)制的第1 類(lèi)安全風(fēng)險(xiǎn),是CORS 協(xié)議實(shí)現(xiàn)放寬了跨源“寫(xiě)”特權(quán).CORS 對(duì)于簡(jiǎn)單請(qǐng)求沒(méi)有預(yù)檢階段.對(duì)于簡(jiǎn)單請(qǐng)求中允許的9 個(gè)HTTP 頭字段,RFC7231 中明確指出其中的4 個(gè)字段有格式的限制(如Accept、Accept-Language、Content-Language 以及Content-Type).然而目前,主流瀏覽器中只有Safari 進(jìn)行了格式限制,而且所有主流的瀏覽器對(duì)Content-Type 字段的限制都是基于前綴匹配.這意味著攻擊者網(wǎng)頁(yè)在簡(jiǎn)單請(qǐng)求中攜帶惡意負(fù)載,服務(wù)器對(duì)HTTP 頭信息不安全的解析將造成安全威脅.Chen 等人證明了,不安全的格式檢查能夠使得攻擊者網(wǎng)頁(yè)在Apache 服務(wù)器端遠(yuǎn)程執(zhí)行代碼.此外,CORS 沒(méi)有對(duì)簡(jiǎn)單請(qǐng)求HTTP 頭信息的總字段進(jìn)行限制,而瀏覽器通常對(duì)HTTP 請(qǐng)求長(zhǎng)度存在限制,超過(guò)長(zhǎng)度限制將返回HTTP 400 錯(cuò)誤,否則正常返回HTTP 200.這種不一致性,可以允許攻擊者網(wǎng)頁(yè)通過(guò)構(gòu)造CORS 請(qǐng)求來(lái)推斷受害者網(wǎng)頁(yè)是否存在cookie 等信息.推斷cookie 的存在能夠被用來(lái)偷取受害者用戶(hù)的隱私,如用戶(hù)登錄了醫(yī)院網(wǎng)站,可以推斷出用戶(hù)可能存在某些病癥.另外,CORS 請(qǐng)求對(duì)HTTP 內(nèi)容也沒(méi)有格式或者編碼的限制,這也能造成安全風(fēng)險(xiǎn).

CORS 機(jī)制的第2 類(lèi)安全風(fēng)險(xiǎn),是其為網(wǎng)絡(luò)交互引入了新的風(fēng)險(xiǎn)信任依賴(lài).CORS 機(jī)制使得一個(gè)網(wǎng)站能夠訪問(wèn)跨源服務(wù)器的資源,導(dǎo)致跨源服務(wù)器與請(qǐng)求網(wǎng)站存在信任依賴(lài).如此,當(dāng)攻擊者有機(jī)會(huì)攻破跨源服務(wù)器某個(gè)允許訪問(wèn)的網(wǎng)站時(shí),跨源服務(wù)器的資源將會(huì)被泄漏,這種情況在HTTPS 服務(wù)器信任HTTP 同網(wǎng)站網(wǎng)頁(yè)時(shí)最為明顯.

CORS 機(jī)制的第3 類(lèi)安全風(fēng)險(xiǎn),是其配置通常不被開(kāi)發(fā)人員很好地理解.由于它的無(wú)表達(dá)策略和它與其他Web 機(jī)制的復(fù)雜的交互,CORS 協(xié)議配置出現(xiàn)了各種各樣的錯(cuò)誤.開(kāi)發(fā)人員可能按照前綴、后綴或正則等匹配方式來(lái)確定允許訪問(wèn)服務(wù)器資源的源,這種匹配方式可能存在漏洞,使得攻擊者可以構(gòu)造滿足匹配的網(wǎng)址域名來(lái)惡意偷取跨源服務(wù)器的資源.

4.3 方案對(duì)比與討論

無(wú)服務(wù)器輔助的兩類(lèi)通信機(jī)制分別基于document.domain 與postMessageAPI,我們對(duì)這兩種機(jī)制進(jìn)行總結(jié)分析,包括通信范圍、攻擊后果、發(fā)起攻擊的影響范圍評(píng)估以及其在目前網(wǎng)站中的使用率(見(jiàn)表7).

Table 7 Comparison on cross-domain or cross-origin communication mechanisms without server’s intervention表7 無(wú)服務(wù)器輔助的跨域/跨源通信機(jī)制對(duì)比

其中,document.domain 局限于同一網(wǎng)站內(nèi)的資源共享,而且共享成功的兩個(gè)frame 具有任意資源訪問(wèn)權(quán)限.盡管有研究者們提出了基于document.domain 機(jī)制的安全的跨源通信通道[96],但是Web 應(yīng)用仍越來(lái)越傾向于使用postMessageAPI.然而,postMessage API 的使用范例使得Web 應(yīng)用存在數(shù)據(jù)注入攻擊與隱私泄漏的問(wèn)題,以至于1.85%至10.88%的使用postMessage 機(jī)制通信的網(wǎng)站存在被攻擊的風(fēng)險(xiǎn)[14,93].現(xiàn)有解決方案的思路在于對(duì)網(wǎng)頁(yè)代碼進(jìn)行重寫(xiě)以建立正常行為模型,或阻止其他處理函數(shù)的調(diào)用.前者存在誤報(bào)與影響正常跨源通信的風(fēng)險(xiǎn),而后者由于處理函數(shù)具備與宿主frame 相同權(quán)限而存在繞過(guò)網(wǎng)頁(yè)重寫(xiě)防御機(jī)制的缺陷.研究者們需要在這一方面進(jìn)行更進(jìn)一步的研究,以提出更合理、完善的解決方案.

在服務(wù)器輔助的跨源通信機(jī)制上,CORS 已經(jīng)被引入至HTML5 標(biāo)準(zhǔn)中,而JSON-P 是開(kāi)發(fā)者對(duì)于跨源需求所提出的方案,因此其沒(méi)有統(tǒng)一的規(guī)范來(lái)實(shí)施以解決面臨的安全問(wèn)題.此外,基于JSON-P 實(shí)現(xiàn)的跨域機(jī)制還面臨著信任問(wèn)題.因?yàn)镴SON-P 資源是作為JavaScript 立即執(zhí)行的,引入該資源腳本的網(wǎng)頁(yè)不能對(duì)JSON-P 資源執(zhí)行任何輸入驗(yàn)證.若JSON-P 資源含有惡意代碼,引入該資源腳本的網(wǎng)頁(yè)將受到攻擊.因此,導(dǎo)入第三方JSON-P資源需要完全信任第三方.Stock 等人[90]曾對(duì)目前網(wǎng)站中JSON-P 與CORS 的使用率進(jìn)行了統(tǒng)計(jì),發(fā)現(xiàn)2014 年前,JSON-P 的使用率遠(yuǎn)大于CORS.然而截至2016 年,CORS 的使用率已經(jīng)超過(guò)JSON-P 將近10%.CORS 機(jī)制相對(duì)于JSON-P 更加完善,HTML5 標(biāo)準(zhǔn)的支持也將不斷修復(fù)CORS 機(jī)制中存在的安全漏洞,因此,Web 應(yīng)用開(kāi)發(fā)者將逐漸趨向于使用CORS 來(lái)取代JSON-P.

4.4 小 結(jié)

目前的跨域/跨源通信方案最主要的4 種機(jī)制是document.domain,postMessage,JSON-P 與CORS.document.domain 只支持同網(wǎng)站下不同子域名之間的資源共享;而JSON-P 由于其在可用性與安全性上的不足,已經(jīng)基本被CORS 所替代.之后的網(wǎng)站將越來(lái)越傾向于使用postMessage 與CORS 這兩類(lèi)標(biāo)準(zhǔn)中提供的跨源通信機(jī)制.然而,postMessage 與CORS 依舊存在各種各樣的安全威脅,研究人員在不斷地分析安全威脅與提出更加安全的機(jī)制,網(wǎng)站開(kāi)發(fā)人員應(yīng)當(dāng)了解使用這些機(jī)制的風(fēng)險(xiǎn),并盡可能按照標(biāo)準(zhǔn)建議的方案進(jìn)行代碼編寫(xiě).不論如何,跨域/跨源通信機(jī)制允許不同源網(wǎng)站共享資源,這意味著網(wǎng)站的信任邊界從本網(wǎng)站自身向外擴(kuò)大,我們要認(rèn)識(shí)到信任邊界擴(kuò)大的安全威脅,不應(yīng)為了便利而盲目地使用這些通信機(jī)制.

5 內(nèi)存攻擊下的同源策略安全

使用不安全語(yǔ)言(如C/C++)開(kāi)發(fā)的軟件不可避免地存在引起內(nèi)存攻擊的漏洞,如緩沖區(qū)溢出、內(nèi)存泄漏與格式化字符串等[97].內(nèi)存攻擊的初始形式為代碼注入攻擊[98],即攻擊者在程序運(yùn)行時(shí)利用程序的漏洞注入事先準(zhǔn)備的負(fù)載(payload),然后通過(guò)將程序控制流指向負(fù)載,導(dǎo)致負(fù)載作為惡意代碼得以執(zhí)行.應(yīng)對(duì)代碼注入攻擊的防御機(jī)制是數(shù)據(jù)不可執(zhí)行(data execution prevention,簡(jiǎn)稱(chēng)DEP)機(jī)制[99].DEP 通過(guò)將數(shù)據(jù)段與代碼段分離,并確保數(shù)據(jù)段不可執(zhí)行.此后,代碼重用攻擊得以提出,例如ROP(return oriented programming)[100,101],JOP(jump oriented programming)[102,103]等.代碼重用攻擊不需要注入代碼,而是從現(xiàn)有程序代碼中找到一系列的片段(稱(chēng)為gadgets)并修改棧來(lái)鏈接gadgets.代碼重用攻擊被證明能執(zhí)行任意代碼,但控制流完整性(control flow integrity,簡(jiǎn)稱(chēng)CFI)[104,105]以及一些基于特征的啟發(fā)式方式[106,107]能夠被用來(lái)檢測(cè)與防御代碼重用攻擊.其他抵御代碼重用攻擊的方案還包括修改編譯器來(lái)使得程序沒(méi)有可利用的gadgets[108],或者通過(guò)地址空間隨機(jī)化[109]來(lái)使得攻擊者很難找到gadgets.更進(jìn)一步的,內(nèi)存攻擊還能允許攻擊者直接對(duì)內(nèi)存中的數(shù)據(jù)進(jìn)行讀取或修改(稱(chēng)之為僅數(shù)據(jù)攻擊).基于數(shù)據(jù)流的系統(tǒng)化的攻擊(data oriented programming,簡(jiǎn)稱(chēng)DOP)[110]與防御機(jī)制(data flow integrity,簡(jiǎn)稱(chēng)DFI)[111]也隨后得以提出.

瀏覽器環(huán)境的特殊性,使得內(nèi)存攻防研究進(jìn)入一個(gè)新的階段.

?代碼注入攻擊:瀏覽器通過(guò)引入在運(yùn)行 JavaScript 時(shí)編譯 JavaScript 的即時(shí)編譯器(just-in-time compiler,簡(jiǎn)稱(chēng)JIT 編譯器)來(lái)提高性能,這使得JIT 編譯后生成的代碼(稱(chēng)為JIT 代碼)所在內(nèi)存頁(yè)的權(quán)限必然是變化的:在生成JIT 代碼時(shí),內(nèi)存頁(yè)的權(quán)限為可寫(xiě);運(yùn)行JIT 代碼時(shí),內(nèi)存頁(yè)的權(quán)限為可讀.這意味著攻擊者有可能來(lái)發(fā)起代碼注入攻擊.

?代碼重用攻擊:JIT 編譯意味著一個(gè)惡意的frame 可以通過(guò)設(shè)計(jì)相應(yīng)的JavaScript 代碼來(lái)在瀏覽器中注入代碼重用攻擊所需要的gadgets,從而傳統(tǒng)的使用特定編譯器來(lái)去除gadgets 的方案并不能抵御對(duì)瀏覽器的代碼重用攻擊;而且,瀏覽器的性能需求使得利用CFI 來(lái)加固JIT 代碼是不可行的.

?僅數(shù)據(jù)攻擊:一個(gè)網(wǎng)頁(yè)中可能包含來(lái)自不同源的frame,這些不同源的代碼將在同一進(jìn)程中執(zhí)行.一個(gè)惡意frame 可以利用內(nèi)存攻擊來(lái)直接修改受害者frame 的數(shù)據(jù).

瀏覽器環(huán)境中的內(nèi)存攻擊將對(duì)同源策略安全造成破壞性的影響.成功發(fā)起代碼注入攻擊和代碼重用攻擊意味著攻擊者frame 可以直接執(zhí)行任意代碼,同源策略的安全防御能夠很容易被繞過(guò).發(fā)起僅數(shù)據(jù)攻擊可以直接讀取與修改受害者frame 的數(shù)據(jù).由于同源策略的安全監(jiān)控器與網(wǎng)頁(yè)代碼位于同一個(gè)渲染進(jìn)程里,僅數(shù)據(jù)攻擊也可以通過(guò)修改瀏覽器的元數(shù)據(jù)來(lái)欺騙同源策略的安全監(jiān)控器.考慮到瀏覽器(特別是JIT 編譯器)漏洞的不可避免性,研究分析可行的內(nèi)存攻擊以及設(shè)計(jì)合適的防御方案,是瀏覽器同源策略安全研究中不可缺少的環(huán)節(jié).本節(jié)將對(duì)現(xiàn)有瀏覽器內(nèi)存攻防研究工作進(jìn)行總結(jié)分析.

5.1 代碼注入攻擊及防御

5.1.1 攻擊方案

針對(duì)瀏覽器的代碼注入攻擊通常利用了JIT 編譯器的特性.首先,JIT 編譯器將在運(yùn)行時(shí)將JIT 代碼寫(xiě)入內(nèi)存頁(yè)中,這意味著JIT 代碼頁(yè)在某些時(shí)候需要設(shè)置為可寫(xiě).Gong 等人[18]發(fā)現(xiàn),Chrome 中的JIT 代碼頁(yè)是同時(shí)具備寫(xiě)與可執(zhí)行權(quán)限的,據(jù)此實(shí)現(xiàn)了代碼注入攻擊.具體來(lái)說(shuō),Gong 等人首先利用Chrome 的V8JavaScript 引擎中的漏洞來(lái)獲取對(duì)任意內(nèi)存地址的讀寫(xiě)權(quán)限,其后分析Chrome 代碼來(lái)追蹤到JIT 代碼的入口地址,最后通過(guò)對(duì)該地址的內(nèi)存頁(yè)的重寫(xiě)來(lái)注入惡意代碼.更進(jìn)一步地,Song 等人[17]認(rèn)為,應(yīng)對(duì)代碼注入攻擊的傳統(tǒng)W^X(不能同時(shí)可寫(xiě)與可執(zhí)行)方式在瀏覽器環(huán)境中是無(wú)用的.W^X 通過(guò)限制內(nèi)存頁(yè)的權(quán)限不能同時(shí)為可寫(xiě)與可執(zhí)行來(lái)抵抗代碼注入攻擊,然而,瀏覽器中JIT 編譯器產(chǎn)生新代碼或優(yōu)化現(xiàn)有JIT 代碼時(shí),必須將JIT 代碼頁(yè)短時(shí)間內(nèi)更改為可寫(xiě),這個(gè)短暫的時(shí)間窗口可以被敵手利用來(lái)將惡意代碼注入到JIT 內(nèi)存頁(yè)中.

其次,JIT 編譯器生成JIT 代碼的一些規(guī)則也能用來(lái)發(fā)起代碼注入攻擊.Blazakis 等人[19]提出的JITSpraying攻擊能夠利用JIT 編譯器忽略大常數(shù)的特性,來(lái)在JIT 代碼中注入所需的代碼.圖10 展示了JITSpraying 攻擊的原理.具體來(lái)說(shuō),攻擊者frame 的JavaScript 代碼可以定義一個(gè)含有大常數(shù)的變量,如:

該代碼被JIT 編譯器編譯后的二進(jìn)制代碼在圖10 中進(jìn)行了標(biāo)注,其中,對(duì)變量a賦值的大常數(shù)直接存在于JIT 代碼中.若攻擊者frame 利用控制流劫持漏洞使得程序跳轉(zhuǎn)到JIT 代碼的第2 個(gè)字節(jié)執(zhí)行,此后瀏覽器執(zhí)行的程序邏輯將被篡改.所以,攻擊者frame 可以通過(guò)合理地組織JavaScript 大常數(shù)來(lái)在JIT 代碼中注入惡意代碼.為增大控制流跳轉(zhuǎn)到注入代碼特定地址的概率,JITSpraying 攻擊要求攻擊者frame 重復(fù)地注入大量的代碼頁(yè),這一操作被稱(chēng)作為Spraying.

Fig.10 Example of injecting code into browsers by JITSpraying attack圖10 通過(guò)JITSpraying 攻擊向?yàn)g覽器中注入代碼的示例

5.1.2 防御方案

與傳統(tǒng)環(huán)境中的應(yīng)對(duì)代碼注入攻擊方案相同,瀏覽器環(huán)境中也首先需要對(duì)JIT 代碼頁(yè)采用W^X 方案.Chen等人[112]提出了JITDefender 系統(tǒng),來(lái)在JIT 編譯器中增加W^X 機(jī)制.JITDefender 機(jī)制能夠標(biāo)識(shí)JIT 代碼的兩個(gè)時(shí)間點(diǎn):JIT 編譯器生成JIT 代碼與JIT 代碼開(kāi)始被執(zhí)行.JITDefender 的工作流是在第1 個(gè)時(shí)間點(diǎn)時(shí)將JIT 代碼頁(yè)權(quán)限設(shè)置為可寫(xiě)但不可執(zhí)行,在第2 個(gè)時(shí)間點(diǎn)將JIT 代碼頁(yè)設(shè)置為可執(zhí)行但不可寫(xiě).

Crane 等人[113]設(shè)計(jì)了Readactor 架構(gòu)來(lái)實(shí)現(xiàn)僅可執(zhí)行內(nèi)存頁(yè).Readactor 設(shè)計(jì)了對(duì)應(yīng)的編譯器來(lái)將未修改的源代碼進(jìn)行轉(zhuǎn)換,其中實(shí)現(xiàn)了分離代碼和數(shù)據(jù)來(lái)消除對(duì)代碼頁(yè)的讀訪問(wèn)、隨機(jī)化代碼布局與設(shè)計(jì)跳板代碼(trampoline)來(lái)隱藏代碼指針等操作.基于該編譯器,一個(gè)應(yīng)用程序的代碼頁(yè)將不需要有讀寫(xiě)權(quán)限.Readactor 之后利用Intel 處理器所提供的擴(kuò)展頁(yè)表(extended page tables,簡(jiǎn)稱(chēng)EPT)來(lái)實(shí)現(xiàn)硬件限制的僅可執(zhí)行內(nèi)存頁(yè).目前,主流瀏覽器已經(jīng)實(shí)施了對(duì)JIT 代碼的W^X[114]保護(hù).

盡管JITDefender 與Readactor 在瀏覽器中實(shí)現(xiàn)了W^X,但JIT 編譯器在生成JIT 代碼與執(zhí)行JIT 代碼之間仍有短暫的時(shí)間窗口來(lái)發(fā)起代碼注入攻擊.基于此,Song 等人[17]建議將JIT 引擎拆分為兩個(gè)不同的進(jìn)程來(lái)應(yīng)對(duì)這種安全威脅,包括一個(gè)執(zhí)行JIT 代碼的不受信任進(jìn)程和一個(gè)發(fā)出JIT 代碼的受信任進(jìn)程.這種體系結(jié)構(gòu)可以防止JIT 內(nèi)存在不受信任的進(jìn)程中隨時(shí)可寫(xiě).由于分割JIT 引擎需要進(jìn)程間通信和消息同步,因此在JavaScript 基準(zhǔn)測(cè)試中,該方案所引入的運(yùn)行時(shí)開(kāi)銷(xiāo)高達(dá)50%.此外,Chen 等人[115]設(shè)計(jì)了JITSafe 框架來(lái)混淆JIT 代碼與縮小JIT 編譯器生成與執(zhí)行JIT 代碼的時(shí)間窗口.Frassetto 等人[116]利用地址空間隨機(jī)化技術(shù)來(lái)使得攻擊者無(wú)法獲取JIT 代碼頁(yè)的地址,從而抵抗利用該時(shí)間窗口的代碼注入攻擊.

利用JIT 編譯器忽略處理大常數(shù)的特性來(lái)發(fā)起的JITSparying 攻擊能夠更進(jìn)一步地加強(qiáng)為代碼重用攻擊,因此將在下一節(jié)中具體闡述其加強(qiáng)后的攻擊與防御方案.

5.2 代碼重用攻擊及防御

5.2.1 攻擊方案

代碼重用攻擊是通過(guò)鏈接小的代碼指令片段(gadgets)來(lái)執(zhí)行任意代碼,因而需要兩個(gè)前提:一是目標(biāo)程序中具備有足夠的gadgets,二是目標(biāo)程序存在控制流劫持漏洞使得攻擊者能夠?qū)adgets 進(jìn)行鏈接.由于軟件漏洞的不可避免,對(duì)代碼重用攻擊的攻防研究通常認(rèn)為第2 個(gè)條件是成立的,因而研究者們著重于如何在瀏覽器中尋找或注入新的gadgets.特別注意的是,代碼重用攻擊所提供的任意代碼執(zhí)行權(quán)限將能幫助攻擊者frame 直接繞過(guò)瀏覽器同源策略的限制.

Snow 等人[32]提出了JIT-ROP 攻擊,一種針對(duì)JIT 代碼的代碼重用攻擊方案.JIT-ROP 攻擊假設(shè)攻擊者frame可以通過(guò)編寫(xiě)合適的JavaScript 代碼來(lái)利用瀏覽器的漏洞,從而獲取到反復(fù)讀取任意內(nèi)存地址的能力.攻擊者可以利用該能力來(lái)跟蹤程序指針.利用程序指針的指向關(guān)系,攻擊者可以獲取到足夠多的代碼內(nèi)存頁(yè).接下來(lái),攻擊者可以對(duì)收集到的代碼內(nèi)存頁(yè)進(jìn)行分析,從中搜索到發(fā)起代碼重用攻擊所需的gadgets 以及一些特殊的API函數(shù),如加載鏈接庫(kù)等.最后,攻擊者通過(guò)利用控制流劫持漏洞來(lái)鏈接搜索到的gadgets 來(lái)調(diào)用目標(biāo)API,并提供所需的參數(shù).Snow 等人在IE 瀏覽器中成功發(fā)起了JIT-ROP 攻擊.

JIT-ROP 攻擊的工作方式是尋找已存在代碼頁(yè)中的gadagets,這并不能保證攻擊者所需要的gadgets 一定能夠被找到.考慮到JITSpraying 攻擊能夠?qū)崿F(xiàn)代碼注入,Athanasakis 等人[20]設(shè)計(jì)了結(jié)合JITSpraying 攻擊與JITROP 攻擊的代碼重用攻擊.該攻擊利用JITSpraying 攻擊中所使用的大常數(shù)來(lái)往瀏覽器中注入gadgets,然后與JIT-ROP 一樣,利用控制流劫持漏洞來(lái)將注入的gadgets 鏈接到一起,從而發(fā)起代碼重用攻擊.圖11 中展示了生成執(zhí)行mprotect 系統(tǒng)調(diào)用并提供相關(guān)參數(shù)所需的gadgets 與對(duì)應(yīng)的JavaScript 代碼.例如,在JavaScript 中為變量g3 賦值為12828721,當(dāng)JIT 編譯器對(duì)JavaScript 進(jìn)行編譯后,所生成的二進(jìn)制代碼將包含c3c031,該指令片段的含義是對(duì)eax 寄存器清零后返回.

Fig.11 Code reuse attack by combining JITSpraying and JIT-ROP attack[20]圖11 結(jié)合JITSpraying 與JIT-ROP 的代碼重用攻擊[20]

更進(jìn)一步地,Maisuradze 等人[117]發(fā)現(xiàn):除了JavaScript 中的大常數(shù)以外,還有很多其他方案可以實(shí)現(xiàn)gadgets的注入.舉例來(lái)說(shuō),含有條件判斷語(yǔ)句的JavaScript 代碼被JIT 編譯器編譯后,同樣能夠產(chǎn)生所需要的gadgets.如圖12(a)所示,JavaScript 函數(shù)js_gadget 中的條件語(yǔ)句將被編譯為“test eax,eax;je 0xc380cd”.其中,JE 指令后的數(shù)字表示if 代碼塊內(nèi)的指令長(zhǎng)度,因此,通過(guò)設(shè)計(jì)相應(yīng)的if 代碼塊,攻擊者frame 可以在JIT 代碼中注入任意代碼.Maisuradze 等人[21]隨后還開(kāi)發(fā)了DachShund 框架來(lái)幫助瀏覽器測(cè)試JavaScript 中哪些情況會(huì)導(dǎo)致gadgets的注入.圖12(b)中展示了DachShund 框架發(fā)現(xiàn)的gadgets 注入場(chǎng)景,包括在JavaScript 中調(diào)用console 與Math等API 時(shí),參數(shù)中的大常數(shù)、三元語(yǔ)句以及switch 語(yǔ)句中的大常數(shù)等.

Fig.12 Examples of injecting gadgets through JavaScript圖12 通過(guò)JavaScript 來(lái)注入gadgets 的示例

5.2.2 防御方案

應(yīng)對(duì)代碼重用攻擊的方案有兩種思路,包括對(duì)瀏覽器進(jìn)行額外的安全加固和對(duì)JavaScript 代碼的重寫(xiě).首先,對(duì)瀏覽器進(jìn)行修改意味著可以確保現(xiàn)有的網(wǎng)站可以在不做任何改動(dòng)的情況下運(yùn)行并提高安全.

Athanasakis 等人[20]通過(guò)對(duì)IE 瀏覽器的反匯編發(fā)現(xiàn),IE 中實(shí)現(xiàn)了常數(shù)盲化(constant blinding)機(jī)制來(lái)阻止大常數(shù)的注入.當(dāng)JIT 編譯器發(fā)現(xiàn)JavaScript 中含有大于兩個(gè)字節(jié)的大常數(shù)時(shí),將會(huì)首先生成一個(gè)隨機(jī)數(shù),然后將JIT 代碼用兩條指令替代:第1 條將隨機(jī)數(shù)存儲(chǔ)到指定寄存器中,第2 條對(duì)寄存器作異或操作.異或操作的操作數(shù)為隨機(jī)數(shù)與原來(lái)大常數(shù)的異或值.經(jīng)過(guò)常數(shù)盲化后,JIT 代碼中將不存在大常數(shù)所直接對(duì)應(yīng)的指令,但JIT 代碼的邏輯未發(fā)生變化.特別的,考慮到兩個(gè)字節(jié)的常數(shù)在JIT 代碼中大量存在與性能需求,瀏覽器不能對(duì)兩個(gè)字節(jié)的常數(shù)進(jìn)行常數(shù)盲化.Athanasakis 等人[20]隨后指出,利用 JavaScript 函數(shù)與兩字節(jié)的常數(shù)同樣能注入所需的gadgets.因此,常數(shù)盲化并不能完全抵抗代碼重入攻擊.

地址隨機(jī)化與控制流完整性也能被應(yīng)用到瀏覽器中來(lái)抵抗代碼重入攻擊.Frassetto 等人[116]設(shè)計(jì)了能夠抵抗代碼重入攻擊的JITGuard 框架.JITGuard 將JIT 編譯器放置在SGX 機(jī)制所創(chuàng)建的enclave 中,并且利用地址隨機(jī)化與地址雙向映射將JIT 編譯器編譯生成的JIT 代碼放置在隨機(jī)的區(qū)域內(nèi).JITGuard 確保隨機(jī)區(qū)域的地址只有enclave 內(nèi)的JIT 編譯器才能獲取.即使攻擊者通過(guò)JITSpraying 攻擊注入了gadgets,攻擊者仍無(wú)法定位到gadgets 的地址,因而代碼重用攻擊將無(wú)法成功.Niu 等人[118]將控制流完整性機(jī)制應(yīng)用到JIT 代碼中,其提出的RockJIT 機(jī)制能夠抵抗代碼重用攻擊,但平均產(chǎn)生了14.4%的運(yùn)行時(shí)開(kāi)銷(xiāo).

其次,對(duì)frame 中JavaScript 代碼進(jìn)行驗(yàn)證與重寫(xiě)也能應(yīng)對(duì)代碼重用攻擊,并能保證瀏覽器本身的性能不會(huì)因?yàn)榘踩庸潭艿接绊?Maisuradze 等人[21]在用戶(hù)瀏覽器與Web 服務(wù)器之間實(shí)現(xiàn)了一個(gè)網(wǎng)絡(luò)代理,該代理對(duì)接收到的JavaScript 代碼進(jìn)行重寫(xiě)來(lái)消除大常數(shù).圖13 給出了消除兩種形式的大常數(shù)的示例.攻擊者可通過(guò)對(duì)變量的賦值來(lái)注入大常數(shù),重寫(xiě)后的JavaScript 腳本利用JavaScriptAPI 中的parseInt 函數(shù),使得大常數(shù)0x1234作為字符串存在內(nèi)存中.注意:除了明顯的賦值語(yǔ)句外,類(lèi)似于“1234”&567 的形式也會(huì)引入大常數(shù).JIT 編譯器在解析右圖的JavaScript 代碼時(shí)會(huì)進(jìn)行預(yù)處理,即執(zhí)行“1234”&567 語(yǔ)句并將結(jié)果mov 到存儲(chǔ)變量i的寄存器中.網(wǎng)絡(luò)代理可以利用JavaScriptAPI 中的toString 函數(shù)要求編譯器將變量作為字符串存儲(chǔ).為保證JavaScript 重寫(xiě)的完備性,網(wǎng)絡(luò)代理將首先解析JavaScript 代碼所對(duì)應(yīng)的抽象語(yǔ)法樹(shù),然后遍歷抽象語(yǔ)法樹(shù)來(lái)移除大常數(shù),最后根據(jù)更新后的抽象語(yǔ)法樹(shù)來(lái)生成重寫(xiě)后的JavaScript 代碼.

Fig.13 Examples of removing big constants (e.g.,0x1234) through rewriting JavaScript[21]圖13 通過(guò)JavaScript 重寫(xiě)的大常數(shù)(如0x1234)消除示例[21]

5.3 僅數(shù)據(jù)攻擊及防御

5.3.1 攻擊方案

僅數(shù)據(jù)攻擊同樣能夠被用來(lái)繞過(guò)或欺騙同源策略的安全監(jiān)控器.Jia 等人[22]發(fā)現(xiàn),瀏覽器的同源策略安全監(jiān)控器依賴(lài)瀏覽器渲染進(jìn)程維護(hù)的元數(shù)據(jù)來(lái)進(jìn)行策略實(shí)施.圖14 中給出了Chrome 瀏覽器的同源策略實(shí)施的部分代碼,其中,SecurityOrigin 類(lèi)為每個(gè)frame 維護(hù)了對(duì)應(yīng)的元數(shù)據(jù),包括URL 與源等信息.該代碼中第2 個(gè)if 語(yǔ)句判斷了SecurityOrigin 對(duì)象是否相同,也即是否同源.然而,第1 個(gè)if 語(yǔ)句表明了如果攻擊者能夠通過(guò)僅數(shù)據(jù)攻擊將m_universalAccess 修改為true,Chrome 的同源策略實(shí)施將會(huì)被繞過(guò).Jia 等人利用了Chrome 的一個(gè)已知漏洞來(lái)使得攻擊者frame 里的JavaScript 代碼能夠訪問(wèn)任意內(nèi)存地址的數(shù)據(jù),并且利用Chrome 處理HTML 標(biāo)簽的一些特性來(lái)繞過(guò)了瀏覽器中的地址隨機(jī)化保護(hù),最終使得攻擊者直接定位到m_universalAccess 的內(nèi)存地址,并對(duì)其進(jìn)行修改.攻擊者frame 可以?xún)?nèi)嵌DropBox 或GooglePlay 等云服務(wù)的frame(受害者frame),然后利用該僅數(shù)據(jù)攻擊,攻擊者可以繞過(guò)同源策略來(lái)在受害者frame 中點(diǎn)擊按鈕,如從GooglePlay 中下載惡意應(yīng)用.此后,云服務(wù)將下載的惡意應(yīng)用同步到用戶(hù)本地,打破瀏覽器多進(jìn)程模型維護(hù)的用戶(hù)本地與網(wǎng)頁(yè)的邊界,實(shí)現(xiàn)木馬程序的注入.

Fig.14 Part of source code of same-origin policy enforcement in Chrome [22]圖14 Chrome 中同源策略實(shí)施的部分源代碼[22]

Rogowski 等人[23]在Jia 的工作基礎(chǔ)上,更進(jìn)一步地提出了內(nèi)存制圖(memory cartography)技術(shù)來(lái)簡(jiǎn)化僅數(shù)據(jù)攻擊的構(gòu)造過(guò)程.內(nèi)存制圖技術(shù)包含4 個(gè)步驟:首先,攻擊者在線下訪問(wèn)目標(biāo)應(yīng)用并執(zhí)行受害者用戶(hù)可能會(huì)執(zhí)行的操作,與此同時(shí),攻擊者暫停瀏覽器運(yùn)行并對(duì)渲染進(jìn)程進(jìn)行內(nèi)存掃描來(lái)獲取足夠多的數(shù)據(jù)指針;此后,攻擊者利用掃描到的數(shù)據(jù)指針制定內(nèi)存地圖,這其中需要考慮到地址的隨機(jī)化問(wèn)題;接下來(lái),攻擊者需要找到瀏覽器的內(nèi)存泄漏漏洞,使得其可以對(duì)任意內(nèi)存進(jìn)行讀寫(xiě);最后,攻擊者frame 在運(yùn)行時(shí)利用內(nèi)存地圖與內(nèi)存泄漏漏洞來(lái)查找目標(biāo)數(shù)據(jù)的地址,并對(duì)目標(biāo)數(shù)據(jù)進(jìn)行修改.實(shí)驗(yàn)結(jié)果表明,該內(nèi)存制圖技術(shù)能夠直接用來(lái)重現(xiàn)Jia 等人的工作,并在IE 瀏覽器上也實(shí)現(xiàn)了內(nèi)存利用來(lái)泄漏受害者frame 的cookie.

Frassetto 等人[116]實(shí)現(xiàn)了對(duì)JIT 編譯器的僅數(shù)據(jù)攻擊DOJITA.JIT 編譯器在編譯JavaScript 代碼時(shí),會(huì)首先生成中間語(yǔ)言,然后根據(jù)中間語(yǔ)言來(lái)生成最后的二進(jìn)制代碼.如果攻擊者能夠在中間語(yǔ)言中加入一些偽造的數(shù)據(jù),這些數(shù)據(jù)將會(huì)被編譯為二進(jìn)制代碼執(zhí)行.Frassetto 等人利用瀏覽器的堆溢出漏洞實(shí)現(xiàn)了該僅數(shù)據(jù)攻擊,使得攻擊者frame 獲取到在渲染進(jìn)程中執(zhí)行任意代碼的能力,同源策略也將很容易被攻擊者繞過(guò).

5.3.2 防御方案

僅數(shù)據(jù)攻擊發(fā)生的根本原因是瀏覽器對(duì)一些安全相關(guān)敏感數(shù)據(jù)的不完全保護(hù),使得攻擊者可以利用內(nèi)存漏洞來(lái)對(duì)敏感數(shù)據(jù)進(jìn)行任意讀寫(xiě).因此,解決僅數(shù)據(jù)攻擊必然需要對(duì)瀏覽器進(jìn)行安全加固以保護(hù)安全敏感數(shù)據(jù).

Jia 等人[22]認(rèn)為,地址隨機(jī)化能夠用來(lái)保護(hù)這些安全相關(guān)的數(shù)據(jù).瀏覽器可以將所有安全相關(guān)數(shù)據(jù)放置在一個(gè)單獨(dú)的內(nèi)存段中,并對(duì)內(nèi)存段的基址進(jìn)行隨機(jī)化處理.更進(jìn)一步的,瀏覽器要保證沒(méi)有指針從內(nèi)存段外指向內(nèi)存段里,否則,內(nèi)存攻擊者將可以跟蹤指針來(lái)找到隨機(jī)化后的內(nèi)存段.此外,瀏覽器還要保證攻擊者無(wú)法通過(guò)其他內(nèi)存數(shù)據(jù)來(lái)引用該內(nèi)存段的基址,如將內(nèi)存地址放在特殊的寄存器中來(lái)避免基址的泄漏.在具體實(shí)現(xiàn)過(guò)程中,為避免對(duì)瀏覽器的大范圍修改,Jia 等人使用瀏覽器的可信內(nèi)核進(jìn)程來(lái)維護(hù)該內(nèi)存段的基址.

Reis 等人[33]對(duì)瀏覽器的多進(jìn)程架構(gòu)進(jìn)行加固,來(lái)保護(hù)這些安全相關(guān)的數(shù)據(jù).傳統(tǒng)的瀏覽器多進(jìn)程架構(gòu)會(huì)使得位于同一瀏覽實(shí)例的frame 放在同一渲染進(jìn)程中[24,25](見(jiàn)第2.1 節(jié)),所以當(dāng)一個(gè)frame 內(nèi)嵌跨源子frame 時(shí),父子frame 將在同一個(gè)進(jìn)程中運(yùn)行,同源策略的安全監(jiān)控器也不得不放置在渲染進(jìn)行中進(jìn)行策略實(shí)施.Reis 等人提出了SiteIsolation 架構(gòu),該架構(gòu)徹底地將不同網(wǎng)站的frame 運(yùn)行在不同的渲染進(jìn)程里.在這種情況下,即使攻擊者frame 對(duì)其所在的渲染進(jìn)程發(fā)起了內(nèi)存攻擊并控制了該渲染進(jìn)程,由于進(jìn)程邊界的存在,攻擊者frame 依舊不能訪問(wèn)受害者frame 所在的渲染進(jìn)程的數(shù)據(jù),從而實(shí)現(xiàn)更強(qiáng)的安全隔離.

對(duì)安全敏感數(shù)據(jù)的保護(hù),還可以使用SGX 等CPU 級(jí)別的隔離機(jī)制.例如,Frassetto 等人[116]將JS 引擎放置在利用SGX 創(chuàng)建的enclave 中,由于enclave 外的代碼無(wú)法對(duì)enclave 里的內(nèi)存進(jìn)行訪問(wèn),攻擊者frame 將無(wú)法修改JavaScript 引擎中的敏感數(shù)據(jù),之前的DOJITA 僅數(shù)據(jù)攻擊將無(wú)法實(shí)現(xiàn).TrustJS[119]與Fidelius[120]也利用硬件機(jī)制實(shí)現(xiàn)了類(lèi)似的安全加固.

5.4 方案對(duì)比與討論

表8 總結(jié)了瀏覽器3 種內(nèi)存攻擊的代表性工作、攻擊原理、對(duì)同源策略的影響以及相關(guān)防御機(jī)制.

Table 8 Summary on memory attacks on browser表8 瀏覽器內(nèi)存攻擊總結(jié)

我們從以下兩個(gè)角度來(lái)分析討論這3 類(lèi)內(nèi)存攻擊.

?攻擊原理:對(duì)瀏覽器發(fā)起這3 類(lèi)內(nèi)存攻擊的共同點(diǎn)是利用來(lái)自于JavaScript 引擎的漏洞,攻擊者可利用這些漏洞來(lái)影響可執(zhí)行代碼(如通過(guò)大常數(shù)等),獲得內(nèi)存讀取能力(如搜索所有代碼頁(yè)中的gadgets)以及獲得內(nèi)存寫(xiě)能力(如修改元數(shù)據(jù)).根據(jù)Jia 等人[22]對(duì)安全漏洞的分析,Chrome 于2014 年～2016 年間存在599 個(gè)安全漏洞,其中104 個(gè)漏洞允許攻擊者獲得內(nèi)存讀寫(xiě)能力,每個(gè)Chrome 的版本平均存在6個(gè)內(nèi)存漏洞.這意味著瀏覽器內(nèi)存攻擊與瀏覽器安全增強(qiáng)將是長(zhǎng)期存在的研究?jī)?nèi)容.

?對(duì)同源策略的影響:對(duì)瀏覽器的3 類(lèi)內(nèi)存攻擊均對(duì)同源策略產(chǎn)生了破壞性的影響.其中,代碼注入攻擊與代碼重用攻擊的最終目的都是在渲染進(jìn)程內(nèi)執(zhí)行任意代碼,這將能夠直接繞過(guò)同源策略的限制來(lái)訪問(wèn)跨源資源;僅數(shù)據(jù)攻擊可以作用在與同源策略有關(guān)的元數(shù)據(jù)或者其他數(shù)據(jù)上,前者將導(dǎo)致攻擊者可以欺騙同源策略的安全監(jiān)控器,而后者意味著攻擊者可能繞過(guò)同源策略以訪問(wèn)跨源資源.

表9 對(duì)抵抗以上3 類(lèi)攻擊的防御方案進(jìn)行了總結(jié)分析,包括防御機(jī)制類(lèi)型、能抵抗的攻擊類(lèi)型、對(duì)瀏覽器引入的性能開(kāi)銷(xiāo)以及對(duì)瀏覽器代碼的修改數(shù)量.我們從防御機(jī)制類(lèi)型的角度來(lái)對(duì)這些方案進(jìn)行總結(jié)討論.

?W^X 與控制流完整性通常被認(rèn)為是分別解決代碼注入與重入攻擊的有效方式.目前,主流瀏覽器中已經(jīng)實(shí)現(xiàn)了W^X 保護(hù)[114].然而,控制流完整性為瀏覽器帶來(lái)了不可忽略的開(kāi)銷(xiāo).例如,Niu 等人[118]的方案引入了14.6%的開(kāi)銷(xiāo),這使得其在瀏覽器中應(yīng)用還有一些距離.

?地址空間隨機(jī)化幾乎能用來(lái)抵抗所有類(lèi)型的內(nèi)存攻擊,但必須要求隨機(jī)化后內(nèi)存段的基址很難被攻擊者找到,因此需要謹(jǐn)慎處理指針以及維護(hù)內(nèi)存段的機(jī)制.

?利用特殊JIT 編譯器特性的攻擊可以被相應(yīng)的防御機(jī)制所抵抗,如針對(duì)于大常數(shù)的常數(shù)盲化機(jī)制與JavaScript 代碼重寫(xiě)機(jī)制.然而,常數(shù)盲化機(jī)制引入了15%～80%的性能開(kāi)銷(xiāo)性能的需求,這使得其不能應(yīng)用于1 到2 字節(jié)的常數(shù)上,而使用1 到2 字節(jié)常數(shù)進(jìn)行內(nèi)存攻擊是可行的[20];JavaScript 重寫(xiě)機(jī)制對(duì)Chrome 與Edge 瀏覽器分別引入了21%與24%的開(kāi)銷(xiāo),且需要網(wǎng)絡(luò)代理的輔助[21],這對(duì)于要求性能與易用性的瀏覽器來(lái)說(shuō)是很難接受的.

?內(nèi)存隔離機(jī)制能從根本上解決內(nèi)存攻擊問(wèn)題,但通常意味著對(duì)瀏覽器現(xiàn)有架構(gòu)的修改,如Site Isoltion架構(gòu)[33]對(duì)Chrome 修改或增加了450k 行數(shù)的源代碼,這在實(shí)現(xiàn)以及推廣上均存在較大的問(wèn)題.此外,對(duì)瀏覽器的架構(gòu)修改也可能引入額外的開(kāi)銷(xiāo),如何確保性能,也是需要考慮的問(wèn)題.

Table 9 Comparison on memory defenses schemes in browsers表9 瀏覽器內(nèi)存防御方案對(duì)比

5.5 小 結(jié)

Web 的發(fā)展與瀏覽器對(duì)即時(shí)編譯的需求,使得內(nèi)存攻擊者們逐漸將瀏覽器作為攻擊目標(biāo).代碼注入攻擊、重用攻擊與僅數(shù)據(jù)攻擊的發(fā)起,將會(huì)直接破壞瀏覽器所實(shí)施的同源策略,導(dǎo)致攻擊者幾乎可以無(wú)限制地訪問(wèn)受害者frame 的資源.JavaScript 代碼重寫(xiě)是解決內(nèi)存攻擊的一種方案,但性能與對(duì)目前網(wǎng)站的兼容性限制了其實(shí)用性.基于瀏覽器加固的方案將是應(yīng)對(duì)內(nèi)存攻擊的主流,如瀏覽器從單進(jìn)程演變到多進(jìn)程模型乃至目前的SiteIosltion 即是典型的體現(xiàn).不論如何,內(nèi)存攻防對(duì)抗將使得瀏覽器同源策略安全在曲折中增強(qiáng).

6 未來(lái)研究展望

同源策略的重要性使得其被視為瀏覽器安全的基石,然而Web 應(yīng)用需求的多樣性與瀏覽器本身的脆弱性,使得策略攻擊者與內(nèi)存攻擊者能夠繞過(guò)或欺騙同源策略以獲取跨源資源.如何解決現(xiàn)有安全威脅、應(yīng)對(duì)未知威脅,并且兼顧易用性、靈活性、向后兼容性等多方面的因素,需要更進(jìn)一步的研究,具體表現(xiàn)為:

?易用性:應(yīng)對(duì)策略攻擊者的防御方案通常要求Web 應(yīng)用開(kāi)發(fā)者提供細(xì)粒度或者靈活的策略,例如應(yīng)對(duì)第三方腳本的防御方案[30,44,51,55].然而,Web 的多樣性與復(fù)雜性,使得研究者們不能簡(jiǎn)單地假設(shè)開(kāi)發(fā)者都具備很強(qiáng)的安全意識(shí),不能要求開(kāi)發(fā)者來(lái)制定復(fù)雜的策略甚至需要考慮策略之間的一致與沖突.同源策略安全增強(qiáng)機(jī)制的易用性,將促進(jìn)其應(yīng)用于實(shí)際.

?靈活性:Web 環(huán)境是不斷演化與進(jìn)步的,新的需求與場(chǎng)景層出不窮.諸如用于保存歷史的Archive 網(wǎng)站、廣告分析、用戶(hù)追蹤與內(nèi)容安全策略等新型策略的出現(xiàn),使同源策略在實(shí)際應(yīng)用上捉襟見(jiàn)肘[10,14,31,93],未來(lái)的同源策略應(yīng)當(dāng)要更加靈活,以支持這些新型需求與場(chǎng)景.

?向后兼容性:同源策略作為瀏覽器所必須實(shí)現(xiàn)的基本安全策略,對(duì)其安全增強(qiáng)必須要考慮到向后兼容性.安全增強(qiáng)方案需要能夠支持現(xiàn)有的同源策略,不能由于安全增強(qiáng)導(dǎo)致大部分網(wǎng)站不能渲染與運(yùn)行或者必須作出對(duì)應(yīng)修改.

因此,我們認(rèn)為未來(lái)的研究工作應(yīng)該重點(diǎn)關(guān)注以下幾個(gè)方面.

(1) 對(duì)有潛在風(fēng)險(xiǎn)代碼的權(quán)限限制

網(wǎng)頁(yè)中潛在風(fēng)險(xiǎn)代碼包括了第三方腳本與處理跨源數(shù)據(jù)的處理函數(shù)等,前者由同源策略規(guī)則不足所引起,并使得第三方腳本能任意操作網(wǎng)頁(yè)資源(見(jiàn)第3.1.2 節(jié));后者由跨源通信機(jī)制所引起,并使得接收方存在數(shù)據(jù)注入攻擊的威脅(見(jiàn)第4.1.2 節(jié)).現(xiàn)有研究工作的思路在于隔離第三方腳本[30,44,51,54]與推斷跨源數(shù)據(jù)接收方的安全行為模型[92].這些防御機(jī)制要么為Web 應(yīng)用開(kāi)發(fā)者網(wǎng)頁(yè)編寫(xiě)造成不便,要么對(duì)攻擊行為的檢測(cè)存在誤報(bào)的風(fēng)險(xiǎn).我們認(rèn)為,未來(lái)的研究工作可對(duì)這兩種情況進(jìn)行統(tǒng)一,可以借助于iframesandbox 機(jī)制[121]的思路來(lái)對(duì)JavaScript代碼的權(quán)限進(jìn)行劃分,進(jìn)而提出統(tǒng)一的訪問(wèn)控制框架來(lái)對(duì)有潛在風(fēng)險(xiǎn)代碼進(jìn)行權(quán)限限制.例如,Web 開(kāi)發(fā)者可以剝奪不可信第三方腳本的DOM 元素訪問(wèn)權(quán)限、剝奪處理跨源數(shù)據(jù)處理函數(shù)的網(wǎng)絡(luò)訪問(wèn)權(quán)限等.使用這種基于權(quán)限的控制一方面能覆蓋潛在風(fēng)險(xiǎn)代碼運(yùn)行的整個(gè)生命周期,另一方面更便于Web 開(kāi)發(fā)者理解與使用.

(2) 同源策略與其他策略協(xié)作

同源策略是瀏覽器安全的基本策略,但并不是唯一策略.新型場(chǎng)景與需求的出現(xiàn),使得瀏覽器中出現(xiàn)了內(nèi)容安全策略[10]等新型策略,這要求同源策略與這些新型策略之間要保持一致性,確保一種策略不能由于其他策略的存在而被繞過(guò)或者欺騙(見(jiàn)第3.2.1 節(jié)與第3.3.1 節(jié)).我們認(rèn)為:未來(lái)的研究工作需要設(shè)計(jì)策略協(xié)作安全驗(yàn)證機(jī)制來(lái)輔助新型策略設(shè)計(jì)者構(gòu)造策略,需要提出新的框架與系統(tǒng)以幫助Web 應(yīng)用開(kāi)發(fā)者來(lái)為其網(wǎng)頁(yè)配置這些策略并檢查驗(yàn)證策略的合理性與一致性,更進(jìn)一步地,未來(lái)的研究工作可能需要在瀏覽器中提供統(tǒng)一的框架來(lái)定義與實(shí)施這些策略.

(3) 數(shù)據(jù)可控的跨源資源共享

現(xiàn)有的跨源資源共享機(jī)制研究通常考慮共享過(guò)程中資源被竊取或者對(duì)接收方的影響等問(wèn)題,而忽略共享后資源的使用權(quán)限問(wèn)題.不論是服務(wù)器輔助還是無(wú)服務(wù)器輔助的機(jī)制,數(shù)據(jù)所有者在共享后將直接對(duì)數(shù)據(jù)失去控制權(quán),數(shù)據(jù)接收方可以任意地使用、修改與傳播共享的資源.例如,一個(gè)Web 應(yīng)用可能請(qǐng)求用戶(hù)獲取其他社交網(wǎng)站的聯(lián)系人信息以進(jìn)行用戶(hù)推薦,而當(dāng)社交網(wǎng)站將信息傳輸給該Web 應(yīng)用后,后者將可以任意地使用這些敏感信息[60].我們認(rèn)為:未來(lái)的跨源資源共享應(yīng)當(dāng)關(guān)注共享數(shù)據(jù)的可控性,如對(duì)于隱私數(shù)據(jù)可以要求數(shù)據(jù)在短暫使用后必須刪除、對(duì)于共享數(shù)據(jù)的進(jìn)一步傳輸需要經(jīng)由數(shù)據(jù)所有者的同意.數(shù)據(jù)可控的跨源資源共享將極大地促進(jìn)Web 資源可靠交互.

(4) 硬件或操作系統(tǒng)支持的同源策略不同主體間的隔離機(jī)制

同源策略的本質(zhì)上是為Web 資源設(shè)定邊界(同源),并限制跨邊界的資源訪問(wèn).然而,現(xiàn)有同源策略的實(shí)施依賴(lài)于瀏覽器來(lái)實(shí)現(xiàn)主體之間的隔離.瀏覽器作為大型軟件,不可避免地面臨著內(nèi)存攻擊.我們認(rèn)為:未來(lái)的研究工作應(yīng)當(dāng)會(huì)更傾向于使用基于操作系統(tǒng)甚至是基于硬件的隔離機(jī)制,以縮減可信計(jì)算基來(lái)實(shí)現(xiàn)更強(qiáng)的安全隔離.然而,可信計(jì)算基的縮減意味著策略實(shí)施將面臨著一些語(yǔ)義的丟失,例如,SiteIsolation 項(xiàng)目[33]利用進(jìn)程來(lái)進(jìn)行主體間的隔離,但是需要其他機(jī)制來(lái)判斷Web 資源類(lèi)型來(lái)決定是否進(jìn)行隔離.此外,這種瀏覽器架構(gòu)上的變化還需要考慮性能以及向后兼容性等因素.

7 結(jié)束語(yǔ)

本文對(duì)瀏覽器同源策略安全的研究進(jìn)展進(jìn)行了深入分析和總結(jié).首先介紹了同源策略的規(guī)則和跨域/跨源通信機(jī)制,分析了同源策略安全研究的威脅模型和研究方向;接著,分別總結(jié)分析了同源策略規(guī)則不足與應(yīng)對(duì)方案、跨域與跨源通信機(jī)制安全威脅及應(yīng)對(duì)方案以及內(nèi)存攻擊下的同源策略安全;最后,展望了同源策略安全的未來(lái)研究方向.期望我們的工作能夠?yàn)橐院蟮难芯空呓o予有益的參考,為同源策略安全研究作出貢獻(xiàn).

致謝我們向同源策略安全研究的先行者以及對(duì)本文工作提出寶貴建議的評(píng)審老師表示衷心的感謝.