简而言之

在一次引人入胜的漏洞挖掘之旅中，数月前在一项众测项目中下发现了一串巧妙链接的安全缺陷，这串漏洞链融合了多种技术元素，包括但不限于postMessage的不当使用、JSONP端点的粗疏防护、Web应用防火墙（WAF）的规避、基于DOM的跨站脚本（XSS）在非目标子域名上的运用、CORS配置的宽松策略，以及最终导向的核心目标：对受保护资产实施跨站请求伪造（CSRF）攻击。出于保密原则，本文隐去了识别信息，聚焦于技术细节与故事的精彩之处。

寻找难以捉摸的CSRF

我的目标的漏洞赏金计划范围仅限于www.rxxxxd.com及rxxxxd.com下的几个其他子域名。那时，我在那里寻找漏洞的想法已经穷尽。然而，我心中仍存有一个可利用的跨站请求伪造（CSRF）的可能性...

我注意到一些子域名，比如inscope.rxxxxd.com，可以通过向根植于https://www.rxxxxd.com/api的端点发出POST请求来执行敏感操作（如更新认证用户的个人资料）。这类请求的认证依赖于环境权限，具体体现为一个名为sid的cookie，标记为SameSite=None和Secure。

不幸的是，那些端点需要一个防御CSRF的令牌（与认证用户的会话绑定）作为查询参数csrftoken存在。运行在https://inscope.rxxxxd.com上下文中的客户端代码会通过一个经过认证的GET请求到https://www.rxxxxd.com/profile来获取这个反CSRF令牌，该请求相应地配置了CORS。

此外，我没有找到直接窃取受害者那个反CSRF令牌的方法。在我寻找CSRF的征途中，似乎遇到了一堵无法逾越的墙。

宽松的CORS策略使我超出范围

当我在目标上的进展像这样停滞时，我通常开始探索范围外的资产，希望发现并滥用它们与某些范围内资产之间的信任关系。在进一步测试https://www.rxxxxd.com/profile端点后，我意识到其CORS配置不仅允许来自https://in-scope.rxxxxd.com的源，还允许由rxxxxd.com任意子域组成的任何Web源：

因此，如果我能在rxxxxd.com的任何子域名（即使是范围外的）上发现跨站脚本（XSS）实例，我就能窃取受害者的反CSRF令牌，然后对https://www.rxxxxd.com/api端点发起CSRF攻击。带着这个计划，我开始仔细审查rxxxxd.com的范围外子域名。

范围外子域上的不安全消息事件监听器

借助postMessage-tracker Chrome扩展工具，我锁定了https://out-xx-sxxe.rxxxxd.com/search，它在'message'事件上有一个引人注目的监听器：

该事件监听器中明显缺少来源检查，意味着任何恶意页面（部署在Web上的任何地方），只要持有https://out-xx-sxxe.rxxxxd.com/search的接口并引用，就可以向该接口发送恶意Web消息，而这些消息会无条件地被接受和处理。影响如何完全取决于监听器的逻辑。对该代码进行简单的静态分析，消息事件监听器执行以下操作：

1. 将事件的数据属性解析为JSON，并将结果存储在一个名为t的对象中。
2. 在periods上拆分method属性。
3. 使用步骤2的结果迭代访问某个window.APP对象（在客户端其他地方声明）的嵌套属性。
4. 调用由此获得的函数，并将t对象（见步骤1）的一个名为arg的属性作为参数传递。

那么，我的恶意页面可以向https://out-xx-sxxe.rxxxxd.com/search发送一个