導(dǎo)語：Web聚合運用跨域通信機制一文來源于網(wǎng)友上傳，不代表本站觀點，若需要原創(chuàng)文章可咨詢客服老師，歡迎參考。

1引言

在傳統(tǒng)的web1.0應(yīng)用程序中，每個Web站點相互隔離，用戶訪問Web站點僅能得到來自本站點的信息。即使需要訪問其他站點，也是通過編輯拷貝已存儲在本地的信息或者用戶調(diào)換網(wǎng)站地址的方式來訪問內(nèi)容，而不是直接訪問信息源數(shù)據(jù)。在新的Web2.0潮流之下，希望網(wǎng)站之間打破隔離進行數(shù)據(jù)融合，使之能夠共享信息。在這種背景下，聚合型網(wǎng)站設(shè)計方式應(yīng)運而生，這就是新型的Web應(yīng)用程序——聚合應(yīng)用(mashupapplication)。Mashup這個名詞來源于流行音樂，將不同風(fēng)格的音樂拼接，混雜在一起，構(gòu)成自己獨特的新曲子；Mashup在Web環(huán)境中代表著整合不同來源的內(nèi)容以提供交互式體驗的Web站點或應(yīng)用程序[1]。利用其他網(wǎng)站開放應(yīng)用接口所提供的內(nèi)容進行混搭，從而創(chuàng)造出獨特的、具有新價值的Web應(yīng)用。Mashup把不同源或站點的信息進行融合以保證信息共享，打破站點之間“孤島林立”的現(xiàn)狀，由此瀏覽Web站點更加直觀便捷，用戶體驗更加富。典型的Mashup應(yīng)用當屬Housingmap，它將第三方網(wǎng)站Craigslist的租房信息和GoogleMaps提供的地圖信息有機地組織起來，讓租房的信息直觀顯示在地圖上，創(chuàng)造出一個嶄新的、互動性強的房屋搜尋站點[2]。根據(jù)以上實例背景，本文建立一個Housingmap聚合應(yīng)用模型，由電子地圖與租房信息2部分組成，如圖1所示。傳統(tǒng)的Web瀏覽器安全機制遵守同源策略(SOP,same-originpolicy)。同源策略規(guī)定JavaScript(JS)代碼只能訪問其來自同源服務(wù)器上的數(shù)據(jù)，把來自不同源的內(nèi)容相互分離。這種策略給JS提供安全保障的同時限制了基于JS的跨域訪問。Mashup是對多個站點資源的優(yōu)化組合，需要從多個分散的站點獲取信息源，而不要求各個站點之間相互信任。傳統(tǒng)同源策略過渡的安全設(shè)計沒有考慮多個站點之間交互時整體的快速通信需求，也沒考慮新的信任模型下的安全問題。如圖1所示，電子地圖與租房信息的數(shù)據(jù)分別來自www.map-和www.housing-2個不同源的網(wǎng)站，在現(xiàn)有的同源策略下是不能夠相互訪問和通信。怎樣整合相互獨立的第三方數(shù)據(jù)、實現(xiàn)不同源數(shù)據(jù)之間的通信是聚合應(yīng)用需要解決的問題。另外，惡意攻擊者可能重寫來自其他源的網(wǎng)頁屬性，例如來自www.map-的腳本可能重寫www.housing-網(wǎng)頁的location屬性，操縱原頁面跳轉(zhuǎn)到某個惡意的頁面，而導(dǎo)致框架釣魚攻擊。如何保證不同源數(shù)據(jù)間通信的安全性與完整性是聚合應(yīng)用需要解決的另外一個問題。針對上述問題，研究人員在聚合應(yīng)用跨域交互方面做了大量研究，其中，文獻[3]利用內(nèi)嵌框架(iframe)實現(xiàn)客戶端通信。這種方法的缺點是不但很難保證消息的完整性，而且攻擊者很容易進行框架釣魚攻擊。文獻[4]提出了一種跨域通信方案，兼容主流瀏覽器。聚合應(yīng)用能與一個或多個網(wǎng)絡(luò)服務(wù)應(yīng)用交互，交互過程包括2個階段：設(shè)置階段(建立中間幀，非信任幀，傳輸JS通信對象)與數(shù)據(jù)交換階段。文獻[5]提出了一種基于值的跨域通信機制，對象序列化后進行傳輸。其中，分批處理數(shù)據(jù)減少了整合者與小部件之間信息交換次數(shù)，由此提升了系統(tǒng)性能。美中不足的是，如何解決跨域通信帶來的安全問題以及如何共享JS對象還有待進一步研究。本文在研究相關(guān)工作的基礎(chǔ)上提出了一種適合于聚合應(yīng)用的安全跨域通信(SCDC，securecross-domaincommunication)系統(tǒng)。首先，從各個不同的域入手，同一信任域的內(nèi)容封裝為組件表示，建立聚合應(yīng)用的安全組件；其次，利用分層通信棧實現(xiàn)域間通信，即聚合應(yīng)用與組件間通信；最后，利用封裝技術(shù)安全實現(xiàn)組件間細粒度對象共享。該方案具有安全可靠性強、效率高、支持對象共享的特點，旨在為聚合應(yīng)用提供一種安全可靠的跨域通信系統(tǒng)。

