現(xiàn)代瀏覽器中Cookie同源策略測試框架的設計與實現(xiàn)*

梁浩喆，馬 進,2，陳秀真,2，楊 瀟

（1.上海交通大學 網絡空間安全學院，上海 200240；2.上海市信息安全綜合管理技術研究重點實驗室，上海 200240）

0 引 言

Cookie在Web應用程序（Web Application）中通常用于標識用戶的身份或者記住用戶的使用偏好，以便改善用戶體驗。Cookie的使用方法十分簡單，為Web應用的編寫者帶來了許多便利。但是，Cookie也因其簡潔的訪問方式而給Web應用程序帶來了一些安全漏洞，如寬泛授權（Ambient Authority）、弱機密性（Weak Confidentiality）和弱完整性（Weak Integrity）[1-2]。盡管開發(fā)者和標準制定者們想出了許多對策以減輕這些問題的影響，但由于Web文檔（Document）以及同源策略（Same-Origin Policy）的復雜性，標準所覆蓋不到之處總是不可避免。各類Web對象的源（Origin）的不一致性與各種能寫入或者發(fā)送Cookie的請求觸發(fā)方法糾纏在一起，構成了復雜的Cookie訪問規(guī)則[3-4]。澄清這些規(guī)則有助于開發(fā)人員選擇正確的方法來構建他們的Web應用程序，并幫助瀏覽器設計與開發(fā)人員找到瀏覽器設計與實現(xiàn)中的問題。

Cookie在實際應用程序中是保存在瀏覽器中的鍵值對，鍵為Cookie的名字，值為服務器所需存儲的信息，如用戶名、用戶的偏好或用戶的標識。一般來說，如果瀏覽器向服務器發(fā)送請求，Cookie將與該請求一同發(fā)送出去，服務器根據(jù)Cookie中保存的信息確定用戶是否登錄，且應該返回什么樣的結果等。因此，一旦Cookie因為瀏覽器漏洞或者用戶的操作失誤被泄露或被替換，用戶的信息也會隨之泄露，使用戶易遭受身份冒充攻擊（Impersonation Attack）[5]。此外，惡意或受到攻擊者控制的網站可能會設置Cookie來跟蹤用戶的行為或使正常的服務功能失常。較為典型的利用Cookie的Web攻擊是跨站請求偽造（Cross-Site Request Forgery），惡意站點誘使用戶觸發(fā)向用戶已登錄的正常網站的請求，包含登錄信息的Cookie將一同發(fā)送出去。通過這種方式，惡意站點可以像真正的登錄用戶一樣要求正常網站執(zhí)行一些需要特定用戶權限的操作，這將對用戶的賬戶造成損害并泄露個人信息。緩解跨站請求偽造的常用方法是在用戶首次請求網站的Web文檔（Web Document）時，服務端在返回的文檔中嵌入一個屬于該網站的令牌（Token），在其后的請求中要求瀏覽器附上該令牌，惡意網站沒有這個令牌，故不能冒充正常的用戶請求。雖然Token的方法能有效緩解跨站請求偽造的問題，但這種方法并不是用于保護Cookie，并不能阻止Cookie的發(fā)送。

為防止Cookie跨源使用，在瀏覽器實現(xiàn)時通常讓Cookie的發(fā)送遵守同源策略[6]。每個Cookie都有各自的Web源（Origin）[7]，對Cookie的操作是否合法是由根據(jù)同源策略所衍生出的規(guī)則確定的。同源策略是一組復雜的規(guī)則集合，盡管其覆蓋廣泛，但是這些規(guī)則沒有明確的“學術或非學術定義”[8]。除了Cookie之外，其他諸如文檔對象模型對象（DOM Objects）之類的瀏覽器資源都有它們自己對應的源。DOM對象的源和Cookie的源可能有所不同，但它們卻可以交互。DOM文檔中的對象可以發(fā)出攜帶Cookie的請求，或者接收寫入Cookie的響應[8]。這就意味著Cookie與其他Web對象之間的交互沒有明確標準與規(guī)則，同時一些復雜的嵌套與交互所產生的結果可能也與設計者的初衷不符。這些模糊的規(guī)則可能會給攻擊者一些繞過保護的機會，威脅Web應用程序信息的完整性和機密性[9]。

同源策略涉及眾多Web資源，不同的Web資源中又有多種方式可以觸發(fā)攜帶Cookie的請求或者接收寫入Cookie的響應。在一項研究中難以逐一描述全部的規(guī)則，所以針對這個問題的研究一般都只描述同源策略的一個子集。例如，文獻[5，8，10]研究了來自不同源的DOM對象如何訪問其他DOM對象里的內容；文獻[4，11]研究了現(xiàn)代瀏覽器的Cookie保護措施的有效性；文獻[12-13]描述了Local storage和Session storage的同源策略以及Web SQL和相關API中的同源策略。本文的研究內容是由HTML元素所寫入或者發(fā)送的Cookie的同源策略，即HTML元素對Cookie的讀寫規(guī)則。具體來說，本文設計并實現(xiàn)了一個測試框架用于分析在現(xiàn)代瀏覽器中的以下內容：

