打造安全 Ajax mashup 的未來

當前的 網頁瀏覽器設計不能輕鬆而安全地從多個源擷取內容並將其顯示到頁面上。瞭解開發人員如何充分利用可用的工具來完成該任務，以及使用這些工具給所得應用程式帶來的安全和延展性方面的壓力。另外，學習提出的幾種用於補救此情形的瀏覽器改進，以及如何參與相關討論，使 Web 開發超越這一障礙，使互通性達到的一個新水平。

與 Ajax 混合

mashup 是一個 Web 應用程式，它整合了來自多個源的內容並將其交付到一個頁面中進行顯示。伺服器向每個內容來源發出請求，解析收到的資訊，並將結果綜合到一個頁面中發給瀏覽器，如 圖 1 所示。

圖 1. 混合來自多個源的內容

Asynchronous JavaScript + XML（Ajax）應用程式 使 Web 頁面能從伺服器擷取內容並使用 JavaScript 代碼非同步地在適當位置進行自我更新，如 圖 2 所示。這樣，使用者就可以與富使用者介面 (UI) 進行互動而無需重新載入整個頁面。伺服器向瀏覽器發送初始頁面，後者回調伺服器以擷取更新後的內容。非同步 JavaScript 代碼調用頻繁使用 XML 來編碼資料；但是，其他的資料格式則更通用，如 JavaScript Object Notation (JSON)、HTML 和分隔文本。

圖 2. 使用 Ajax 的互動式資料顯示

Ajax mashup 是一種混合的 Web 應用程式。它使用 Ajax 技術來顯示富 UI，此類富 UI 使用從多個源非同步檢索到的內容在適當位置進行自我更新。伺服器向瀏覽器發送初始頁面，後者發出調用以檢索更新後的內容。這些調用可從瀏覽器直接發往第三方源或者發回初始伺服器，初始伺服器用作第三方內容的代理。

回頁首

格格不入

當設計包含當前瀏覽器環境的元素時，沒有人注意到 Ajax mashup。瀏覽器、超文字傳輸通訊協定 (HTTP)（HTTP）或 HTML 或專門設計用於容納瀏覽器的（以一種安全而健壯的方式）非同步檢索多個源中內容的功能的 XHTML 都沒有內建任何組件。World Wide Web Consortium (W3C) HTTP 規範中的一些可能用於 mashup 的一些特性（如 Document Object Model (DOM) Level 3 Load 和 Save Specification）並未由大多數瀏覽器完全實現，或是根本沒有實現。

Dynamic HTML (DHTML) 開始時不與動態檢索到的內容結合使用。動態 Web 頁面的顯示和資料元素都與操作它們的指令碼一起交付。這些指令碼將顯示、隱藏、移動、建立和銷毀文檔對象以便實現動態效果，但是一旦需要從伺服器擷取更多資料，原頁面就被新頁面取代。資料流與頁面重新載入同步。

因此，希望構建交互式 Web 應用程式 (Mashup)（現在稱為 mashup）的開發人員必須利用可用的技術設法對其進行擴充以滿足他們的需求。有兩種方法可使瀏覽器在無需重新載入頁面的情況下檢索內容：嵌入外部傳輸機制和使用瀏覽器本機物件執行傳輸任務。

外部協助

早期的解決方案是 Microsoft 的 Remote Scripting，它使用一個 Java applet 與伺服器端組件交換 XML 格式的訊息。此方法很快就因為供應商的爭論以及 Java Virtual Machine (JVM) 和安全模型的差異而變得不實用。

Microsoft 稍後構建了 XMLHttpRequest (XHR) 對象，其設計者的預想是只能通過 Microsoft Outlook Web Access (OWA) 來使用該對象。該對象最初只能由 Windows Internet Explorer 使用者使用，直到多年後 Mozilla 和 Safari 採用它時，才得到廣泛使用。它最初是一個外部的 Microsoft ActiveX 對象，而當前的實現則是瀏覽器內的本機物件。雖然其名稱為 XHR，但是 XHR 對象卻可以傳輸任意格式的資料而非僅限於有效 XML 格式資料。