2相關(guān)跨域通信方案

跨域，簡單的理解就是在JS同源策略的限制，域名下的JS無法操作或是域名下的對象?？缬蛲ㄐ琶媾R著許多挑戰(zhàn)，下面分別介紹3種傳統(tǒng)處理跨域的方案：服務(wù)器端、動態(tài)創(chuàng)建腳本、段標識通信?？缬蛘埱蟀l(fā)送至本地服務(wù)器端，然后由服務(wù)器端請求相應(yīng)的數(shù)據(jù)發(fā)送到瀏覽器端。在服務(wù)器端的幫助下，瀏覽器端所有請求發(fā)送至同一域，實現(xiàn)了跨域通信。此方案適用于幾乎所有的跨域訪問，支持各種類型格式的數(shù)據(jù)，但是經(jīng)過了中間，延遲高、開發(fā)工作量大，并且加重了本域服務(wù)器的負荷。至于動態(tài)創(chuàng)建腳本方案，雖然瀏覽器禁止跨域訪問，但仍可以引用其他域的JS文件，由此能夠通過創(chuàng)建script節(jié)點完全實現(xiàn)跨域通信。該方案實現(xiàn)非常簡單，但返回的數(shù)據(jù)格式只能是JSON數(shù)據(jù)，對于其他格式的數(shù)據(jù)無能為力。最常見的跨域通信解決方案是利用URL段標識符(fragmentidentifier)[6]交換信息，傳輸?shù)臄?shù)據(jù)一旦超過瀏覽器對URL長度的限制則必須對數(shù)據(jù)進行分段傳輸。這種方法的優(yōu)勢在于同一頁面瀏覽不同分段時不必刷新整個頁面。不足之處在于不同瀏覽器URL長度限制有所不同，數(shù)據(jù)容量都是有限的。數(shù)據(jù)直接暴露在URL中，一些瀏覽器會刪除段標識符，不能保證應(yīng)用程序的一致性與可靠性。面對復(fù)雜的聚合應(yīng)用環(huán)境，以上這些方案或多或少存在下列問題：首先是開銷問題，服務(wù)器方案經(jīng)過了中間，開發(fā)工作量大，因此并不適合于大規(guī)模的Mashup應(yīng)用；其次是靈敏度問題，段標識通信機制中數(shù)據(jù)容量都是有限的，消息一旦超過當前瀏覽器最大傳輸限制則必須分段進行傳輸。在動態(tài)的Mashup網(wǎng)絡(luò)環(huán)境下，通過輪詢URL探測分段是否變化，響應(yīng)時間往往不確定，會有一定的延遲；最后一個問題是安全性，無論是動態(tài)創(chuàng)建腳本還是段標識通信，消息內(nèi)容或者不安全或者不是預(yù)期的。Mashup應(yīng)用的通信環(huán)境往往是不完全受信任的環(huán)境，如不采取特別的安全防范措施容易導(dǎo)致惡意攻擊或私有信息泄漏。隨著瀏覽器跨域通信的需求越來越強烈，HTML標準的下一個版本HTML5新增了跨域通信功能，即提出了跨文檔通信(crossdocumentcom-munication)機制。在希望發(fā)送消息的窗口或內(nèi)嵌框架中調(diào)用postMessage方法，接收方設(shè)置一個事件處理函數(shù)來接收發(fā)送過來的消息[7]。為了解決上述問題，本文先將不同源網(wǎng)站視為獨立的信任域，并封裝為可相互直接交互的內(nèi)部組件，利用HTML5新增的跨文檔通信機制，實現(xiàn)組件間的通信。這種方案主要有如下優(yōu)勢：①安全系數(shù)高，該方案適用于不完全受信任的環(huán)境，開發(fā)人員可以選擇性接收來自域的消息，如果消息的內(nèi)容不安全或者不是預(yù)期的，則可以放棄相應(yīng)的消息；②可靠性強，與其他跨域通信方案不同，此方案以一致的方式處理未丟棄的消息；③性能提升，此方案允許雙向通信，具有安全、簡單、快速的特點，不依賴于幀或其他頁面，也不需要輪詢URL查找數(shù)據(jù)。

