简而言之
在一次引人入胜的漏洞挖掘之旅中，数月前在一项众测项目中下发现了一串巧妙链接的安全缺陷，这串漏洞链融合了多种技术元素，包括但不限于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消息，而这些消息会无条件地被接受和处理。影响如何完全取决于监听器的逻辑。对该代码进行简单的静态分析，消息事件监听器执行以下操作：
- 将事件的数据属性解析为JSON，并将结果存储在一个名为t的对象中。
- 在periods上拆分method属性。
- 使用步骤2的结果迭代访问某个window.APP对象（在客户端其他地方声明）的嵌套属性。
- 调用由此获得的函数，并将t对象（见步骤1）的一个名为arg的属性作为参数传递。
那么，我的恶意页面可以向https://out-xx-sxxe.rxxxxd.com/search发送一个
4A评测 - 免责申明
本站提供的一切软件、教程和内容信息仅限用于学习和研究目的。
不得将上述内容用于商业或者非法用途，否则一切后果请用户自负。
本站信息来自网络，版权争议与本站无关。您必须在下载后的24个小时之内，从您的电脑或手机中彻底删除上述内容。
如果您喜欢该程序，请支持正版，购买注册，得到更好的正版服务。如有侵权请邮件与我们联系处理。敬请谅解！
程序来源网络，不确保不包含木马病毒等危险内容，请在确保安全的情况下或使用虚拟机使用。
侵权违规投诉邮箱：4ablog168#gmail.com（#换成@）
