摘  要： 提出了一種新的安全解決方案，主要采用frame片段標(biāo)識(shí)符技術(shù)在瀏覽器端實(shí)現(xiàn)跨域數(shù)據(jù)通信，在此基礎(chǔ)上主要關(guān)注3個(gè)安全因素：數(shù)據(jù)保密、身份驗(yàn)證和數(shù)據(jù)完整。該方案不需要對(duì)當(dāng)前的瀏覽器環(huán)境進(jìn)行任何修改就可實(shí)現(xiàn)異源內(nèi)容相互間安全的通信。
關(guān)鍵詞： 聚合；安全；同源策略；跨域通訊

    在Web2.0時(shí)代，一種新型的基于Web的數(shù)據(jù)集成應(yīng)用程序——Mashup，逐漸在Internet上變得越來(lái)越流行。在IBM、微軟等企業(yè)的推動(dòng)下，今后數(shù)年內(nèi)Mashup將成為主流應(yīng)用。即使商業(yè)用戶的IT技術(shù)水平并不高，同樣也可創(chuàng)建符合自身需求的Mashup，并將這些Mashup加以組合，IT產(chǎn)業(yè)的安全性也將隨之大幅提高[1]。
    目前，Mashup應(yīng)用仍然處于萌芽階段，但Mashup和其他類(lèi)型的Web應(yīng)用一樣，也面臨著各種各樣的安全問(wèn)題。因此，本文主要分析了Mashup的安全問(wèn)題，并提出一種新的安全解決方案以提高M(jìn)ashup的安全性。
1 Mashup(聚合)的基本概念
    Mashup是一類(lèi)Web應(yīng)用(或Web站點(diǎn))，集成了來(lái)自多個(gè)源站點(diǎn)的內(nèi)容和代碼并將其集成到一個(gè)頁(yè)面中，其主要目標(biāo)是為用戶提供一種更加集成和方便的使用體驗(yàn)[2]。例如，www.housingmaps.com將Google Maps上的地圖與Craigslist(美國(guó)網(wǎng)上廣告公司)的房屋信息集成在一起，因此，用戶可以從谷歌地圖上直觀地獲得不同地點(diǎn)的房屋價(jià)格信息并能據(jù)此進(jìn)行房屋租賃或銷(xiāo)售等業(yè)務(wù)。這種概念和呈現(xiàn)方式非常簡(jiǎn)單，房屋價(jià)格信息和地圖數(shù)據(jù)集成之后提供的可視化功能非常強(qiáng)大。
    通常將上例中的www.housingmaps.com稱(chēng)為集成者，它集成了由第三方(如Google和Craigslist，也稱(chēng)為內(nèi)容提供者)提供的內(nèi)容和代碼，并為用戶提供了所需要的一站式的服務(wù)。而第三方提供的資源，在Mashup中被稱(chēng)為組件(由HTML與JavaScript組成，旨在被集成到集成者的網(wǎng)頁(yè)中，它通常是客戶端的一些Web服務(wù))。
    Mashup應(yīng)用通常主要有兩種框架結(jié)構(gòu)：服務(wù)器端框架和客戶端框架，如圖1所示。

    服務(wù)器端框架是一種傳統(tǒng)的聚合方式，首先在服務(wù)器端集成異源的內(nèi)容和服務(wù)，然后將集成后的頁(yè)面返回到瀏覽器。圖1所示為框架中的集成者(i.com)實(shí)際上起到代理的作用，因此，存在一些弊端：
    (1)對(duì)第三方資源的請(qǐng)求/響應(yīng)都需經(jīng)過(guò)i.com，降低了性能；
    (2)大量用戶可能導(dǎo)致過(guò)度的服務(wù)器負(fù)載，i.com易成為瓶頸點(diǎn)，可擴(kuò)展性差；
    (3)i.com易成為黑客的攻擊點(diǎn)。
    近年來(lái)，隨著Ajax技術(shù)及相關(guān)技術(shù)的發(fā)展，Mashup應(yīng)用出現(xiàn)了客戶端框架，即在瀏覽器端集成異源的內(nèi)容和服務(wù)，例如www.housingmaps.com就采用此種框架。同時(shí)，內(nèi)容提供者(即第三方)也更愿意提供客戶端的服務(wù)，如Google公司提供的Maps API就是一種非常流行的用于客戶端的組件，集成者可以方便地將該組件集成到自己的Mashup應(yīng)用中。由圖1可知，集成者(i.com)將來(lái)自異源的內(nèi)容和服務(wù)集成到一個(gè)網(wǎng)頁(yè)中，集成者和組件、組件與組件之間可以在瀏覽器端進(jìn)行通信，組件(如a.com)可以使用Ajax技術(shù)異步訪問(wèn)服務(wù)器來(lái)實(shí)現(xiàn)網(wǎng)頁(yè)局部刷新的效果，給用戶帶來(lái)更好的使用體驗(yàn)?；诖耍疚闹饕芯苛丝蛻舳丝蚣芟碌陌踩珣?yīng)用問(wèn)題。