很多開發人員使用 Macromedia Flash 的 XML 通訊特性來構建可嵌入的組件與伺服器進行通訊。XMLSocket 和 flex.net.socket 對象提供了類似 XHR 的功能，但附帶了額外的通訊控制和 XML 解析功能。

內部工作

由於外部傳輸機制相關的問題和依賴性，互連網開發團體協作發現並開發了幾個瀏覽器本地的遠程調用方法。

• 使用一個隱藏的 iframe 元素來載入外部內容：然後通過 DOM 訪問 iframe，提取載入文檔中的內容。您可指定 URL querystring 中的任何參數或動態建立一個表單，此表單以 iframe 為目標提交到服務。此方法與很大範圍內的當前的和舊式瀏覽器安全色。
• 使用 img 元素髮送內容請求：伺服器使用 URL 的 querystring 中的參數執行其任務，然後在 cookie 中返回編碼後的內容。此方法僅限於可輕鬆通訊數量的資料使用，因為 querystring 和 cookie 都有大小限制。
• 在當前頁面的 DOM 中動態建立指令碼元素：載入後，立即執行伺服器所提供的代碼。伺服器使用 URL querystring 中的參數。

請參閱 參考資料 中關於這些工具和技術的詳細資料的連結。

回頁首

突破界限

大多數可用於非同步檢索內容的技術都繼承了 JavaScript 安全模型的安全性，它使指令碼只與源於該指令碼所屬頁面所在的同一伺服器的元素進行互動。這就是所有瀏覽器都實現了的同源策略（Same Origin Policy）。

要讓 Web 頁面從第三方檢索內容，必須避開同源策略。常用的不受同源策略限制的例外是 <script> 標記技術，由此向頁面的 DOM 追加 <script> 元素，致使其載入並運行元素的 src 屬性所指定的 URL 處發現的代碼。

使用 <script> 標記運行來自多個網站的指令碼以所有相關網站間的高水平信任為前提，因為所有此類指令碼都在相同的執行和安全上下文中運行，因此可能獲得其他網站的資訊和 cookie 的訪問權。

回頁首

安全或延展性：不可兼得

當前廣泛用於啟用 Ajax mashup 的工作區都會產生一些代價。當擴充瀏覽器的設計限制時，就會影響應用程式總體操作的其他方面。這種做法通常會導致應用程式的安全性或延展性降低。

安全，但是否可伸縮？

當受到瀏覽器的同源策略限制時，承載應用程式的伺服器必須承擔擷取第三方內容並將其發送到客戶機的任務。伺服器除提供常規的伺服器功能外，還擔當第三方服務的客戶機的角色。

使用伺服器作為每個客戶機事務的代理意味著大量使用者可能導致過度的伺服器負載。使用此技術的應用程式需要設計成伺服器端可伸縮，使用多個同等的伺服器處理請求負載。

可伸縮，但是否安全？

使用 <script> 標記避開同源策略使客戶機能檢索來自第三方的內容。 此功能消除了伺服器的延展性瓶頸，因為每個額外的客戶機都承擔了自身的內容收集任務。

<script> 標記的延展性優點的獲得以避開同源策略安全性模型為代價，可能導致易於收到攻擊：

• 跨網站 cookie 訪問成為可能：一個網站的指令碼可訪問另一個網站的 cookie。
• 在運行檢索到的代碼之前不能檢查其安全問題：代碼載入後立即運行。

回頁首

可能的解決方案

很明顯，瀏覽器當前提供的用於 mashup 的工具不能構建同時具有延展性和安全性的應用程式。開發人員必須找到從當前和長遠角度來看都有效解決方案。

此時此地

一種最近開發的內容檢索技術通過其 src URL 的片段標識符（URL 中 # 符號後的部分）使用了頁面指令碼和隱藏的 iframe 之間的通訊。父頁面中的指令碼和嵌入的 iframe 可設定彼此的片段標識符，儘管它們來自不同的起源。指令碼之間保持一種一致的通訊協定，由 JavaScript 計時器驅動，該計時器定期地啟用常式以檢查片段標識符中的更改。

由於指令碼必須瞭解彼此的地址並且它們自身之間必須協作以取得對協議的一致遵守，因此要確保信任。由於任何伺服器互動都在每個組件本地並且與指令碼間通訊分離，因此不會暴露 cookie。