3SCDC系統(tǒng)設(shè)計與實現(xiàn)

3.1系統(tǒng)概況

本文系統(tǒng)為聚合應(yīng)用及其各個組件(component)實現(xiàn)了SCDM系統(tǒng)的JS庫，解決了跨域通信與域間對象共享的難題。SCDM系統(tǒng)把不同信任域的內(nèi)容封裝到不同組件，且每個組件有其輸入輸出端口，為組件通信提供了接口；事件中心維護系統(tǒng)通信，通過建立分層通信棧來實現(xiàn)組件間的通信，跨域通信依賴于跨文檔通信機制；對象共享是聚合應(yīng)用域間通信的高級應(yīng)用。系統(tǒng)支持多個較新版本的瀏覽器，InternetExplorer8.0+(IE8.0及以上版本)，F(xiàn)irefox3.1+，Safari4.0+，Opera9.5+，GoogleChrome1.0+。對于不同的瀏覽器，實現(xiàn)代碼大體上類似。圖2以2個組件之間的通信為例說明系統(tǒng)的整體框架，多個組件之間通信時架構(gòu)與此類似。SCDC系統(tǒng)包含3個主要模塊：域封裝模塊、域間通信模塊、細粒度對象共享模塊。域封裝模塊是系統(tǒng)的入口和核心。聚合應(yīng)用由不同源(域)的內(nèi)容組成。鑒于安全性考慮，不同信任域的內(nèi)容封裝到不同組件中以起到域間隔離的作用，并且組件的輸入輸出端口為域間通信模塊提供接口。域間通信模塊為組件模塊和對象共享模塊提供服務(wù)。判別通信雙方是否處于同一個域，完成域間通信識別的任務(wù)，并且為不同域之間通信搭起橋梁，完成系統(tǒng)跨域通信的任務(wù)。細粒度對象共享模塊是系統(tǒng)的高級應(yīng)用模塊。目前組件間并不能直接跨域共享對象，但是借助基于值傳輸?shù)目缥臋n通信機制能在對象序列化為字符串后能進行對象的共享。為了更好地安全地實現(xiàn)信息共享，本模塊根據(jù)域封裝模塊所提供的組件，及域間通信模塊提供的服務(wù)獲取通信狀態(tài)，實現(xiàn)組件間細粒度的對象共享。細粒度對象共享的過程是先建立封裝對象，并且由策略系統(tǒng)明確定義策略以控制對象共享，然后對象序列化后通過域間通信模塊進行傳輸。

3.2域封裝模塊