2 瀏覽器的安全模型及Mashup的應(yīng)用安全
2.1 同源策略與“全有或全無(wú)”模型
    目前由瀏覽器所實(shí)現(xiàn)的安全模型是同源策略，最早出自Netscape Navigator2.0。這里的同源是指同協(xié)議、同域名和同端口[3]。如果2個(gè)網(wǎng)頁(yè)具有相同的協(xié)議、域名和端口，則認(rèn)為它們是同源的。所謂同源策略，是指由某一來(lái)源的腳本不允許讀取或設(shè)置來(lái)自另一不同來(lái)源的文檔的屬性。該機(jī)制將異源的Web應(yīng)用程序分離開(kāi)，即如果多個(gè)瀏覽器窗口、<frame>或<iframe>元素(下文統(tǒng)一用<frame>表示)中的文檔是從不同的服務(wù)器下載的，則它們無(wú)法相互訪問(wèn)數(shù)據(jù)和腳本，瀏覽器的腳本只被允許訪問(wèn)來(lái)自同源的資源(如DOM和Cookie等資源)，并能創(chuàng)建XMLHttpRequest對(duì)象異步訪問(wèn)文檔來(lái)源所指服務(wù)器的資源。例如，<frame>A(來(lái)自http://a.com)不能訪問(wèn)
<frame>B(來(lái)自http://b.com)中的任何DOM元素，反之亦然。來(lái)自a.com的腳本也只能創(chuàng)建XMLHttpRequest對(duì)象異步訪問(wèn)a.com，而不能異步訪問(wèn)b.com。
    但上文所提的同源策略有一個(gè)例外，文檔中包含的腳本資源文件和圖像文件被視為文檔的組成部分，因此認(rèn)為與文檔是同源的，即使它們實(shí)際上存在于不同的網(wǎng)域中。例如，a.com/service.html中包含<script src=“http://b.com/lib.js”>，雖然lib.js來(lái)自b.com，但被認(rèn)為是a.com/service.html的組成部分，即lib.js與service.html是同源的，都來(lái)自a.com，因此lib.js(雖然來(lái)自b.com)中的腳本也就能夠訪問(wèn)a.com/service.html的DOM等資源，并能創(chuàng)建XMLHttpRequest對(duì)象異步訪問(wèn)a.com。
    同源策略比較適用于Internet發(fā)展的早期。由于這時(shí)很少網(wǎng)站將重要的應(yīng)用邏輯放在瀏覽器端，即使有，這些網(wǎng)站也只限于自己的服務(wù)器而不同第三方打交道，因此，同源策略能有效避免惡意的攻擊。但I(xiàn)nternet發(fā)展到今天，情況已有了很大的不同。許多集成者更愿意集成多個(gè)來(lái)源的內(nèi)容到他們的站點(diǎn)中，為用戶提供定制化和更有附加值的服務(wù)。由前面的分析可知，Mashup的本質(zhì)就是要集成多個(gè)來(lái)源的內(nèi)容和服務(wù)，而同源策略卻是不允許使用來(lái)自不同源的內(nèi)容。這導(dǎo)致在開(kāi)發(fā)Mashup應(yīng)用時(shí)只能采用“全有或全無(wú)”模型，即站點(diǎn)a.com或者完全不信任來(lái)自站點(diǎn)b.com的內(nèi)容，在集成時(shí)將來(lái)自b.com的內(nèi)容隔離在<frame>元素中；或者完全信任來(lái)自站點(diǎn)b.com的腳本，在集成時(shí)將來(lái)自站點(diǎn)b.com的腳本放到<script>標(biāo)記中，而這些腳本能完全訪問(wèn)來(lái)自a.com的資源。因此，需要實(shí)現(xiàn)一種方法使得瀏覽器能夠支持合法的跨域數(shù)據(jù)訪問(wèn)，但是無(wú)需犧牲終端用戶的安全和對(duì)自身數(shù)據(jù)的控制。
2.2 Mashup應(yīng)用安全
    Mashup擁有兩個(gè)最本質(zhì)的特性：互通信能力和安全性?；ネㄐ拍芰κ侵讣烧吲c組件或組件間相互通信的能力。在簡(jiǎn)單的Mashup中，可能不需要這種互通信能力，此時(shí)可將組件包含在<frame>中，利用同源策略來(lái)隔離異源的資源以達(dá)到保護(hù)的目的。但在越來(lái)越趨于復(fù)雜的Mashup應(yīng)用中，集成者與組件間確實(shí)需要相互通信的能力。安全性要求來(lái)自某源的組件不能存取來(lái)自另一源的組件的保密信息，如DOM、cookies等信息。根據(jù)同源策略及“全有或全無(wú)”模型，當(dāng)不同來(lái)源的組件集成到集成者的同一網(wǎng)頁(yè)時(shí)，相互之間不能通信，除非采取一些技術(shù)手段來(lái)繞過(guò)同源策略的限制。結(jié)果通常造成開(kāi)發(fā)人員被迫必須在安全性和功能之間進(jìn)行權(quán)衡，導(dǎo)致為了滿足功能而犧牲應(yīng)用的安全性。為此，已經(jīng)存在的Mashup應(yīng)用采用了許多繞開(kāi)同源策略的措施：
    (1)Ajax代理，Mashup服務(wù)器端框架經(jīng)常使用的一種方法[4]。例如，由于同源策略的限制，a.com/service.html中的JavaScript代碼是不能訪問(wèn)位于b.com中的某一Web服務(wù)ServiceB的，但可以在a.com中建立新的Web服務(wù)ServiceProxy，則a.com/service.html可通過(guò)Ajax訪問(wèn)a.com/ServiceProxy，而ServiceProxy的功能就是將請(qǐng)求轉(zhuǎn)發(fā)給b.com/ServiceB，由ServiceB產(chǎn)生的響應(yīng)結(jié)果再按原路徑返回給a.com/service.html。
    (2)<frame>片段標(biāo)識(shí)符技術(shù)，Mashup客戶端框架經(jīng)常使用的方法。通過(guò)frame.src屬性的片段標(biāo)識(shí)符(URL中#符號(hào)后的部分)，使用了頁(yè)面腳本和隱藏的<frame>標(biāo)記之間進(jìn)行通信以繞過(guò)同源策略的限制。
    當(dāng)前開(kāi)發(fā)Mashup時(shí)，集成者通常將第三方提供的組件封裝到<frame>標(biāo)記中，利用同源策略所提供的安全機(jī)制，以實(shí)現(xiàn)安全的目的。但集成者與組件間通常更需要協(xié)作，筆者認(rèn)為在瀏覽器端利用<frame>片段標(biāo)識(shí)符技術(shù)進(jìn)行通信時(shí)應(yīng)當(dāng)滿足以下3個(gè)主要的安全因素：
    (1)數(shù)據(jù)保密。在Mashup應(yīng)用中，經(jīng)常有這樣的場(chǎng)景：如用戶可能在某一網(wǎng)頁(yè)中輸入內(nèi)容，并希望此內(nèi)容將只提供給特定的組件，而不被其他第三方截獲?；蛘?，集成者、組件提供者和用戶可能共享一個(gè)秘密信息，而不希望此信息被無(wú)關(guān)的第三方截獲。因此，在瀏覽器端實(shí)現(xiàn)消息傳遞機(jī)制時(shí)，應(yīng)能保證消息只能被相關(guān)的參與方獲取，而其他無(wú)關(guān)的第三方不能截獲到此消息。
    (2)身份驗(yàn)證。參與通信的雙方能夠相互進(jìn)行身份驗(yàn)證是瀏覽器端消息傳遞機(jī)制另一個(gè)很重要的安全要求。在Mashup應(yīng)用中進(jìn)行身份驗(yàn)證主要是指通信雙方能驗(yàn)證彼此的域名。
    (3)數(shù)據(jù)完整。數(shù)據(jù)完整是指集成者和組件提供者提供給用戶的內(nèi)容是沒(méi)有被攻擊者篡改過(guò)的，也即意味著被攻擊者篡改過(guò)的消息能被檢測(cè)出來(lái)。
3 <frame>片段標(biāo)識(shí)符安全通信技術(shù)
3.1 基于<frame>片段標(biāo)識(shí)符的跨域數(shù)據(jù)訪問(wèn)
    <frame>標(biāo)記能夠在一個(gè)HTML文件中封裝和顯示另一個(gè)完整的HTML文件。通常稱(chēng)<frame>所在的網(wǎng)頁(yè)為父頁(yè)面，而<frame>所包含的網(wǎng)頁(yè)(通過(guò)向frame.src屬性指定一個(gè)URL來(lái)確定)稱(chēng)為子頁(yè)面。
    目前開(kāi)發(fā)Mashup應(yīng)用時(shí)，集成者通常將組件封裝到<frame>標(biāo)記中。當(dāng)<frame>的源URL與其父頁(yè)面同源時(shí)，根據(jù)同源策略，父頁(yè)面中的JavaScript可通過(guò)<frame>的DOM訪問(wèn)它的所有內(nèi)容。同樣，<frame>也可以通過(guò)其父頁(yè)面的DOM訪問(wèn)父頁(yè)面的所有內(nèi)容。然而，當(dāng)異源時(shí)，父頁(yè)面不能訪問(wèn)<frame>的內(nèi)容，<frame>也無(wú)法訪問(wèn)父頁(yè)面的內(nèi)容。此時(shí)，可利用frame.src屬性的片段標(biāo)識(shí)符(如http://a.com/proxy.html#data_here，#符號(hào)后的data_here就是要傳遞的數(shù)據(jù))來(lái)實(shí)現(xiàn)跨域數(shù)據(jù)訪問(wèn)。<frame>的外部代碼(如主頁(yè)面中的Javascript代碼)不能讀取frame.src，但可以重寫(xiě)frame.src，此即frame.src屬性的只寫(xiě)特性。這樣，<frame>的外部代碼就可以根據(jù)已知文檔的URL，構(gòu)造“URL+#+要傳遞的數(shù)據(jù)”字符串，指定給frame.src屬性，并將觸發(fā)子頁(yè)面的onLoad事件，于是在子頁(yè)面的onLoad事件處理程序中可接受父頁(yè)面?zhèn)鬟^(guò)來(lái)的數(shù)據(jù)并決定下一步的操作。如圖2所示，集成者i.com/main.html由于同源策略的限制，在瀏覽器端不能訪問(wèn)a.com的資源。因此，可通過(guò)以下步驟實(shí)現(xiàn)i.com/main.html將數(shù)據(jù)data_here傳送給a.com。
    (1)i.com/main.html(即父頁(yè)面，包含frame1元素)設(shè)置frame1.src=“http://a.com/proxy.html#data_here”。
    (2)frame1下載頁(yè)面a.com/proxy.html。通過(guò)frame.src來(lái)傳遞數(shù)據(jù)可以使用#將數(shù)據(jù)加到frame的URL結(jié)尾來(lái)實(shí)現(xiàn)。
    (3)子頁(yè)面(a.com/proxy.html)的onLoad事件被激活。此時(shí)，可通過(guò)window.location.hash取出i.com/main.html傳遞過(guò)來(lái)的數(shù)據(jù)data_here。
    (4)由于frame1和組件a.com同源，故能相互訪問(wèn)彼此的資源，即組件a.com也就能訪問(wèn)i.com/main.html傳過(guò)來(lái)的數(shù)據(jù)data_here。
    當(dāng)組件a.com處理完數(shù)據(jù)data_here后，需要將數(shù)據(jù)data_toI傳遞給父頁(yè)面i.com/main.html，也可以通過(guò)frame1來(lái)傳遞嗎？答案是否定的，frame1不能給它的父頁(yè)面?zhèn)鬟f任何消息，因?yàn)樗鼈兾挥诓煌脑?。但是frame1(a.com)可以包含另一個(gè)frame2，圖2中，frame1通過(guò)設(shè)置frame2.src為父頁(yè)面的URL(即i.com)。這時(shí)，i.com/main.html包括frame1(域?yàn)閍.com)，而frame1又包含frame2(域?yàn)閕.com)。同時(shí)，可以發(fā)現(xiàn)frame2.parent.parent正是i.com/main.html，且frame2和main.html同源，因此在frame2中可以通過(guò)frame2.parent.parent訪問(wèn)main.html的任何內(nèi)容，調(diào)用main.html中的JavaScript函數(shù)。實(shí)現(xiàn)步驟如下：
    (1)組件a.com通過(guò)在frame1(a.com/proxy.html)中設(shè)置frame2.src=“http://i.com/proxy.html#data_toI”；
    (2)frame2下載頁(yè)面i.com/proxy.html。之后子頁(yè)面的onLoad事件被激活，在onLoad事件中可通過(guò)window.location.hash取得組件a.com傳過(guò)來(lái)的數(shù)據(jù)data_toI。
    (3)由于frame2(i.com/proxy.html)和i.com/main.html同源，故在frame2中可調(diào)用main.html的receiveFromA函數(shù)將數(shù)據(jù)data_toI傳遞給main.html。

    但上述使用<frame>片段標(biāo)識(shí)符的跨域數(shù)據(jù)訪問(wèn)存在一個(gè)安全問(wèn)題：不確定數(shù)據(jù)的來(lái)源。當(dāng)main.html通過(guò)frame1.src向組件a.com傳送數(shù)據(jù)data_here時(shí)，由于同源策略的安全機(jī)制，雖然可以保證數(shù)據(jù)能被組件a.com獲得。但是，當(dāng)組件a.com得到數(shù)據(jù)data_here時(shí)，沒(méi)有直接的方法得知數(shù)據(jù)的來(lái)源。而在大多數(shù)情況下，不確定來(lái)源的數(shù)據(jù)是不安全的。因此，必須要有能實(shí)現(xiàn)對(duì)通信雙方的身份進(jìn)行驗(yàn)證的方法克服此安全漏洞。受TCP三次握手的啟發(fā)，本文提出一種利用共享密鑰技術(shù)在瀏覽器端實(shí)現(xiàn)跨域通信雙方身份驗(yàn)證的方法，如圖3所示。父頁(yè)面i.com/main.html首先產(chǎn)生密鑰SK1，并使用<frame>片段標(biāo)識(shí)符技術(shù)將SK1傳遞給子頁(yè)面frame1(a.com/proxy.html)。接收方frame1可通過(guò)將密鑰SK1作為數(shù)據(jù)包的一部分傳回main.html以證明接收方frame1確實(shí)來(lái)源為a.com。但是frame1還需要證明發(fā)送方是來(lái)自于i.com，因此，frame1又產(chǎn)生一個(gè)新的密鑰SK2，并將SK1和SK2一起傳送給main.html，若main.html能將SK2作為密鑰再傳給frame1就能證明發(fā)送方main.html確實(shí)來(lái)自i.com。至此，main.html和frame1都擁有了密鑰SK2，故可將SK2作為共享密鑰，并使用它來(lái)完成接下來(lái)的通信。圖3所示main.html將“SK2＋要傳的數(shù)據(jù)”作為數(shù)據(jù)包傳給frame1，frame1將先驗(yàn)證密鑰是否等于SK2，如果是，則接受傳過(guò)來(lái)的數(shù)據(jù)。因此，對(duì)于惡意的攻擊可以很容易被識(shí)別和去除。

