某天，當我在做某個項目的漏洞測試時，在登入的一些HTTP請求記錄中，我發現了一種利用postMessage方式竊取和編輯使用者Cookie的方法。由于該測試是邀請測試，出于保密，我隻能在下文中和大家分享一些方法思路。
postMessage介紹
相信大家都聽過不同視窗之間的通信、目前視窗與内部iframe架構的通信以及一些跨域技巧，window.postMessage功能就是允許在兩個用戶端的視窗/frames間發送資料資訊，跨域地實作通信的方法。
在HTML5中，Window.postMessage() 方法可以安全地實作跨源通信。通常，對于兩個不同頁面的腳本，隻有當執行它們的頁面位于具有相同的協定(通常為https)，端口号(443為https的預設值)，以及主機 (兩個頁面的模數 Document.domain設定為相同的值) 時，這兩個腳本才能互相通信。window.postMessage() 方法提供了一種受控機制來規避此限制，隻要正确的使用，這種方法就很安全。
Window.postMessage有三個參數，message、targetOrigin和可選的[transfer])，其中message代表将要發送到其他視窗的資料，targetOrigin表示接收資料消息的目标視窗，transfer代表消息的所有權。另外還有一個window.addEventListener(“message”, receiveMessage, false)，用以監聽消息資料的回報，其中的message就存在data、origin和source三個屬性，origin屬性表示消息資料發送方的身份，隻有和原來指定發送方的協定、域名或端口一緻，才能建立通信。具體請參考postMessage的詳細介紹。
舉個例子，比如我們這有一個包含js代碼的頁面，用來監聽記錄傳入的消息，其中的js代碼如下：
在上述child.html的子頁面中，存在一個向首頁面的消息發送，它就調用了postMessage方法，如下：
window.parent.postMessage("Hello parent", "target");
接下來，會發生什麼呢?
首先，你通路那個會加載child.html子頁面的首頁面，之後，子頁面會向首頁面發送消息，然後，首頁面接收該消息并通過控制台進行記錄。這裡會存在什麼安全隐患嗎？
如果攻擊者能控制消息發送的目标視窗target參數值會怎樣？
當然，如果子頁面存在點選劫持又會怎樣？
我們要思考的是，按照postMessage規範來說，如果消息發送的目标視窗target參數是星号*，表示無限制，也即可以發送到任何引用了子頁面的域名中去。這樣的話，就會導緻一些不安全的問題出現。
具體測試
回到之前的漏洞測試過程中，為了更好地展示思路，接下來開始，假設我們的測試目标為域名onga.com。我通過爬蟲找到了其中一個包含了HTML内容的一個HTML頁面 sync.html，然後，我的工具也顯示該頁面中包含了一些不安全的Javascript代碼。
這個檔案沒有其它過多的元素，隻包含了一個script标記，是以這個頁面看起來是起到一個中轉作用。仔細分析其中的 sync.html 檔案，其中包含了一個postMessage方法，它向變量名為wOrigin的目标發送了消息，如下：
window.parent.postMessage(JSON.stringify(msg), wOrigin);
這樣，我們現在就看到了兩個變量，分别為msg和wOrigin。于是，我認真查找了類似變量的初始化位置，以确定是否可以對它們進行控制。很驚訝的是，msg是Cookie值，其它相關的都是使用者的輸入。
在分析wOrigin變量的過程中， 它在三個地方存在，第一個地方就是：
var fdata = JSON.parse(decodeURIComponent(window.location.hash.substr(1)));
var ns = fdata.ns;
var worigin = fdata.worigin;
代碼很簡單，首先，它擷取到了目前視窗的URL哈希值，然後執行編碼操作(Decode)；之後，解析為json對象，接着，建立兩個變量，ns代表命名空間，wOrigin代表消息的發送目标視窗。
看到window.location.hash方法，我們就會自然地想到它可以用dom-based XSS加以利用，但這個問題在此不作讨論。
是以，接下來，我繼續檢查其中的代碼，檢視 ns 和 wOrigin 在傳遞給postMessage方法前的一些過濾機制，啊，竟然沒有！那這樣的話，我們就可以想辦法來構造exploit看看了。
構造Exploit
現在，我們需要逆向來思考這個過程：
首先，要建立ns 和 wOrigin 兩個變量；
假設 ns=anyblah ，wOrigin=*；
建立json對象格式 {“ns”:”anyblah”,”wOrigin”:”*”}；
構造存在漏洞的URL：
http://vulnerable-onga.com/sync.html#{“ns”:”anyblah”,”wOrigin”:”*”}
當上述URL頁面被加載之後，postMessage方法會向首頁面發送一個消息，但由于采用了*星号，該過程中不會限制發送目标域，消息可以發送到任何采取監聽措施的域名中去。
現在，我們在首頁面中來設定一個監聽以接收消息：
建立一個iframe架構來加載存在漏洞的頁面，并把它設定為子頁面，是以最終的PoC代碼可以如下：
當打開攻擊者設定的包含上述代碼的頁面http://attacker.com/poc.html後，監聽器将會運作，并會等待傳入消息，同時，iframe架構會被加載，此時，存在漏洞的頁面也一樣會在iframe架構會中被加載，并會向首頁面也就是攻擊者控制的網站頁面中發送包含有cookie的消息，最終，在我們的執行個體中，攻擊者控制的網站會捕獲到這些包含cookie的消息。
這就完了嗎？
當然沒有，不要忙着慶祝，這其中可能會有一些遺漏的東西，我們一起來看看。由于目标系統包含postMessage方法的檔案隻有57行代碼，我決定好好分析一下。果然，我又在其中發現了另外一行有意思的代碼：
window.addEventListener(‘message’, h_message);
我又趕緊檢查了一下參數h_message函數的具體内容：
function h_message(event)
{
var data = null;
try { data = JSON.parse(event.data); } catch(e) { return;}
if (data.msgType !== "write" && data.namespace !== ns) {
return;
}
setCookie(data.cookieName, data.cookieVal,parseInt(data.expiresDays, 10), data.secureOnly);
}
我們來分析一下以上代碼包含的意思：
傳入消息中可能包含有json對象；
json對象中的msgType屬性可能和write屬性相同；
另外一個namespace屬性可能和hash中的 ”ns“相同，都是使用者端控制的輸入；
if (data.msgType !== “write” && data.namespace !== ns)中使用了邏輯非和與運算，是以兩組條件中都需要滿足才能return傳回；
否則，就會執行下一個包含其它json屬性為參數的setCookie()函數。
這裡确實是存在風險的，由于缺乏對消息源的認證機制，是以任意網站都可以用來發送消息并向setCookie()中傳入惡意值。基于以上偉世通，我們可以構造出以下json對象來：
{“msgType”:”write”,”namespace”:”a”,”cookieName”:”injectedt”,”cookieVal”:”hacked”,”expiresDays”:10,”secureOnly”:false}
目标URL我們可以這樣來設定：/sync.html#{“ns”:”a”,”wOrigin”:”*”}
最終的PoC頁面中将包含以下代碼：
儲存包含上述代碼的PoC頁面為html格式并打開，cookie就能成功注入，是以攻擊者端也就能向存在漏洞網站，注入任意cookie資料資訊，實作間接的cookie竊取和編輯操作了。如下視訊所示：
看不到？請點選底部閱讀原文。
參考：
http://www.sec-1.com/blog/wp-content/uploads/2016/08/Hunting—postMessage-Vulnerabilities.pdf
https://www.youtube.com/watch?v=XTKqQ9mhcgM
https://robertnyman.com/2010/03/18/postmessage-in-html5-to-send-messages-between-windows-and-iframes/
https://gist.github.com/YasserGersy/1fc77ff9b678fb5028a272a86c1d2ea1
https://ngailong.wordpress.com/2018/02/13/the-mystery-of-postmessage/
*參考來源：medium，clouds編譯，轉載請注明來自FreeBuf.COM