雖然仍不完美（例如，它依賴於設計行為以外的異常，並且查詢更改不如用事件啟用來響應更改），但是這個解決方案比任何其他方案都更接近於提供瀏覽器本地的、安全的、頁面中的跨域通訊。

請注意：James Burke 是 AOL Developer Network 的一名開發人員，他開創了片段標識符技術並將其構建到最新版本的 Dojo Toolkit JavaScript 庫中。

長期

瀏覽器製造商和開發團體當前正在討論幾種可能的修改瀏覽器環境元素的方法，使其以 Ajax mashup 為構建目標。Web Hypertext Application Technology Working Group (WHATWG) 在其用於 Cross Document Messaging 機制的 Web Applications 1.0 Working Draft 的 7.3 節中提出了一個建議。Opera 瀏覽器已經實現了此特性。它指定了不同域中的 DOM 對象之間協作通訊的方法，該方法允許訊息的接收方根據訊息的起源來選擇所要響應的訊息。

Ian Hickson 以前任職於 Opera，現在任職於 Google。他提出了對現有的 XMLHttpRequest 對象的跨網站擴充。他的提議包括對發出請求的方式（包括前序控制的限制和存取控制機制）的幾個修改。

Douglas Crockford 是任職於 Yahoo! 的一名 JavaScript 傳道者和架構師，他是全球最有造詣的 JavaScript 語言專家之一。您可在他的個人 Web 網站上及通過 Yahoo! Developer Network 找到很多他的解釋進階 JavaScript 技術的展示和文章。Crockford 提出的另一項計劃是 JSON，它是一種 Ajax 應用程式中廣泛使用的資料交換格式，其主要原因是易於被 JavaScript 解析並且不像 XML 那樣冗餘。Crockford 編寫了兩個提議來將 mashup 敏感的元素構建到瀏覽器中。

絕妙提議

幾個絕妙提議可協助您應對此困境：

• JSONRequest 提議：瀏覽器實現一個新對象，其運作方式類似於現有的 XMLHttp 對象，作出了以下幾點修改：
  • JSONRequest 將免除同源策略。
  • 將使用 HTTP 前序的最小設定，減小請求的總體大小。
  • 不傳輸 cookie，確保避免跨網站 cookie 問題。
  • JSONRequest 將只接受有效 JSON 文本，確保不將原始的可執行代碼發送執行。
  • 通訊失敗後，在重試阻止某些攻擊類之前引入隨機延遲。
  • 每個請求都將返回一個序列標識符，使非同步響應能 更容易地與其原始請求相關聯。
  • 對雙向串連的特定支援將使伺服器能通過開放的通訊通道非同步地啟動通訊。
• <module> 標記提議：新的 HTML 標籤將頁面分隔成彼此不受影響但可安全地通訊的模組集合：
  • The <module> 標記將能夠訪問第三方資源，免除同源策略。
  • 頁面和模組間的合作通訊只能通過特定的介面來進行。模組間不能相互連信 —— 只能與頁面通訊。頁面可使模組間的通訊更加方便。
  • 通訊僅限於有效 JSON 文本， 相比之下，與 JavaScript 對象通訊可能因為附帶的代碼導致 安全泄漏。
  • 提出了一些限制用於確保模組和頁面不會干擾彼此的顯示，避免導致安全問題。
• 內容限制題頭： Gervase Markham 提出了內容限制題頭規範， 該規範使作者能表達全部意圖 —— 確定內容與其他網站內容的互動方式。一致的實現將提交包含策略字串的內容限制題頭。
• W3C Access Control List (ACL) System：W3C ACL System 可用作 基於 ACL 的系統的模型，用來管理對 Ajax mashup 中服務 HTTP 的資源的訪問。
• Cross-browser.xml：Flash 對象在伺服器上尋找 cross-browser.xml 檔案，然後才嘗試訪問其特定的 URL。 此檔案指定了哪個網站可承載訪問該伺服器上所提供服務的應用程式。很多 Web 服務提供方已經實現了此檔案。

請參閱 參考資料 中關於這些提議的詳細資料的連結。