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

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

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

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

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

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

瀏覽器的同源策略(same-origin policy,簡稱 SOP)被提出來定義瀏覽器加載的互聯(lián)網(wǎng)資源的安全邊界.Netscape 的工程師們在1995 年發(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]也對同源策略進(jìn)行了描述與定義.同源策略逐漸成為瀏覽器的基礎(chǔ)訪問控制策略,諸如Chrome,Firefox,Safari 與Edge 等主流瀏覽器都實(shí)現(xiàn)了同源策略[4,5].

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

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

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

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

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

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

1 同源策略概述

1.1 術(shù)語定義

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

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

1.2 同源策略規(guī)則

同源策略是瀏覽器安全的基礎(chǔ)安全策略[5].瀏覽器為每個(gè)加載的frame 設(shè)置一個(gè)稱為“源”的屬性.區(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.

同源策略的檢測要求是“同源”,即主體與客體所在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 等frame 分別在協(xié)議、域名與端口上不一致,故而不能訪問這些frame 的資源.

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

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

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

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

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

2 同源策略安全研究方向

2.1 威脅模型

2.1.1 研究場景

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

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

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

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

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

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

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

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

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

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

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

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

2.1.2 敵手模型

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

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

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

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

2.2 研究方向

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.1.1 用途與分類

為了豐富功能與增強(qiáng)交互性,Web 應(yīng)用廣泛集成第三方腳本到其自身的網(wǎng)頁中.Yue 等人[34]發(fā)現(xiàn):96.9%的網(wǎng)站包含來自其他源的腳本,平均每個(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)、動態(tài)廣告(如GoogleAdSense)、社交網(wǎng)絡(luò)(如Facebook 和Twitter)與用戶追蹤(如Quantserve)等服務(wù).有些第三方腳本還提供了編程庫(如jQuery)與密碼算法庫(如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 具有更大的攻擊面.我們首先來總結(jié)分析由引入第三方腳本所帶來的對宿主frame 的新的攻擊向量,包括以下3 種.

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

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

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

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

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

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

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

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

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

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

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

3.1.3 防御方案

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

(1) 第1 類是基于語言的防御機(jī)制.

即利用JavaScript 語言的特性來實(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ò)代理來將在網(wǎng)頁中包含一個(gè)Jate庫并對第三方腳本進(jìn)行重寫.Jate庫利用JavaScript的“with(scope){?}”語句使得第三方腳本的所有變量不能超過scope 變量的作用域,因而第三方腳本無法直接訪問宿主frame 的其他變量.為支持第三方腳本對宿主frame 的正常操作,Jate 利用JavaScript 的對象代理(proxy)機(jī)制為宿主frame 中的相關(guān)變量創(chuàng)建代理對象,并在第三方腳本重寫時(shí),允許對這些代理對象的訪問.同時(shí),由于對象代理機(jī)制允許設(shè)置回調(diào)函數(shù),宿主frame 可以實(shí)施對應(yīng)的策略:當(dāng)一個(gè)代理對象被調(diào)用時(shí),該對象上的策略回調(diào)函數(shù)將會被調(diào)用,用來判斷第三方腳本是否被授權(quán)來訪問宿主frame 的對象,如圖3(a)中允許對window 對象的引用,但拒絕對data 對象的引用.其實(shí)驗(yàn)表明,Jate 機(jī)制引入了接近20%的開銷.

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

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

即利用瀏覽器提供的WebWorker 來實(shí)現(xiàn)宿主frame 與第三方腳本的隔離.由于JavaScript 的單線程性質(zhì),frame 中比較耗時(shí)的操作將會很大程度上影響到網(wǎng)頁瀏覽體驗(yàn).WebWorker 機(jī)制使得JavaScript 可以請求瀏覽器創(chuàng)建新的線程來運(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 來允許第三方腳本對特定DOM 的合法訪問.第三方腳本與宿主frame 之間的交互需要通過消息通信機(jī)制來實(shí)現(xiàn).

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

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

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

即通過對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ī)制來實(shí)現(xiàn).Meyerovich 等人與Acker 等人先后提出了ConScript[55]與WebJail[56]來限制第三方資源.具體來說,通過在JavaScript 引擎中增加API 來對原來JavaScript 函數(shù)引入新的建議函數(shù)(advice function).當(dāng)建議函數(shù)存在時(shí),JavaScript 引擎將會調(diào)用建議函數(shù),否則調(diào)用原函數(shù).宿主frame 因此可以利用建議函數(shù)來限制第三方腳本.

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

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

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

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

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

3.2.1 安全威脅

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

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

Moshchuk 等人[58]指出,同源策略無法實(shí)現(xiàn)在URL 路徑上的隔離.考慮分別來自于https://www.facebook.com/user1 與https://www.facebook.com/user2 的兩個(gè)同源frame,它們代表著不同用戶的主頁,但卻無法實(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)用開發(fā)者可以利用HTMLiframe 中的sandbox 關(guān)鍵字來限制后一個(gè)frame 的權(quán)限,如不允許彈窗或不允許提交表單等.然而,若該被攻擊的frame 具備執(zhí)行JavaScript 代碼的權(quán)限,其可以訪問良好的frame 來實(shí)現(xiàn)彈窗或者提交表單的功能.Singh 等人[13]分析cookie 的訪問控制包含URL 路徑,而同源策略忽略URL 路徑的策略實(shí)施機(jī)制將會破壞cookie 的訪問控制.Lerner 等人[31]發(fā)現(xiàn),同源策略對同源不同frame 的過度授權(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)為是來自于同一個(gè)源(https://web.archive.org/).如此,攻擊者網(wǎng)頁可以事先編寫用來修改受害者網(wǎng)站內(nèi)容的代碼,在網(wǎng)頁被存檔后,該代碼將修改受害者網(wǎng)頁內(nèi)容,從而影響諸如利用存檔網(wǎng)站來進(jìn)行法律取證的行為的正確性.

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

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

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

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

3.2.2 防御方案

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

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

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

(2) 第2 類是動態(tài)的同源策略.

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

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

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

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

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

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

3.3.1 安全威脅

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

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

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

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

Fig.4 One form of XSSI attack through including remote JSON file[75]圖4 一種通過包含遠(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ù)器會根據(jù)登錄的用戶往腳本中填入不同的信息(稱之為動態(tài)腳本).通過對150 個(gè)網(wǎng)站的實(shí)驗(yàn)分析,Lekies 等人發(fā)現(xiàn):49 個(gè)網(wǎng)站使用了動態(tài)腳本,其中攜帶的動態(tài)信息包含了用戶的數(shù)據(jù)(如用戶名與郵箱地址)以及網(wǎng)頁與Web應(yīng)用通信的安全令牌等.與JSON 劫持攻擊類似,為獲取這些信息,攻擊者可以利用HTML 的script 標(biāo)簽將受害者網(wǎng)站的動態(tài)腳本引入到自身的frame 中(圖4 中攻擊行為的步驟2).該動態(tài)腳本將在攻擊者frame 中執(zhí)行.根據(jù)用戶敏感信息在動態(tài)腳本中的不同定義方式(如全局變量、數(shù)組等),攻擊者frame 可以通過事先重載相應(yīng)的JavaScript 函數(shù)(圖4 中攻擊行為的步驟1)、或者事后訪問全局變量來獲取這些敏感信息.利用這些敏感信息,攻擊者可以實(shí)現(xiàn)用戶追蹤或個(gè)性化的社會工程.更進(jìn)一步地,Staicu 等人[79]發(fā)現(xiàn):同源策略規(guī)則中,允許嵌入的跨源圖片也能被用來造成類似的隱私泄漏.

為了更直觀地描述CSRF 與XSSI 攻擊,我們總結(jié)了兩種攻擊所利用的同源策略規(guī)則、后果以及相關(guā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 攻擊的建立來自于兩個(gè)不同的角度.

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

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

3.3.2 防御方案

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

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

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

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

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

3.4 方案對比與討論

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

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

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

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

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

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

3.5 小 結(jié)

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

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

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

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

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

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

4.1.1 document.domain 跨域通信

(1) 機(jī)制概述

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

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

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

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

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

2)注入到1.html 中的惡意腳本發(fā)起攻擊.如圖6(a)所示,惡意腳本可以訪問與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ò)請求,并成功獲取服務(wù)器返回的網(wǎng)絡(luò)響應(yīng).

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

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

4.1.2 postMessage 跨源通信

(1) 機(jī)制概述

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

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

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

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

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

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

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

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

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

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

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

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

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

4.2.1 JSON-P 跨源通信

(1) 機(jī)制概述

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

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

(2) 安全威脅

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

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

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

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

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

最后,攻擊者網(wǎng)頁可以通過網(wǎng)絡(luò)通信來將獲取的惡意數(shù)據(jù)返回給攻擊者服務(wù)器.此外,Grossman[75]發(fā)現(xiàn),可以攻擊使用JSON-P 機(jī)制的Google 郵件網(wǎng)站.當(dāng)用戶事先登錄了Google 郵件網(wǎng)站后,瀏覽器中維護(hù)了用戶對應(yīng)的cookie.當(dāng)用戶cookie 沒有過期的情況下,用戶被誘導(dǎo)訪問了攻擊者網(wǎng)頁,該攻擊者網(wǎng)頁嵌入了Google 郵件網(wǎng)站的腳本(如http://mail.google.com/mail/?_url_scrubbed_來獲取聯(lián)系人列表).由于瀏覽器在發(fā)送網(wǎng)絡(luò)請求時(shí)會自動攜帶對應(yīng)的cookie,Google 郵件服務(wù)器將會返回受害者用戶的聯(lián)系人列表.聯(lián)系人列表在JavaScript 中將會轉(zhuǎn)為數(shù)組Array,攻擊者網(wǎng)頁可以通過事先重載Array 對象來讀取聯(lián)系人列表.這種攻擊是XSSI 攻擊(見第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ī)范,來允許一個(gè)frame 獲取跨源服務(wù)器的網(wǎng)絡(luò)響應(yīng).CORS中定義了兩類請求:簡單請求與非簡單請求.前者要求請求方法為HEAD,GET 或POST,且HTTP 頭信息為預(yù)先定義的幾種字段(如Accept,Content-Language 等);后者采用諸如PUT,DELETE 之類的請求方法,或使用一些其他的HTTP 頭字段.非簡單請求被認(rèn)為是可能存在安全風(fēng)險(xiǎn)的網(wǎng)絡(luò)請求.

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

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

(2) 安全威脅

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

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

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

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

4.3 方案對比與討論

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

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

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

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

4.4 小 結(jié)

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

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

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

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

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

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

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

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

5.1 代碼注入攻擊及防御

5.1.1 攻擊方案

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

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

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

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

5.1.2 防御方案

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

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

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

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

5.2 代碼重用攻擊及防御

5.2.1 攻擊方案

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

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

JIT-ROP 攻擊的工作方式是尋找已存在代碼頁中的gadagets,這并不能保證攻擊者所需要的gadgets 一定能夠被找到.考慮到JITSpraying 攻擊能夠?qū)崿F(xiàn)代碼注入,Athanasakis 等人[20]設(shè)計(jì)了結(jié)合JITSpraying 攻擊與JITROP 攻擊的代碼重用攻擊.該攻擊利用JITSpraying 攻擊中所使用的大常數(shù)來往瀏覽器中注入gadgets,然后與JIT-ROP 一樣,利用控制流劫持漏洞來將注入的gadgets 鏈接到一起,從而發(fā)起代碼重用攻擊.圖11 中展示了生成執(zhí)行mprotect 系統(tǒng)調(diào)用并提供相關(guān)參數(shù)所需的gadgets 與對應(yīng)的JavaScript 代碼.例如,在JavaScript 中為變量g3 賦值為12828721,當(dāng)JIT 編譯器對JavaScript 進(jìn)行編譯后,所生成的二進(jìn)制代碼將包含c3c031,該指令片段的含義是對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的注入.舉例來說,含有條件判斷語句的JavaScript 代碼被JIT 編譯器編譯后,同樣能夠產(chǎn)生所需要的gadgets.如圖12(a)所示,JavaScript 函數(shù)js_gadget 中的條件語句將被編譯為“test eax,eax;je 0xc380cd”.其中,JE 指令后的數(shù)字表示if 代碼塊內(nèi)的指令長度,因此,通過設(shè)計(jì)相應(yīng)的if 代碼塊,攻擊者frame 可以在JIT 代碼中注入任意代碼.Maisuradze 等人[21]隨后還開發(fā)了DachShund 框架來幫助瀏覽器測試JavaScript 中哪些情況會導(dǎo)致gadgets的注入.圖12(b)中展示了DachShund 框架發(fā)現(xiàn)的gadgets 注入場景,包括在JavaScript 中調(diào)用console 與Math等API 時(shí),參數(shù)中的大常數(shù)、三元語句以及switch 語句中的大常數(shù)等.

Fig.12 Examples of injecting gadgets through JavaScript圖12 通過JavaScript 來注入gadgets 的示例

5.2.2 防御方案

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

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

地址隨機(jī)化與控制流完整性也能被應(yīng)用到瀏覽器中來抵抗代碼重入攻擊.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 編譯器才能獲取.即使攻擊者通過JITSpraying 攻擊注入了gadgets,攻擊者仍無法定位到gadgets 的地址,因而代碼重用攻擊將無法成功.Niu 等人[118]將控制流完整性機(jī)制應(yīng)用到JIT 代碼中,其提出的RockJIT 機(jī)制能夠抵抗代碼重用攻擊,但平均產(chǎn)生了14.4%的運(yùn)行時(shí)開銷.

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

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

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

5.3.1 攻擊方案

僅數(shù)據(jù)攻擊同樣能夠被用來繞過或欺騙同源策略的安全監(jiān)控器.Jia 等人[22]發(fā)現(xiàn),瀏覽器的同源策略安全監(jiān)控器依賴瀏覽器渲染進(jìn)程維護(hù)的元數(shù)據(jù)來進(jìn)行策略實(shí)施.圖14 中給出了Chrome 瀏覽器的同源策略實(shí)施的部分代碼,其中,SecurityOrigin 類為每個(gè)frame 維護(hù)了對應(yīng)的元數(shù)據(jù),包括URL 與源等信息.該代碼中第2 個(gè)if 語句判斷了SecurityOrigin 對象是否相同,也即是否同源.然而,第1 個(gè)if 語句表明了如果攻擊者能夠通過僅數(shù)據(jù)攻擊將m_universalAccess 修改為true,Chrome 的同源策略實(shí)施將會被繞過.Jia 等人利用了Chrome 的一個(gè)已知漏洞來使得攻擊者frame 里的JavaScript 代碼能夠訪問任意內(nèi)存地址的數(shù)據(jù),并且利用Chrome 處理HTML 標(biāo)簽的一些特性來繞過了瀏覽器中的地址隨機(jī)化保護(hù),最終使得攻擊者直接定位到m_universalAccess 的內(nèi)存地址,并對其進(jìn)行修改.攻擊者frame 可以內(nèi)嵌DropBox 或GooglePlay 等云服務(wù)的frame(受害者frame),然后利用該僅數(shù)據(jù)攻擊,攻擊者可以繞過同源策略來在受害者frame 中點(diǎn)擊按鈕,如從GooglePlay 中下載惡意應(yīng)用.此后,云服務(wù)將下載的惡意應(yīng)用同步到用戶本地,打破瀏覽器多進(jìn)程模型維護(hù)的用戶本地與網(wǎng)頁的邊界,實(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ù)來簡化僅數(shù)據(jù)攻擊的構(gòu)造過程.內(nèi)存制圖技術(shù)包含4 個(gè)步驟:首先,攻擊者在線下訪問目標(biāo)應(yīng)用并執(zhí)行受害者用戶可能會執(zhí)行的操作,與此同時(shí),攻擊者暫停瀏覽器運(yùn)行并對渲染進(jìn)程進(jìn)行內(nèi)存掃描來獲取足夠多的數(shù)據(jù)指針;此后,攻擊者利用掃描到的數(shù)據(jù)指針制定內(nèi)存地圖,這其中需要考慮到地址的隨機(jī)化問題;接下來,攻擊者需要找到瀏覽器的內(nèi)存泄漏漏洞,使得其可以對任意內(nèi)存進(jìn)行讀寫;最后,攻擊者frame 在運(yùn)行時(shí)利用內(nèi)存地圖與內(nèi)存泄漏漏洞來查找目標(biāo)數(shù)據(jù)的地址,并對目標(biāo)數(shù)據(jù)進(jìn)行修改.實(shí)驗(yàn)結(jié)果表明,該內(nèi)存制圖技術(shù)能夠直接用來重現(xiàn)Jia 等人的工作,并在IE 瀏覽器上也實(shí)現(xiàn)了內(nèi)存利用來泄漏受害者frame 的cookie.

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

5.3.2 防御方案

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

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

Reis 等人[33]對瀏覽器的多進(jìn)程架構(gòu)進(jìn)行加固,來保護(hù)這些安全相關(guān)的數(shù)據(jù).傳統(tǒng)的瀏覽器多進(jìn)程架構(gòu)會使得位于同一瀏覽實(shí)例的frame 放在同一渲染進(jìn)程中[24,25](見第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 對其所在的渲染進(jìn)程發(fā)起了內(nèi)存攻擊并控制了該渲染進(jìn)程,由于進(jìn)程邊界的存在,攻擊者frame 依舊不能訪問受害者frame 所在的渲染進(jìn)程的數(shù)據(jù),從而實(shí)現(xiàn)更強(qiáng)的安全隔離.

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

5.4 方案對比與討論

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

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

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

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

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

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

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

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

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

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

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

5.5 小 結(jié)

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

6 未來研究展望

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

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

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

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

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

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

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

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

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

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

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

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

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

7 結(jié)束語

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

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