摘  要： 提出了一種新的安全解決方案，主要采用frame片段標識符技術在瀏覽器端實現跨域數據通信，在此基礎上主要關注3個安全因素：數據保密、身份驗證和數據完整。該方案不需要對當前的瀏覽器環境進行任何修改就可實現異源內容相互間安全的通信。
關鍵詞： 聚合；安全；同源策略；跨域通訊

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

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

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

3.2 安全分析
    從數據保密、身份驗證和數據完整3個方面來分析上述基于<frame>片段標識符的跨域數據訪問方案的安全性。
    (1)數據保密。利用瀏覽器提供的同源策略限制和frame.src的只寫特性來實現數據保密性。在父頁面和<frame>之間傳送的數據不會被父頁面上其他的DOM元素看到，因為<frame>與父頁面處在不同的源。而且數據不出現在瀏覽器緩存中，數據也不會跨過網絡，因此可以認為數據包只能被接收的<frame>或來自a.com的其它頁面觀察到。
    (2)身份驗證。圖3中利用共享密鑰的技術能保證瀏覽器客戶端跨域通信雙方身份的驗證。frame1只有當其將父頁面傳過來的密鑰SK1再傳回父頁面時，才能讓它的身份得到驗證；類似的，父頁面也只有將密鑰SK2傳回frame1時，才能驗證它的身份。之后，通過利用父頁面和frame1的共享密鑰SK2來保證雙方通信的機密性。
    (3)數據完整。攻擊者篡改過的數據能被檢測出來。要篡改通信的數據，攻擊者需要知道共享密鑰SK2，否則在目的地，傳過來的數據包將被拒絕并被丟棄。因此，沒有經過身份驗證的組件是不能篡改數據的。
    當前所有瀏覽器端所實現的安全模型是同源策略，其導致了異源內容間只能是“完全信任”或“完全不信任”的結果。隨之帶來的問題是：Mashup不能在實現功能性需求的同時也能很好地解決安全問題。因此，需要瀏覽器實現一種新的安全模型，使得瀏覽器能夠支持合法的跨域數據訪問，而無需犧牲終端用戶的安全。但是，主流瀏覽器要實現新的安全模型并在業內普遍使用需要幾年的時間，同時一些研究者提出的解決方案中或者要求改進當前的瀏覽器環境；或者不能提供一個靈活和安全的點到點的域間通信機制[5-6]。本文提出了一種新的域間通信機制，它不需要對當前的瀏覽器環境進行任何修改就可適用，并且主要考慮了3個安全因素：數據保密、身份驗證和數據完整。在不遠的將來，通過不斷改善瀏覽器技術，及增加新的Web標準使Mashup更加安全，Mashup方式也將會得到更廣泛的應用。
參考文獻
[1] 佚名.Garter：IT業界未來四年的十大新技術[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跨域訪問的研究與應用[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.