3.2 安全分析
    從數(shù)據(jù)保密、身份驗(yàn)證和數(shù)據(jù)完整3個(gè)方面來(lái)分析上述基于<frame>片段標(biāo)識(shí)符的跨域數(shù)據(jù)訪問(wèn)方案的安全性。
    (1)數(shù)據(jù)保密。利用瀏覽器提供的同源策略限制和frame.src的只寫(xiě)特性來(lái)實(shí)現(xiàn)數(shù)據(jù)保密性。在父頁(yè)面和<frame>之間傳送的數(shù)據(jù)不會(huì)被父頁(yè)面上其他的DOM元素看到，因?yàn)?lt;frame>與父頁(yè)面處在不同的源。而且數(shù)據(jù)不出現(xiàn)在瀏覽器緩存中，數(shù)據(jù)也不會(huì)跨過(guò)網(wǎng)絡(luò)，因此可以認(rèn)為數(shù)據(jù)包只能被接收的<frame>或來(lái)自a.com的其它頁(yè)面觀察到。
    (2)身份驗(yàn)證。圖3中利用共享密鑰的技術(shù)能保證瀏覽器客戶端跨域通信雙方身份的驗(yàn)證。frame1只有當(dāng)其將父頁(yè)面?zhèn)鬟^(guò)來(lái)的密鑰SK1再傳回父頁(yè)面時(shí)，才能讓它的身份得到驗(yàn)證；類(lèi)似的，父頁(yè)面也只有將密鑰SK2傳回frame1時(shí)，才能驗(yàn)證它的身份。之后，通過(guò)利用父頁(yè)面和frame1的共享密鑰SK2來(lái)保證雙方通信的機(jī)密性。
    (3)數(shù)據(jù)完整。攻擊者篡改過(guò)的數(shù)據(jù)能被檢測(cè)出來(lái)。要篡改通信的數(shù)據(jù)，攻擊者需要知道共享密鑰SK2，否則在目的地，傳過(guò)來(lái)的數(shù)據(jù)包將被拒絕并被丟棄。因此，沒(méi)有經(jīng)過(guò)身份驗(yàn)證的組件是不能篡改數(shù)據(jù)的。
    當(dāng)前所有瀏覽器端所實(shí)現(xiàn)的安全模型是同源策略，其導(dǎo)致了異源內(nèi)容間只能是“完全信任”或“完全不信任”的結(jié)果。隨之帶來(lái)的問(wèn)題是：Mashup不能在實(shí)現(xiàn)功能性需求的同時(shí)也能很好地解決安全問(wèn)題。因此，需要瀏覽器實(shí)現(xiàn)一種新的安全模型，使得瀏覽器能夠支持合法的跨域數(shù)據(jù)訪問(wèn)，而無(wú)需犧牲終端用戶的安全。但是，主流瀏覽器要實(shí)現(xiàn)新的安全模型并在業(yè)內(nèi)普遍使用需要幾年的時(shí)間，同時(shí)一些研究者提出的解決方案中或者要求改進(jìn)當(dāng)前的瀏覽器環(huán)境；或者不能提供一個(gè)靈活和安全的點(diǎn)到點(diǎn)的域間通信機(jī)制[5-6]。本文提出了一種新的域間通信機(jī)制，它不需要對(duì)當(dāng)前的瀏覽器環(huán)境進(jìn)行任何修改就可適用，并且主要考慮了3個(gè)安全因素：數(shù)據(jù)保密、身份驗(yàn)證和數(shù)據(jù)完整。在不遠(yuǎn)的將來(lái)，通過(guò)不斷改善瀏覽器技術(shù)，及增加新的Web標(biāo)準(zhǔn)使Mashup更加安全，Mashup方式也將會(huì)得到更廣泛的應(yīng)用。
參考文獻(xiàn)
[1] 佚名.Garter：IT業(yè)界未來(lái)四年的十大新技術(shù)[EB/OL].http://networking.ctocio.com.cn/NetInformation/105/8147605.shtml，2008-06-03.
[2] Jyrki Hakkola. Mashup Security[EB/OL]. http://www.tml.tkk.fi/Opinnot/T-111.5550/2008/seminaari_hakkola_jyrki.pdf，2008-11-04.
[3] Aaron Bohannon. Building Secure Web Mashups[M/OL]. www.cis.upenn.edu/~bohannon/mashups.pdf，2008-7-16.
[4] 陳臘梅，李為．AJAx跨域訪問(wèn)的研究與應(yīng)用[J].計(jì)算機(jī)工程與設(shè)計(jì)，2008(11):5680－5684.
[5] Frederik De Keukelaere， Sumeer Bhola. SMash: Secure Component Model for Cross-Domain Mashups on Unmodified Browsers[EB/OL]. www2008.org/papers/pdf/p535-dekeukelaereA.pdf，2008-7.
[6] JACKSON C， WANG H J. Subspace: Secure CrossDomain Communicationfor Web Mashups[EB/OL]. www.collinjackson.com/research/papers/fp801-jackson.pdf.2007-5.