信任域(trustdomain)[8]可認為是處于聚合應(yīng)用完全控制下的安全域(域指的是DNS域或IP地址)。信任域與DNS域有著密切聯(lián)系，前者在后者的基礎(chǔ)上加入了安全防范措施。組件可以定義為同一信任域內(nèi)容的封裝。組件源由第三方提供，每個組件邏輯上相互獨立。組件擁有獨特的輸入端口和輸出端口，為后面的異步傳輸消息墊定基礎(chǔ)。為了安全性考慮，系統(tǒng)需要隔離各個組件以防止惡意攻擊。解決方法是將不同的組件置入不同的內(nèi)嵌框架iframe中以達到隔離目的，任意組件不能改變domain屬性以攻擊其他組件。對于上例，Housingmap聚合應(yīng)用模型組合了來自www.map-的電子地圖與www.housing-的租房信息，分別把這2個來自不同信任域的內(nèi)容封裝為電子地圖組件與租房信息組件。然后，電子地圖組件與租房信息組件分別置入各自的iframe起到域間隔離的作用。對于來自同一服務(wù)器的數(shù)據(jù)，但屬于不同信任域，也可以建立多重DNS域從而保證組件間隔離。例如，對于來自服務(wù)器www.map-與信任域為t1、t2的數(shù)據(jù)，能夠建立2個DNS域t1.map-和t2.map-，分別封裝到不同的組件，為下文的域間通信打下基礎(chǔ)。

3.3域間通信模塊

域間通信模塊負責(zé)各個信任域之間的通信。該模塊借鑒與結(jié)合了瀏覽器安全模型的實現(xiàn)方法，在組件端口與事件通道之間通過發(fā)送/接收消息方式實現(xiàn)聚合應(yīng)用與組件間的內(nèi)容交互。事件中心(eventhub)由仲裁域間通信的事件通道(channel)組成，是維護系統(tǒng)通信的核心部件。事件中心實際上是在多對多通道上發(fā)送與接收消息的pub/sub系統(tǒng)，但又不同于傳統(tǒng)的pub/sub系統(tǒng)。事件中心管理連接組件端口與事件通道之間的通信，組件端口與事件通道的命名空間相互隔離，由此避免了組件端口的沖突，提高了組件的重用性。組件有其輸入端口(讀端口)與輸出端口(寫端口)，從組件的輸出端口發(fā)送消息到與之相連的事件通道上；組件的輸入端口從與之相連的事件通道接收消息，由此構(gòu)成了組件與聚合應(yīng)用，以及組件與組件之間的通信。如圖3所示，組件1發(fā)送消息到事件通道1、3，組件1從事件通道3接收到消息。在一般情況下，組件可發(fā)送消息到多個事件通道，同時也可從多個事件通道接收消息。如何保證組件之間通信順暢，文獻[8]中采用的方法是借助于URL段標識符實現(xiàn)域間通信。消息一旦超過當前瀏覽器最大傳輸限制則必須分段進行傳輸，直到上一分段讀取完畢后才能讀取下一個分段。圖3簡化通信本文的解決思路是通過跨文檔通信機制實現(xiàn)聚合應(yīng)用與組件的域間通信。對于聚合應(yīng)用，組件在域封裝模塊已置入iframe幀中，以組件幀表示。而且每個組件均包括隱藏的通道幀，通道幀與聚合應(yīng)用主頁面()屬于同一個域，因此通道幀與聚合應(yīng)用主頁面實現(xiàn)域內(nèi)同步通信。而通道幀與組件幀通過跨文檔通信機制實現(xiàn)域間通信。具體實現(xiàn)架構(gòu)利用JS庫底層實現(xiàn)聚合應(yīng)用與組件的域間通信，實現(xiàn)架構(gòu)類似分層通信棧，由事件中心層、事件通信層及跨文檔通信層3部分組成，在組件及聚合應(yīng)用中的同等層使用較低層進行通信。如圖4所示，事件中心層管理組件端口與事件通道，對于聚合應(yīng)用，事件中心層的主要任務(wù)是裝載組件與卸載組件，建立事件通道與刪除事件通道，連接組件端口與事件通道等；對于組件，這一層負責(zé)處理該組件各端口發(fā)送與接收的事件。事件通信層負責(zé)多路傳送多個組件端口的消息?？缥臋n通信層是為聚合應(yīng)用與組件實現(xiàn)跨域通信，也就是通道幀與組件幀的通信過程。下面列出實現(xiàn)域間通信的常用API，如表1所示，重點描述下組件狀態(tài)的生命周期，參照getComponentState函數(shù)。從loaded到wired狀態(tài)轉(zhuǎn)換由聚合應(yīng)用控制，意味著組件能夠開始發(fā)送消息；從wired到startedCleanup狀態(tài)也是由聚合應(yīng)用所控制，意味著開始卸載組件；而從startedCleanup到doneCleanup狀態(tài)則是由于超時或組件處理不當引發(fā)的，這個過程由組件所控制；剩下的狀態(tài)轉(zhuǎn)換則是由系統(tǒng)自身初始化的。為了避免輪詢組件狀態(tài)，在組件及聚合應(yīng)用狀態(tài)轉(zhuǎn)換時注冊監(jiān)聽函數(shù)。組件與聚合應(yīng)用都通過發(fā)送與接收消息方式進行通信。用一個簡單的例子描述利用分層通信棧的通信過程。首先，聚合應(yīng)用主頁面中裝載2個組件，初始化通信，發(fā)送消息message給組件，主要調(diào)用如下API：

