HTML5跨域消息發(fā)送安全性分析
HTML5是下一代的Web應(yīng)用，它具有許多新的特性，是一種新興的技術(shù)并且在移動應(yīng)用中也有著廣泛的使用。但也正是因為它的一些新特性的出現(xiàn)以及廣泛的應(yīng)用，使得其安全性非常值得關(guān)注。
在本文中，我們將針對HTML5 Web消息發(fā)送(跨域消息發(fā)送)的安全性進行分析和研究。
跨域消息發(fā)送
在討論這一問題之前，我們先來了解下在HTML5中是如何實現(xiàn)跨域的消息發(fā)送。
在HTML5之前，由于同源策略的限制導(dǎo)致在兩個窗口之間進行消息傳送必須是使用相同的協(xié)議、端口和主機。
HTML5有一種新的方法叫做postMessage()，通過這一方法，跨域的消息傳送將不再受到同源策略的限制。
以下是postMessage()的語法：
發(fā)送窗口：
Otherwindows：涉及到的其他窗口
Message：被發(fā)送到接收窗口的信息
targetOrigin：接收窗口必須規(guī)定的URL。如果沒有任何特殊偏好，可以將其規(guī)定為“*”定義“*”為targetOrigin，但這樣做其實會存在一些安全隱患，在后文中我會提到。
Transfer：這個是任意的。
接收窗口：
當otherWindow.postMessage()執(zhí)行時，消息將會被發(fā)送到接收窗口。
發(fā)送方使用以下這段代碼后，我們就可以接收到這條消息。
通過該段代碼，我們可以訪問數(shù)據(jù)以及這一信息的源。如下所示：
Event.origin：提供信息的源(我們所接收到的信息的URL)
Event.data：提供實際所發(fā)送出的信息內(nèi)容#p#
安全性實例分析
出于演示需要，我設(shè)立了如下兩個Lab：
A: http://localhost:8383/
B: http://localhost/
正如你所看到的，上面兩個URL具有不同的端口，第一個運行在8383端口，第二個則是在80端口。正是因為其源不同，所以才導(dǎo)致端口不同。
A是發(fā)送窗口，B是接收窗口
現(xiàn)在我們加載第二個URL(http://localhost/ )作為第一個URL的iframe：
通過使用postMessage()的方法，我可以輕松的將消息從第一個URL發(fā)送到第二個URL.
我們可以通過點擊”send message“的按鈕來進行驗證。
盡管加載在第一個URL中的iframe與其并不同源，但通過postMessage() 即可進行信息傳遞。
現(xiàn)在我們來看一些postMessage()使用過程中可導(dǎo)致應(yīng)用出現(xiàn)漏洞的例子：
case1.
發(fā)送方代碼：
當發(fā)送者把targetOrigin規(guī)定為通配符”*“時，將會導(dǎo)致未知的信息被陌生的接收方(窗口)接收到。原因是從接收窗口傳來的消息任何人都可以再加載一個iframe來進行監(jiān)聽。因此在進行敏感數(shù)據(jù)的傳輸時，使用通配符是一個十分錯誤的決定。
針對此問題最好的解決方法就是在發(fā)送時添加具體的目標字段，如下所示：
Case2.
接收窗口代碼：
在上面這段代碼中可以看到，我們是直接接收發(fā)送方的消息對其進行處理，并不檢驗是否來自發(fā)送方。
但檢查消息的來源無疑是十分重要的，這樣可以防止消息來自未經(jīng)授權(quán)的發(fā)送者。
因此，我們只需要在代碼中加入對發(fā)送方的驗證，這一問題就可解決了。代碼如下：
通過檢驗event.origin，來進行驗證。
Case3.
在這一過程中，發(fā)送方和接收方都應(yīng)該驗證正在傳送的.消息。如果數(shù)據(jù)插入到HTML DOM中時并沒有進行驗證，那么應(yīng)用很有可能遭受到基于DOM的跨站腳本攻擊。
由下面這段代碼可以看出，當應(yīng)用程序接收到攻擊者發(fā)來的惡意信息，并已經(jīng)插入到HTML DOM使用innerHTML屬性時，其顯得異常脆弱。
發(fā)送方：
接收方：
執(zhí)行上面這段代碼，可導(dǎo)致在接收窗口出現(xiàn)XSS。
解決這一問題最簡單的方法就是在給元素分配數(shù)據(jù)值時使用 textContent 而不是innerHTML.
如下所示：
發(fā)送方：
接收方：
執(zhí)行上面這段代碼時我們可以看到，文本中顯示frame是作為數(shù)據(jù)而不是代碼。
從上圖我們可以看到，現(xiàn)在它并不執(zhí)行代碼，而是顯示為正常的文本。
