存储型XSS实战：Crowdsignal与WordPress组合漏洞Payload构造

存储型XSS（跨站脚本攻击）因其危害性大、利用链条长而备受安全研究者关注。一个精心构造的Payload，往往能在意想不到的地方触发。本文将通过一个真实案例，分享一个针对Crowdsignal投票与WordPress平台组合场景下的存储型XSS利用手法。

漏洞触发场景与步骤

这个漏洞的利用链涉及两个常见平台：Crowdsignal（一个在线投票服务）和WordPress.com。攻击者需要能够发布WordPress文章，并诱导受害者点击文章中的特定链接。具体复现步骤如下：

1. 创建恶意投票：访问 https://app.crowdsignal.com/dashboard 并创建一个新的投票。
2. 注入Payload：在投票的答案选项中，输入以下精心构造的Payload：

   "style="position:fixed;top:0;left:0;border:999em solid green;" onmouseover="alert(document.cookie)"

   这段代码利用了HTML属性注入，当鼠标悬停时，会执行alert(document.cookie)。

3. 获取分享链接：点击“Share Your Poll”（分享你的投票），复制生成的投票结果查看链接。
4. 在WordPress中植入：登录 https://wordpress.com/posts，新建一篇博客帖子。
5. 嵌入恶意链接：在帖子编辑器中，将上一步复制的Crowdsignal结果链接插入到文章内容中。
6. 发布与触发：保存并发布这篇文章。任何访问此文章的用户，如果点击了文中嵌入的链接并进入投票结果页，当他们的鼠标滑过被注入的投票选项区域时，存储的XSS Payload将被触发，弹窗显示当前用户的Cookies。

这个案例展示了在复杂应用交互中寻找安全漏洞的巧妙思路。通过将恶意代码存储在一个平台（Crowdsignal），再通过另一个平台（WordPress）进行传播和触发，实现了存储型XSS的攻击效果。

总结与思考

这种攻击方式的关键在于，恶意输入被持久化地保存在Crowdsignal的投票数据中，并通过WordPress文章进行广泛传播。它提醒我们，在进行渗透测试或代码审计时，不仅要关注单一应用点的过滤，更要审视数据在不同系统、不同上下文间流转时可能产生的风险。

对于开发者而言，无论用户输入出现在哪个功能点，都必须进行严格的输出编码和过滤。对于使用第三方插件或嵌入外部内容的平台（如WordPress），也需要对嵌入的内容进行安全沙箱处理或来源审查。

参考来源

• https://hackerone.com/reports/2012636

更多Web安全实战技术与深度分析，欢迎在云栈社区的「安全/渗透/逆向」板块与同道中人交流探讨。