3.4細粒度對象共享模塊

Web主體間共享資源通常有2種處理方案：共享所有資源，或者相互隔離，實現(xiàn)零共享[9]。通常各個主體共享所有資源容易導(dǎo)致跨站腳本攻擊(XSS)，由此研究人員提出了多種方法來隔離各個主體。進一步，如何在各個隔離的主體間共享部分對象，針對這個問題，提出了細粒度共享對象策略。首先，利用SCDC系統(tǒng)的JS庫中對象封裝策略，建立與原對象一致的、可控制的封裝對象view[10]。一致性表示封裝對象view可以取代原對象進行訪問；可控制性意味著可以定義策略限制接收方訪問共享對象的某些屬性或方法。其次，建立細粒度策略(基于通知的策略)約束訪問共享對象。細粒度策略由方面系統(tǒng)(aspectsystem)實現(xiàn)，能控制對象的行為。如圖5所示，為對象map建立封裝對象map_control.view來取代原對象的訪問，并通過為原對象的屬性與方法引入getters、setters、caller訪問器利用map_control.definePolicy設(shè)置策略以控制訪問封裝對象view。view可以看作是與策略的組合體，相當于一個封裝器，策略即為一個函數(shù)。為每個不同的對象建立一個新的封裝對象。同樣地，對于一個函數(shù)對象，相應(yīng)地定義一個新的封裝函數(shù)以取代對原函數(shù)的訪問，并為其定義策略函數(shù)。如圖5所示，電子地圖組件與租房信息組件共享某一對象，如地圖類型(包括普通地圖、衛(wèi)星地圖、地形地圖等類型)。首先，電子地圖組件建立其封裝對象view(map_control.view)以代替原對象。然后通過定義策略控制對封裝對象的訪問，如定義策略即編碼白名單，租房信息組件只能讀其屬性Type，調(diào)用方法getType，但不能重定義方法或?qū)傩?，也不能操作電子地圖組件的其他對象。建立封裝對象view后，怎樣實現(xiàn)組件間view對象的共享。針對這一問題，瀏覽器并未為跨域傳送消息設(shè)定特定的事件通道，但能夠借助于跨文檔通信機制與分層通信棧結(jié)構(gòu)，對象能夠序列化后實現(xiàn)共享傳輸。如圖6所示，組件1與組件2共享封裝對象時，利用SCDC的JS庫發(fā)送方序列化對象后通過分層通信棧發(fā)送給對方；接收方收到消息后把字符串反序列化為對象。由此，當租房信息組件要請求map_control.view的屬性Type時，首先發(fā)送請求給電子地圖組件，依據(jù)view策略得到結(jié)果，然后返回給租房信息組件。圖6封裝對象view共享過程示例細粒度對象共享一定程度上解決了對象傳輸?shù)陌踩裕瑫r也引入了一些新的問題，如異步問題。1)封送處理庫負責(zé)序列化與反序列化對象，并對基本的JS操作如調(diào)用函數(shù)、讀寫屬性、拋出異常等進行譯碼。如果組件1遠程共享一個表格對象table給組件2，組件2請求封送處理庫獲取table.parentNode.parentNode.parentNode.cookie的值，這將泄露了文檔的cookie值；如果組件1遠程共享其封裝對象table_control.view，view能執(zhí)行策略代碼僅能訪問table對象的白名單屬性或方法。封裝對象機制限制訪問對象，解決了遠程對象共享帶來的部分安全問題。2)瀏覽器的同源策略規(guī)定每個框架有獨自的類型鏈與全局對象集合，一定程度上確保了框架間的隔離。由于聚合應(yīng)用需要跨域訪問對象，同源策略受到限制。SCDC系統(tǒng)的細粒度對象共享模塊在訪問對象之前進行檢查，以確認是發(fā)送方對象的封裝對象view或接收方對象的。如果get、set、call等觸發(fā)某個對象既不是veiw也不是，則拒絕此對象，進一步保證對象傳輸?shù)陌踩浴?)由于跨文檔通信機制本身的異步性，通過分層通信棧實現(xiàn)的遠程對象共享引入了異步問題。如圖7所示，圖7(a)中轉(zhuǎn)化為遠程對象的封裝對象view，調(diào)用2個“.”則是異步調(diào)用。這就需要轉(zhuǎn)化代碼結(jié)構(gòu)，調(diào)用者必須提供一個回調(diào)函數(shù)以保持傳輸?shù)耐暾耘c連續(xù)性，這就是連續(xù)傳遞模式(CPS，continuationpassingstyle)。如圖7(c)所示，客戶端自動全局轉(zhuǎn)化為CPS形式進行交互，在調(diào)用y()與z()時，為了保持連續(xù)性注冊回調(diào)函數(shù)以控制當前線程。