（1）哪些HTML元素能夠發(fā)送攜帶Cookie的請求，這些請求在跨源時和同源時是否能攜帶一樣的Cookie。

（2）哪些HTML元素能夠在接收的響應中寫入Cookie，這些響應在由跨源的服務器發(fā)出時和由同源的服務器發(fā)出時是否能寫入一樣的Cookie。

（3）當有跨源的嵌套或者同源的嵌套時，上述規(guī)則會變化為怎樣的規(guī)則。

（4）當HTML元素加上相應的安全屬性時，或者當Cookie設置為不同屬性時，上述規(guī)則會變化為怎樣的規(guī)則。

1 研究背景

1.1 Cookie屬性

Cookie是服務器發(fā)送給客戶端的一個“名稱-值”對，當客戶端向該服務器發(fā)送請求時，可以將對應的Cookie附帶在請求中，用來表示一些客戶端的狀態(tài)。一般情況下，除了名稱和值之外，Cookie中還包含了一些關于Cookie本身的元數(shù)據(jù)。這些元數(shù)據(jù)和“名稱-值”對由響應中的Set-Cookies首部寫入，格式為“Set-Cookies：name=value optionalattributes”，其后的可選屬性optional-attributes即是關于Cookie的元數(shù)據(jù)。這些元數(shù)據(jù)告訴客戶端何時應該發(fā)送Cookie，如果客戶端程序實現(xiàn)良好。遵守這些規(guī)定，Cookie將得到一定的保護。

Cookie中的元數(shù)據(jù)即Cookie的屬性，共有7種。其 中，Expires Attribute和Max-Age Attribute表 示Cookie的最大生命周期，即Cookie在什么時間內有效；HttpOnly Attribute將Cookie標記為“HttpOnly”[14]，即Cookie不能被諸如客戶端站點腳本、flash腳本之類的非http API訪問，此屬性能夠緩解一些跨站腳本攻擊（Cross-Site Scripting Attack）；“Secure”屬性告訴用戶代理僅通過安全通道發(fā)送Cookie，如通過HTTPS[15]發(fā)送，但是安全通道也可以是其他通道，其具體的范疇由瀏覽器自行定義；“sameSite”屬性由HTML5引入[16]，擁有這個屬性的Cookie僅能通過同一站點請求發(fā)送。此功能是為了保護Cookie，緩解CSRF攻擊，該屬性有兩個值——Strict和 Lax。

“Domain”屬性和“Path”屬性指明Cookie應該被發(fā)送到的位置，只有“Domain”字段與請求的地址域相同或者是其子域時，Cookie才可以被發(fā)送。類似地，如果Cookie路徑與請求路徑的前綴相同或是其前綴，則允許將發(fā)送Cookie。域和路徑提供了一些區(qū)分不同Cookie的方法，但過于依賴這些功能可能會產生Web應用中的安全漏洞。例如，來自子域sub.domain.com的響應可以將“Domain”屬性設置為domain.com，這些類型的Cookie可以發(fā)送到domain.com域或該域的其他子域，如another.domain.com。

1.2 同源策略

1.2.1 Web源

RFC 6454[7]給出了Web源的定義，文檔中稱Web Origin“通常被用戶代理（User-Agent）用于限定權限（Authority and Privilege）的范圍”，但是該文檔只是詳細定義了一種Web源，即“URI（統(tǒng)一資源標識符）Web Origin”及其相關的規(guī)則，而其他的Web資源（Resource）未被定義，并不遵守這一套規(guī)則。同源策略的根本原則是隔離不同的Web資源，使每個Web資源屬于一個源，在對其他Web源中的Web資源的訪問時將受到限制，并遵循名為“跨源資源共享（Cross Origin Resource Shared）”的規(guī)則[17-18]。URI Web Origin是一個由協(xié)議、域、端口組成的三元組[19]，當某一URI與另一URI的這三種屬性都相同時才屬于同一個源，例如，以下URI具有不同的來源：

HTTPS：//cookie.test：80

HTTP：//cookie.test：80

HTTPS：//cookie.test：8080

HTTPS：//localstorage.test：80

下列URI有相同的源：

HTTPS：//cookie.test/tag/img

HTTPS：//cookie.test/tag/iframe

需要注意的是，對于DOM Web資源來說，URL的域部分一般是主機（Host）名。Host一般指的是“由封裝在方括號內的點分十進制形式的IPv4地址或注冊名稱”構成的標識[20]。

1.2.2 同源策略的不一致性

