cookie

在上述child.html的子页面中，存在一个向主页面的消息发送，它就调用了postMessage方法，如下：

window.parent.postMessage("Helloparent","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变量的过程中， 它在三个地方存在，第一个地方就是：

varfdata=JSON.parse(decodeURIComponent(window.location.hash.substr(1)));varns=fdata.ns;varworigin=fdata.worigin;

代码很简单，首先，它获取到了当前窗口的URL哈希值，然后执行编码操作（Decode）；之后，解析为json对象，接着，创建两个变量，ns代表命名空间，wOrigin代表消息的发送目标窗口。

看到window.location.hash方法，我们就会自然地想到它可以用dom-based XSS加以利用，但这个问题在此不作讨论。

所以，接下来，我继续检查其中的代码，查看 ns 和 wOrigin 在传递给postMessage方法前的一些过滤机制，啊，竟然没有！那这样的话，我们就可以想办法来构造exploit看看了。

构造Exploit

现在，我们需要逆向来思考这个过程：