4安全策略

4.1SCDC系統(tǒng)整體安全策略

上文已經(jīng)提到組件隔離及組件間通信，至于哪些組件之間可以交互，哪些組件之間禁止交互，則由SCDC系統(tǒng)的安全策略所定義。具體的策略來自多種高級策略，例如企業(yè)級聚合應(yīng)用，安全策略則可能是企業(yè)級策略、部門策略、終端用戶策略的組合。一方面，組件提供方明確它們的組件怎樣整合到聚合應(yīng)用中；另一方面，聚合應(yīng)用提供方可能不同等看待各個組件，可能會阻止部分組件相互交互?？傊?，安全策略依賴于具體的實體應(yīng)用程序，包括組件間訪問控制策略與組件到服務(wù)器端的訪問控制策略。組件間訪問控制策略包括建立與刪除組件、建立與刪除事件通道、哪個組件能在某個事件通道上發(fā)送或接收事件等。事件中心負責(zé)執(zhí)行策略，一種方式可以在聚合應(yīng)用的代碼中明確定義策略；另一種方式為事件中心定義一個配置策略文件，可以從中讀取安全策略，這樣分離了策略定義與聚合應(yīng)用中真正的代碼實現(xiàn)。組件到服務(wù)器端的訪問控制策略包括認證組件與受限訪問權(quán)限。在組件裝載之前，必須先核實認證，并且根據(jù)組件所在域確保組件裝載到合適的iframe幀中，使其不易受到人為攻擊。這種方式不管是客戶端聚合應(yīng)用還是服務(wù)器端聚合應(yīng)用都有統(tǒng)一的訪問控制策略。上述定義了SCDC系統(tǒng)的整體安全策略，但是跨域通信容易導(dǎo)致框架釣魚攻擊，共享信息容易泄露個人隱私信息，針對這2個問題本文特別加入了針對性的安全策略。

4.2防范框架釣魚攻擊

