web消息源的控制

在本节中，我们将学习在接收web消息的页面中，如何将web消息作为源来利用基于DOM的漏洞。我们还将描述如何构造这样的攻击，包括如何绕过常见的对源的验证技术。

如果一个页面以不安全的方式处理传入的web消息，例如，没有在事件监听器中正确验证传入消息的来源，那么事件监听器调用的属性和函数可能会成为接收器。例如，攻击者可以利用一个恶意的iframe并使用postMessage()方法将web消息数据传递给有漏洞的事件监听器，然后该监听器将payload发送到父页面上的接收器。这种行为意味着你可以使用web消息作为向任何接收器发送恶意数据的源。

1. 基于DOM的web消息漏洞的影响是什么

该漏洞的潜在影响取决于目标document对传入消息的处理。例如，如果目标document相信发送方不会在消息中传输恶意数据，并以不安全的方式将数据传递到接收器中，那么document的行为可能会允许攻击者攻击其他用户。

2. 如何利用web消息作为源构造攻击

考虑以下代码：

<script>
window.addEventListener('message', function(e) {
  eval(e.data);
});
</script>

这很容易受到攻击，因为攻击者可以通过构造以下iframe来注入JavaScript payload:

<iframe src="//vulnerable-website" onload="this.contentWindow.postMessage('print()','*')"> 

由于事件监听器不验证消息的来源，并且postMessage()方法指定了发送目标是 "*"，事件监听器接受payload并将其传递到接收器，在本例中为 eval() 函数。       

3. 源验证

即使事件监听器确实包含某种形式的对源的验证，这个验证方式有时也可能存在根本缺陷。例如，考虑以下代码:

window.addEventListener('message', function(e) {
  if (e.origin.indexOf('normal-website.com') > -1) {
    eval(e.data);
  }
});

indexOf方法用于尝试和验证传入消息的来源是 normal-website.com 域。然而实际上，它只检查字符串“normal-website.com”是否包含在源URL的任何地方。因此，如果攻击者的恶意消息的来源是 http://www.normal-website.com.evil.net，那么攻击者可以很容易地绕过这个验证。

同样的缺陷也适用于依赖startsWith()或endsWith()方法的验证检查。例如，下面的事件监听器会认为来源 http://www.malicious-websitenormal-website.com 是安全的:

window.addEventListener('message', function(e) {
  if (e.origin.endsWith('normal-website.com')) {
    eval(e.data);
  }
});

4. 哪些接收器会导致基于DOM的web消息漏洞

只要网站接受来自不可信来源的web消息数据，对来源没有做足够的验证，将消息发送到事件监听器，那么监听器使用的任何接收器都可能导致漏洞。