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。
有关更多信息请阅读：
Bypassing SOP with Iframes - 1可以检查消息是否来自脚本正在监听的同一窗口（特别有趣的是来自浏览器扩展的内容脚本以检查消息是否来自同一页面）：
您可以通过创建一个iframe，使其发送****postMessage并立即删除，来强制**e.source**的值为null。
有关更多信息请阅读：
Bypassing SOP with Iframes - 2为了理想地执行这些攻击，您将能够将受害者网页放入一个iframe中。但一些头部如X-Frame-Header可以阻止这种行为。
在这些情况下，您仍然可以使用一种不太隐蔽的攻击。您可以打开一个新标签页，访问易受攻击的网络应用程序并与之通信：
在以下页面中，您可以看到如何通过阻止主页面在发送数据之前窃取发送给子iframe的敏感postmessage数据，并利用子页面中的XSS在数据被接收之前泄露数据：
Blocking main page to steal postmessage如果您可以iframe一个没有X-Frame-Header的网页，该网页包含另一个iframe，您可以更改该子iframe的位置，因此如果它接收使用通配符发送的postmessage，攻击者可以更改该iframe的来源为一个由他控制的页面并窃取消息：
Steal postmessage modifying iframe location在通过postMessage发送的数据被JS执行的场景中，您可以iframe该页面并利用通过postMessage发送的原型污染/XSS进行攻击。
在https://jlajara.gitlab.io/web/2020/07/17/Dom_XSS_PostMessage_2.html中可以找到几个通过postMessage非常好地解释的XSS。
通过postMessage对iframe进行攻击以利用原型污染然后XSS的示例：
对于 更多信息：
关于 原型污染 的页面链接
关于 XSS 的页面链接
关于 客户端原型污染到 XSS 的页面链接
学习与实践 AWS 黑客技术：HackTricks 培训 AWS 红队专家 (ARTE) 学习与实践 GCP 黑客技术：HackTricks 培训 GCP 红队专家 (GRTE)