框架釣魚攻擊，對于利用iframe來隔離不同信任內(nèi)容的網(wǎng)站來說是很常見的漏洞，也是比較嚴重的攻擊類型[11]。它一定程度上破壞了應(yīng)用程序的完整性，但并不意味著應(yīng)用程序被惡意組件所控制。框架釣魚攻擊還能竊取輸入的信息，包括個人認證信息或密碼等。在聚合應(yīng)用中，這種攻擊不僅能改變組件幀的location屬性，也能作用于事件通道幀與聚合應(yīng)用主頁面之上。對于聚合應(yīng)用，組件、事件通道、聚合應(yīng)用主頁面三者易發(fā)生框架釣魚攻擊。由于URL欄僅能提供微弱的釣魚保護能力，而且不像傳統(tǒng)的釣魚攻擊，聚合應(yīng)用中框架釣魚攻擊的時機是任意的。本文在各個頁面中利用onunload事件處理器，超時設(shè)置及通道幀三者相結(jié)合共同防范框架釣魚攻擊。首先，當組件受到攻擊時觸發(fā)onunload事件并發(fā)送通知消息給聚合應(yīng)用，然而組件與聚合應(yīng)用通過事件通道進行異步通信，不能保證在組件卸載完之前通知消息傳送完畢。換個角度考慮，替換某個組件時將會觸發(fā)通道幀的onunload事件，通過調(diào)用JS函數(shù)通道幀與聚合應(yīng)用實現(xiàn)同步通信，因此在onunload事件完成之前必能成功通知聚合應(yīng)用。根據(jù)上述分析得知，可以用統(tǒng)一的方法來處理針對組件與事件通道的攻擊。其次，另一種可能的情況是在通道幀裝載完畢之前取代組件，這時在聚合應(yīng)用中設(shè)置一個超時處理成功初始化事件通道通信。一旦超時，觸發(fā)錯誤處理程序以決定是卸載或重載組件。利用事件通道的onunload事件處理程序面臨一個挑戰(zhàn)，當用戶操作離開聚合應(yīng)用頁面時，該事件也被觸發(fā)。為了避免錯誤判斷，可以延遲計時器的警告時間，如果用戶仍停留在聚合應(yīng)用中，超時則通知聚合應(yīng)用存在潛在的框架釣魚攻擊。最后，檢測聚合應(yīng)用主頁面的框架釣魚攻擊。有時很難區(qū)分是框架釣魚攻擊還是用戶任意操作離開這個網(wǎng)頁。針對這個問題，設(shè)計一個警告框來通知用戶URL的變化，沒有瀏覽器的支持很難區(qū)分上述2種情形。雖然這種方法對系統(tǒng)性能有一定的影響，但是這是唯一一種確保用戶安全性的方法。

4.3對象共享安全性

隨著計算系統(tǒng)的不斷發(fā)展，資源共享變得越來越重要，而由此導(dǎo)致的安全問題也變得不容忽視。SCDC系統(tǒng)的對象共享模塊容易泄露私有信息，所以做好安全防范工作顯得尤為重要[12]。為了保證私有信息不被泄露，遞歸封裝對象是理想的選擇。遞歸封裝即為某個對象的所有屬性（包括繼承的屬性）及返回值定義訪問器或函數(shù)，并且建立封裝對象須遵循引用一致性策略。引用一致性指以對象ID為索引存儲一個原對象與封裝對象的關(guān)聯(lián)表，如果請求的對象不在表中則生成一個新的封裝對象，否則返回同一個對象以保持引用對象的一致性。同時，雙重的輸入輸出封裝構(gòu)筑另一道安全屏障。除了不允許原對象引用泄漏(exporting)外，同時不允許不受信任的代碼進入(importing)訪問。輸入封裝是為第三方對象(參數(shù)和重定義的屬性)設(shè)計的，即當一個封裝對象的某個方法接收參數(shù)或某個屬性重賦值時都必須進行輸入封裝。下面舉個實例說明怎樣保證對象共享安全性，例如定義對象obj，包含一個屬性prop與一種方法proc，其中方法proc可讀寫，屬性prop則不可讀寫。

5實驗

實驗平臺：全部實驗在頻率為1.5GHz的IntelCeleronM的處理器，512MB內(nèi)存的機器上實現(xiàn)的，所用的操作系統(tǒng)是WindowsXP，采用服務(wù)器ApacheTomcat5.5發(fā)送數(shù)據(jù)到瀏覽器(InternetEx-plorer8.0，F(xiàn)irefox3.6.3，Safari4.0.5，Opera10.54，GoogleChrome6.0.401.1)。服務(wù)器端需要修改服務(wù)器，對服務(wù)器不透明；動態(tài)創(chuàng)建script節(jié)點，需要引用其他域的JS文件且支持的數(shù)據(jù)格式有限；而段標識通信機制是傳統(tǒng)跨域通信方案中最常見的通信方案，應(yīng)用廣泛，對服務(wù)器透明且不需引入其他JS文件等，可比性強，所以本文選擇采用段標識跨域通信機制的系統(tǒng)(FIC系統(tǒng))與本文系統(tǒng)進行測試，對比了兩者在數(shù)據(jù)吞吐率(datathroughput)和事件發(fā)生率(eventrate)以及組件裝載延遲(componentloadlatency)3方面的實驗數(shù)據(jù)，同時還測試比較了SCDC系統(tǒng)支持對象共享前后的JS執(zhí)行時間開銷。

