HTML5跨域消息發(fā)送安全區(qū)分

HTML5是下一代的Web應用，它具有許多新的特性，是一種新興的技術并且在移動應用中也有著廣泛的使用。但也正是因為它的一些新特性的出現(xiàn)以及廣泛的應用，使得其安全性非常值得關注。

在本文中，我們將針對HTML5 Web消息發(fā)送（跨域消息發(fā)送）的安全性進行分析和研究。

跨域消息發(fā)送

在討論這一問題之前，我們先來了解下在HTML5中是如何實現(xiàn)跨域的消息發(fā)送。

在HTML5之前，由于同源策略的限制導致在兩個窗口之間進行消息傳送必須是使用相同的協(xié)議、端口和主機。

HTML5有一種新的方法叫做postMessage()，通過這一方法，跨域的消息傳送將不再受到同源策略的限制。

以下是postMessage()的語法：

發(fā)送窗口：

Otherwindows：涉及到的其他窗口 Message：被發(fā)送到接收窗口的信息 targetOrigin：接收窗口必須規(guī)定的URL。如果沒有任何特殊偏好，可以將其規(guī)定為“*”定義“*”為targetOrigin，但這樣做其實會存在一些安全隱患，在后文中我會提到。 Transfer：這個是任意的。

接收窗口：

當otherWindow.postMessage()執(zhí)行時，消息將會被發(fā)送到接收窗口。

發(fā)送方使用以下這段代碼后，我們就可以接收到這條消息。

通過該段代碼，我們可以訪問數(shù)據以及這一信息的源。如下所示：

Event.origin：提供信息的源（我們所接收到的信息的URL） Event.data：提供實際所發(fā)送出的信息內容

安全性實例分析

出于演示需要，我設立了如下兩個Lab：

A: http://localhost:8383/ B: http://localhost/

正如你所看到的，上面兩個URL具有不同的端口，第一個運行在8383端口，第二個則是在80端口。正是因為其源不同，所以才導致端口不同。

A是發(fā)送窗口，B是接收窗口

現(xiàn)在我們加載第二個URL（http://localhost/ ）作為第一個URL的iframe：

通過使用postMessage()的方法，我可以輕松的將消息從第一個URL發(fā)送到第二個URL.

我們可以通過點擊”send message“的按鈕來進行驗證。

盡管加載在第一個URL中的iframe與其并不同源，但通過postMessage() 即可進行信息傳遞。

現(xiàn)在我們來看一些postMessage()使用過程中可導致應用出現(xiàn)漏洞的例子：

case1.

發(fā)送方代碼：

當發(fā)送者把targetOrigin規(guī)定為通配符”*“時，將會導致未知的信息被陌生的接收方（窗口）接收到。原因是從接收窗口傳來的消息任何人都可以再加載一個iframe來進行監(jiān)聽。因此在進行敏感數(shù)據的傳輸時，使用通配符是一個十分錯誤的決定。

針對此問題最好的解決方法就是在發(fā)送時添加具體的目標字段，如下所示：

Case2.

接收窗口代碼：

在上面這段代碼中可以看到，我們是直接接收發(fā)送方的消息對其進行處理，并不檢驗是否來自發(fā)送方。

但檢查消息的來源無疑是十分重要的，這樣可以防止消息來自未經授權的發(fā)送者。

因此，我們只需要在代碼中加入對發(fā)送方的驗證，這一問題就可解決了。代碼如下：

通過檢驗event.origin，來進行驗證。

Case3.

在這一過程中，發(fā)送方和接收方都應該驗證正在傳送的.消息。如果數(shù)據插入到HTML DOM中時并沒有進行驗證，那么應用很有可能遭受到基于DOM的跨站腳本攻擊。

由下面這段代碼可以看出，當應用程序接收到攻擊者發(fā)來的惡意信息，并已經插入到HTML DOM使用innerHTML屬性時，其顯得異常脆弱。

發(fā)送方：

接收方：

執(zhí)行上面這段代碼，可導致在接收窗口出現(xiàn)XSS。

解決這一問題最簡單的方法就是在給元素分配數(shù)據值時使用 textContent 而不是innerHTML.

如下所示：

發(fā)送方：

接收方：

執(zhí)行上面這段代碼時我們可以看到，文本中顯示frame是作為數(shù)據而不是代碼。

從上圖我們可以看到，現(xiàn)在它并不執(zhí)行代碼，而是顯示為正常的文本。

[參考來源infosec，譯/Change，轉載請注明來自Freebuf黑客與極客]