PostMessage Vulnerabilities
Last updated
Last updated
学习与实践 AWS 黑客技术:HackTricks 培训 AWS 红队专家 (ARTE) 学习与实践 GCP 黑客技术:HackTricks 培训 GCP 红队专家 (GRTE)
PostMessage 使用以下函数发送消息:
注意,targetOrigin 可以是 '*' 或像 https://company.com. 的 URL。 在 第二种情况 中,消息只能发送到该域(即使窗口对象的来源不同)。 如果使用 通配符,消息可以发送到任何域,并将发送到窗口对象的来源。
正如在 这份报告 中所解释的,如果你发现一个可以被 iframed 的页面(没有 X-Frame-Header
保护)并且该页面通过 postMessage 使用 通配符 (*) 发送 敏感 消息,你可以 修改 iframe 的 来源 并将 敏感 消息 泄露 到一个由你控制的域。
请注意,如果页面可以被 iframed,但 targetOrigin 被 设置为一个 URL 而不是通配符,这个 技巧将不起作用。
addEventListener
是 JS 用来声明 期望 postMessages
的函数。
将使用类似以下的代码:
注意在这种情况下,代码的第一件事是检查来源。这非常重要,特别是如果页面将对接收到的信息进行任何敏感操作(例如更改密码)。如果不检查来源,攻击者可以让受害者向这些端点发送任意数据并更改受害者的密码(在这个例子中)。
为了查找当前页面中的事件监听器,你可以:
搜索 JS 代码中的 window.addEventListener
和 $(window).on
(JQuery 版本)
在 开发者工具控制台中执行:getEventListeners(window)
在 浏览器的开发者工具中转到 Elements --> Event Listeners
使用一个浏览器扩展,如 https://github.com/benso-io/posta 或 https://github.com/fransr/postMessage-tracker。这些浏览器扩展将拦截所有消息并显示给你。
event.isTrusted
属性被认为是安全的,因为它仅对由真实用户操作生成的事件返回 True
。虽然如果正确实现很难绕过,但它在安全检查中的重要性显著。
在 PostMessage 事件中使用 indexOf()
进行来源验证可能容易被绕过。一个说明此漏洞的示例是:
search()
方法来自 String.prototype.search()
,旨在用于正则表达式,而不是字符串。传递任何非正则表达式的内容会导致隐式转换为正则表达式,使该方法可能不安全。这是因为在正则表达式中,点(.)作为通配符,允许通过特殊构造的域绕过验证。例如:
match()
函数与 search()
类似,处理正则表达式。如果正则表达式结构不当,可能容易被绕过。
escapeHtml
函数旨在通过转义字符来清理输入。然而,它并不创建一个新的转义对象,而是覆盖现有对象的属性。这种行为可能被利用。特别是,如果一个对象可以被操控,使其受控属性不承认 hasOwnProperty
,则 escapeHtml
将无法按预期执行。以下示例演示了这一点:
预期失败:
绕过转义:
在此漏洞的背景下,File
对象因其只读的 name
属性而特别容易被利用。该属性在模板中使用时,未被 escapeHtml
函数清理,导致潜在的安全风险。
JavaScript 中的 document.domain
属性可以由脚本设置以缩短域名,从而允许在同一父域内更宽松的同源策略执行。
在使用 %%%%%% 嵌入网页到沙箱 iframe 中时,重要的是要理解 iframe 的来源将被设置为 null。这在处理沙箱属性及其对安全性和功能的影响时尤为重要。
通过在沙箱属性中指定 allow-popups
,从 iframe 内部打开的任何弹出窗口都继承其父级的沙箱限制。这意味着,除非还包括 allow-popups-to-escape-sandbox
属性,否则弹出窗口的来源也被设置为 null
,与 iframe 的来源一致。
因此,当在这些条件下打开弹出窗口并使用 postMessage
从 iframe 向弹出窗口发送消息时,发送和接收端的来源都被设置为 null
。这种情况导致 e.origin == window.origin
评估为 true (null == null
),因为 iframe 和弹出窗口共享相同的来源值 null
。
有关更多信息请阅读:
可以检查消息是否来自脚本正在监听的同一窗口(特别有趣的是来自浏览器扩展的内容脚本,以检查消息是否来自同一页面):
您可以通过创建一个iframe,使其发送****postMessage并立即删除,来强制**e.source
**为null。
有关更多信息请阅读:
为了理想地执行这些攻击,您将能够将受害者网页放入iframe
中。但一些头部如X-Frame-Header
可以阻止这种行为。
在这些情况下,您仍然可以使用一种不太隐蔽的攻击。您可以打开一个新标签页,访问易受攻击的网络应用程序并与之通信:
在以下页面中,您可以看到如何通过阻止主页面在发送数据之前窃取发送给子iframe的敏感postmessage数据,并利用子页面中的XSS在数据被接收之前泄露数据:
如果您可以iframe一个没有X-Frame-Header的网页,该网页包含另一个iframe,您可以更改该子iframe的位置,因此如果它接收使用通配符发送的postmessage,攻击者可以更改该iframe的来源为一个被他控制的页面并窃取消息:
在通过postMessage
发送的数据被JS执行的场景中,您可以iframe该页面并利用原型污染/XSS,通过postMessage
发送利用代码。
一些通过postMessage
非常好地解释的XSS可以在https://jlajara.gitlab.io/web/2020/07/17/Dom_XSS_PostMessage_2.html找到。
通过postMessage
对iframe
进行原型污染和然后XSS的利用示例:
对于 更多信息:
链接到关于 原型污染 的页面
链接到关于 XSS 的页面
链接到关于 客户端原型污染到 XSS 的页面
学习与实践 AWS 黑客技术:HackTricks 培训 AWS 红队专家 (ARTE) 学习与实践 GCP 黑客技术: HackTricks 培训 GCP 红队专家 (GRTE)