一個Web文檔中的Web資源不一定與該文檔的源相同。URI Web Origin僅適用于某些Web資源，如DOM對象、本地腳本等，而其他的Web資源有其自己的關于“源”的定義。例如，Cookie的源與DOM對象的源略有不同，因為Cookie源不包括端口，這意味著Cookie可能被發(fā)送到在同一服務器上正在運行的不同進程，因此Cookie的同源策略與HTML元素的同源策略在實現(xiàn)中是有區(qū)別的。嵌入式HTML元素（embedded HTML Element）可以將屬于外部源的Web資源引入文檔，同時可以寫入和發(fā)送Cookie。這種通過HTML元素請求（或響應）寫入（或發(fā)送）Cookie的跨源操作是一個未明確定義的操作，需要進行測試以了解用戶代理（通常是瀏覽器）是如何處理這種情況的。

2 Cookie訪問模型設計

2.1 訪問規(guī)則描述

為了清楚地描述通過HTML元素對Cookie進行寫入或讀取的規(guī)則，本文定義了一種訪問模型。在該模型中，進行訪問的主體是HTML元素，被訪問的對象是瀏覽器中的Cookie。影響訪問控制的因素包括HTML元素本身及其屬性以及上述Cookie的屬性，共9個因素：（1）HTML元素；（2）HTML元素屬性；（3）Cookie；（4）Cookie屬性；（5）請求源；（6）目的源；（7）請求觸發(fā)器屬性；（8）HTTP模 式（schema）；（9） 請 求 方法。模型中，HTML元素可以對Cookie執(zhí)行兩個操作，即寫Cookie（Write Cookie）和讀Cookie（Read Cookie）。每一條讀寫規(guī)則以及每個測試用例都是上述9個因素和兩個操作的組合,。

2.2 訪問屬性詮釋

2.2.1 讀cookie操作

一個HTML元素可以讀取一個Cookie意味著由該HTML元素觸發(fā)的瀏覽器請求可以攜帶該Cookie。例如，如果標簽 ＜img src=“store-cookie_endpoint”/＞可以向服務器發(fā)送帶有“name=value”cookie的請求，意味著標簽img可以讀取Cookie“name=value”。

2.2.2 寫Cookie操作

一個HTML元素可以寫一個Cookie，意味著瀏覽器會根據(jù)與由該HTML元素觸發(fā)的請求所對應的響應中的Set-Cookie響應頭來設置Cookie。例如，如果標簽 ＜img src=“set-cookie_endpoint”/＞向服務器發(fā)送請求，服務器返回帶有Set-Cookie：name=value響應頭的響應，瀏覽器在接收到響應后設置了Cookie“name=value”，表明標簽img可以設置Cookie“name=value”。

2.2.3 HTML元素屬性

某些HTML元素屬性會影響Cookie的發(fā)送，如＜iframe＞的sandbox屬性，另一些屬性如＜link＞中的ref會影響請求是否被觸發(fā)。

2.2.4 Cookie屬性

如1.1節(jié)中所述。

2.2.5 請求源和目的源

發(fā)送源和目標源分別是請求發(fā)出的域和請求發(fā)送到的域。

2.2.6 請求觸發(fā)器屬性

HTTP標準中的一些URI屬性[21]，是可觸發(fā)HTTP請求的屬性，如src、href以及data。

2.2.7 HTTP模式和請求方法

HTTP模式可以是“http”或“https”，請求方法即HTTP協(xié)議的請求方法，如GET、OPTION、HEAD等，而HTML元素請求中的請求方法通常是GET。當Cookie具有“Secure”屬性或“HttpOnly”屬性時，請求方法會影響Cookie是否隨請求一起發(fā)送。

3 框架實現(xiàn)

本文設計的測試工具為一個Web應用程序，其工作方式與普通的Web應用程序相同，以便檢測瀏覽器在實際使用時的表現(xiàn)。前端測試應用有兩種模式：一種是預定義模式（見圖1），前端應用程序可以根據(jù)用戶所選定的元素和屬性向后端應用發(fā)送請求，加載一些預先設計好的HTML元素測試用例；另一種是自定義模式（見圖2），允許由用戶在前端頁面中添加一些新設計的測試用例，包括HTTP元素的嵌套、元素屬性的自定義和Cookie屬性的定義等。后端應用程序負責解析請求，檢查Cookie是否存在，存儲請求信息，包括Cookie（如果存在的話）。前端應用程序將在后續(xù)步驟中獲取測試結果，并將其顯示給用戶。

圖1 預定義模式測試程序

圖2 自定義測試模式測試程序

3.1 框架結構