5.1數(shù)據(jù)吞吐率

組件數(shù)從1、2遞增到32個，輪詢時間間隔取10ms、20ms、40ms、80ms不等，測試數(shù)據(jù)吞吐率(橫縱坐標為對數(shù)刻度)。開始從聚合應(yīng)用傳輸4KB，8KB等小數(shù)據(jù)量到各個組件中，耗時非常短。然后傳送1MB的數(shù)據(jù)，對比系統(tǒng)所用的時間。所有的實驗數(shù)據(jù)都是測驗5次后取平均值得到的，減少了隨機因素的影響。實驗結(jié)果表明隨著組件數(shù)目的增加，SCDC系統(tǒng)的吞吐率隨之增長，只是組件數(shù)越大，吞吐率增長幅度越小些。由于篇幅限制，在此只給出Firefox、GoogleChrome2個常用瀏覽器的測試結(jié)果，如圖8(a)和圖8(b)所示。同時對比SCDC系統(tǒng)與FIC系統(tǒng)，比較圖8(a)與圖8(c)，實驗結(jié)果顯示SCDC系統(tǒng)比FIC系統(tǒng)的吞吐率高出5倍之多。主要原因在于FIC系統(tǒng)受到瀏覽器URL長度的限制，當傳輸數(shù)據(jù)量比較大時，則要分段進行傳輸，而SCDC系統(tǒng)則無此限制，由此數(shù)據(jù)吞吐率明顯提高。

5.2事件發(fā)生率

事件發(fā)生率，衡量對于小事件，系統(tǒng)所能支持的最大事件率。對于許多聚合應(yīng)用來說，組件之間需要交換小事件以響應(yīng)用戶行為。事件發(fā)生率系統(tǒng)傳輸15個字符的小負載(簡單的名/值對)進行測試事件發(fā)生率。測試結(jié)果如圖9(a)和圖9(b)所示，對于各個瀏覽器，存在一定的差異，隨著組件的數(shù)量，輪詢時間間隔的變化，事件發(fā)生率呈現(xiàn)上升的增長趨勢，主要緣于跨文檔通信機制是異步傳輸?shù)臋C制。同時對比SCDC系統(tǒng)與FIC系統(tǒng)，實驗結(jié)果顯示，SCDC系統(tǒng)的事件發(fā)生率比FIC系統(tǒng)提高了5倍左右，如圖9(a)和圖9(c)所示。事件發(fā)生率系統(tǒng)傳輸1MB的大負載進行測試事件發(fā)生率。大負載測試結(jié)果如圖10所示，比較圖9(a)與圖10，可以發(fā)現(xiàn)與小負載測試結(jié)果相似。由此可知，事件發(fā)生率與負載的大小無關(guān)。

6結(jié)束語

聚合應(yīng)用組合了來自不同源的信息，由此信息的交互就成為一個瓶頸。本文在分析比較傳統(tǒng)跨域通信方案優(yōu)缺點的基礎(chǔ)上，利用HTML5新增特性跨文檔通信機制以及借助于分層通信棧結(jié)構(gòu)實現(xiàn)了適合聚合應(yīng)用的安全跨域通信系統(tǒng)；并且在系統(tǒng)中引入了細粒度的對象共享，通過封裝對象及定義策略來約束控制對象，以代替對原對象的訪問。同時，跨域通信與對象共享導(dǎo)致的安全問題也不容忽視，相應(yīng)地增加了針對性的安全防范措施。通過一系列實驗及對其結(jié)果進行比較分析可知，運用該SCDC系統(tǒng)的聚合應(yīng)用程序，性能有了大幅度的提升，事件發(fā)生率、吞吐率明顯較之前的通信方案提高了5倍以上；減少了組件裝載延遲時間；同時，對象共享也僅引入很小的開銷。今后的研究工作包括在聚合應(yīng)用環(huán)境下進一步完善跨域通信系統(tǒng)的安全性，研究更全面的安全措施。同時在對象共享方面有所突破，使得所有瀏覽器本身支持細粒度對象共享。