在本节中，将了解如何利用Web消息作为收件人页面上基于DOM的漏洞来源，还将描述这种攻击时如何构建的，包括如何经常绕过常见的来源验证技术。
什么是DOM的Web消息漏洞？
如果页面以不安全的方式处理传入的Web消息，比如，在事件侦听器中未正确验证传入消息的来源，则事件侦听器调用的属性和函数可能会成为接收器。
例如，攻击者可以托管恶意iframe并使用psotMessage()方法将Web消息数据传递给易受攻击的事件侦听器，然后将有效负载发送到父页面上的接收器。此行为意味着可以使用Web消息作为恶意数据传播到任何这些接收器的源。
基于DOM的Web消息漏洞有什么影响？
这个漏洞的潜在影响取决于目标文档对传入消息的处理，如果目标文档相信发送者不会在消息中传输恶意数据，并通过将数据传递到接收器以不安全的方式处理数据，那么两个文档的联合行为可能允许攻击者危害用户。
如何以网络消息为源构建攻击？
来看下以下代码：
这段代码很容易受到攻击，因为攻击者可以通过构造以下iframe来注入JavaScript的Payload：
<iframe src="//vulnerable-website" onload="this.contentWindow.postMessage('print()','*')">
由于事件侦听器不验证消息的来源，并且postMessage()方法指定targetOrigin "*"，因此事件侦听器接受Payload并将其传递到接收器，在本例中为eval()函数。
场景试验-使用网络消息的DOM型XSS：
https://portswigger.net/web-security/dom-based/controlling-the-web-message-source/lab-dom-xss-using-web-messages
场景说明：
这个试验场景包含一个简单的Web消息漏洞。
试验目的：
要完成这个试验，需要使用漏洞利用服务器向目标站点发布消息，从而调用print()函数。
攻击过程：
①访问首页后可以注意到包含了一个监听Web消息的addEventListener()
②打开"exploit server"将下面代码放入Body中，注意替换下试验URL
<iframe src="https://your-lab-id.web-security-academy.net/" onload="this.contentWindow.postMessage('<img src=1 onerror=print()>','*')">
③保存后发送给受害者，即可完成本试验。
试验小结：
当iframe加载时，postMessage()方法会向主页发送一条网络消息，用于提供广告的事件侦听器获取网络消息的内容并将其插入到ID为ads的div中。但是，在有注入的情况下，它会插入我们的img标签，其中包含无效的src属性，从而引发一个错误导致onerror事件处理程序执行打印的payload。
场景试验-使用Web消息和JavaScriptURL的DOM型XSS：
https://portswigger.net/web-security/dom-based/controlling-the-web-message-source/lab-dom-xss-using-web-messages-and-a-javascript-url
场景说明：
这个试验场景包含一个由Web消息触发的基于DOM的重定向漏洞。
试验目的：
要完成这个试验，需要使用漏洞利用服务器上构建一个HTML页面来针对这个漏洞调用print()函数。
攻击过程：
①根据场景提示，可以注意到在主页包含一个监听Web消息的addEventListener()调用。另外JavaScript还包含有缺陷的indexOf()检查，该检查会在Web消息中的任何位置查找字符串"http:"或"https:"，另外还包含接收器location.href
②打开"exploit server"，在body输入下面的语句，注意替换下试验URL
<iframe src="https://your-lab-id.web-security-academy.net/" onload="this.contentWindow.postMessage('javascript:print()//http:','*')">
③保存后发送给受害者，完成本试验。
试验小结：
这个脚本会发送Web消息，里面包含了任意Payload的JavaScript以及字符串"http:"，第二个参数指定Web消息允许使用任何targetOrigin。
当iframe加载时，postMessage()方法将JavaScript的Payload发送到主页，事件侦听器发现"http:"字符串并继续将Payload发送到location.href接收器，在那里调用print()函数。
来源验证
即使事件侦听器确实包含某种形式的来源验证，此验证步骤有时也可能存在根本缺陷。
例如，考虑以下代码：
indexOf方法用于尝试验证传入消息的来源是normal-website.com，但是在实践中，它只检查字符串"normal-website.com"是否包含在原始URL中的任何位置。因此，如果攻击者的恶意消息来源是
http://www.normal-website.com.evil.net
那么攻击者可以轻松绕过此验证步骤。
同样的缺陷也适用于依赖于startsWith()或endsWith()方法的验证检查。
例如，下面的事件侦听器会将来源
http://www.malicious-websitenormal-website.com
视为安全的：
场景试验-使用Web消息和JSON.parse的DOM型XSS：
https://portswigger.net/web-security/dom-based/controlling-the-web-message-source/lab-dom-xss-using-web-messages-and-json-parse
场景说明：
这个试验场景使用Web消息传递并将消息解析为JSON。
试验目的：
要完成这个试验，需要使用漏洞利用服务器上构建一个HTML页面，利用该漏洞并调用print()函数。
攻击过程：
①主页包含一个侦听Web消息的事件侦听器，这个事件侦听器需要一个使用JSON.parse()解析的字符串。在JavaScript中，可以看到事件监听器需要一个type属性，并且switch语句的load-channel分支改变了iframe src属性
②打开"exploit server"，将下面代码放入body中，注意修改下试验场景的URL
<iframe src=https://your-lab-id.web-security-academy.net/ onload='this.contentWindow.postMessage("{"type":"load-channel","url":"javascript:print()"}","*")'>
③保存后发送给受害者，即可完成试验。
试验小结：
当构建的iframe加载时，postMessage()方法会向主页发送一条类型为load-channel的Web消息，事件侦听器接收消息并使用JSON.parse()对其进行解析，然后将其发送到switch分支进行处理。
switch会触发load-channel分支，它将消息的url属性分配给ACMEplayer.element iframe的src属性，但是，在这种情况下，消息的url属性实际上包含我们的JavaScript的Payload。
由于第二个参数指定Web消息允许使用任何targetOrigin，并且事件处理程序不包含任何形式的来源检查，因此Payload被设置为ACMEplayer.element iframe的src，当受害者在浏览器中加载页面时调用print()函数。
SQL注入攻击-检索隐藏的数据
HTTP Host头漏洞攻击-概念梳理
原文始发于微信公众号（H君网安白话）：基于DOM的漏洞-攻击示例（一）
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论