本文設計的測試框架包含4個主要部分（如圖3所示）：1個前端Web應用程序、2個后端應用程序和1個用于存儲請求信息的共享存儲，且該存儲由2個后端程序共享。前端應用程序可以從后端應用程序加載默認測試用例，或從用戶輸入中生成測試用例；被測試的HTML元素將掛載在前端程序提供的頁面上。在該頁面上，HTML元素將嘗試觸發(fā)對后端“set-cookie”節(jié)點（endpoint）或者“store-cookie”節(jié)點的請求。請求的節(jié)點不同，所進行的測試也不同，根據(jù)所請求的節(jié)點，進行的測試將分為寫入測試和讀取測試。此外，前端程序還負責從后端獲取測試結果的信息，并將它們有組織地展示在頁面中。

圖3 測試框架的結構

兩個后端應用程序的域名是不同的，一為“firstparty.test”，二為“third-party.test”，分別作為測試中的第一方源和第三方源。第一方為發(fā)出跨源請求的源，第三方為接收跨源請求的源。在測試中，第一方同時也發(fā)出同源請求作為對照。每個后端應用都有“set-cookie”和“store-cookie”兩個節(jié)點。“setcookie”節(jié)點用于寫入測試，根據(jù)測試需求嘗試對瀏覽器寫入Cookie。具體來說，該節(jié)點返回帶有“Set-Cookie”響應頭的響應，響應頭的值將根據(jù)前端應用的請求參數(shù)設置，可以包括任何Set-cookie屬性，如“HttpOnly”“sameSite”等?！皊tore-cookie”節(jié)點用于讀取測試，接收HTML元素觸發(fā)的請求，判斷其中是否包含Cookie；如果包含Cookie，后端程序便將與Cookie相關的信息儲存起來，即在共享存儲中存儲被發(fā)送的Cookie和它們所具有的屬性。此外，第一方應用負責將測試結果發(fā)送到前端應用程序。

3.2 框架工作流程

測試工具的完整工作流程如圖3所示。要對一個測試用例進行一次測試，前端首先從后端加載測試用例信息或自定義輸入用例信息，生成帶有指定安全屬性的HTML標簽。標簽包括可以觸發(fā)請求的屬性，該屬性指向需要進行測試的后端節(jié)點，然后將該標簽掛載在頁面上。瀏覽器會解析HTML標記，并根據(jù)其實現(xiàn)決定下一步要做什么。每一次測試都包括對該測試用例的讀測試和寫測試，每個寫測試和讀測試都會分別向第一方應用和第三方應用發(fā)起請求。因此，對一個測試用例進行測試，會發(fā)送4個測試請求。在4個請求都完成后，后端應用會將測試結果返回給前端用戶。為清晰起見，這里給出一次測試的完整過程：

算法1：對一個測試用例進行一次完整的測試

輸入 測試用例信息 test_case_info

輸出 測試結果 test_result

1.generateTags(test_case_info);

2.//write test

3.mount(write_tag_point_to_same_site);

4.mount(write_tag_point_to_cross_site);

5.sendToBackend(Cookie_be_written);

6.//read test

7.setCookie(Cookie_should_be_read);

8.mount(read_tag_point_to_same_site);

9.mount(read_tag_point_to_cross_site);

10.test_result=fetch(same_site_test_result);

11.test_result+=fetch(cross_site_test_result);

3.3 測試舉例

對于測試用例（圖2），有：＜iframe sanbox=“allow-script”

src=“http：//thirdpaty.test/store-cookie”＞

假設瀏覽器中存在帶有“HttpOnly”屬性的第三方Cookie“external=third-party”，同時第一方文檔中存在一個嵌入式元素＜iframe＞，它指向第三方應用的讀取測試節(jié)點“store-cookie”，那么對應的測試結果將表示為9個因素組合而成的一條規(guī)則，如表1所示。

表1 測試結果舉例

如果后端能夠接收到Cookie，那么結果可以解釋為：帶有sandbox=allow-script屬性且指向第三方節(jié)點的HTML元素iframe可以讀取帶有HttpOnly屬性的第三方Cookie；反之，如果服務器無法接收任何Cookie，那么說明該元素不能讀該Cookie。寫入測試結果可以用類似的方式解讀，只要將規(guī)則中的讀取操作替換為寫入操作即可。

圖4為測試結果示例。

圖4 測試結果示例

4 結 語

為厘清通過HTTP元素進行Cookie跨源讀寫的規(guī)則，以幫助應用開發(fā)者構建更為安全的Web應用，以及幫助標準制定者制定更合理的Cookie讀寫標準，本文設計了一種針對現(xiàn)代瀏覽器的測試框架。該框架便于測試人員控制與跨源訪問相關的9個變量，能夠確定在復雜環(huán)境下主流瀏覽器的實際行為。此外，該框架的實現(xiàn)具有可擴展性，能夠依據(jù)測試者的意愿即時構造測試用例和測試頁面進行測試，增加了測試的靈活性，為以后進一步的研究奠定了基礎。