DOM 型 XSS 的排查思路
DOM 型 XSS 的特征是服务端响应中看不到注入内容：前端脚本把地址栏、引用来源、消息事件或本地存储中的数据写入危险接收点，在浏览器内完成拼接与执行。因此抓包看不到触发过程，最有效的排查方式是按数据流分析——先找危险接收点，再逆向确认外部数据能否到达该点，以及中间是否经过安全处理。
基本信息
| 数据来源 | 地址栏、文档来源、跨窗口消息、本地存储 |
|---|---|
| 危险接收点 | 直接写入页面结构、文档写入、动态执行类接口 |
| 排查方法 | 开发者工具设置断点跟踪数据流 |
| 与反射型区别 | 触发过程不出现在服务端响应中 |
| 记录要求 | 页面、来源、接收点、触发条件与是否经安全处理 |
典型使用场景
- 单页应用的地址栏参数被直接渲染到页面
- 锚点与哈希参数驱动的前端路由渲染逻辑
- 跨窗口消息事件处理未校验来源与内容
- 本地存储中的用户昵称被直接写入页面结构
- 第三方脚本库内部的页面结构拼接操作
排查清单
排查清单
# 1. 在脚本资源中检索危险接收点的使用位置
# 2. 逆向追踪：数据来源能否到达该接收点
# 3. 用断点确认中间是否经过编码或白名单处理
# 4. 构造触发条件，在浏览器中确认渲染结果
# 5. 记录：页面、数据来源、接收点、触发条件、处理情况数据流要素读法
| 要素 | 示例 | 检查重点 |
|---|---|---|
| 数据来源 | 地址栏、引用来源、消息事件 | 是否可被外部控制 |
| 中间处理 | 编码函数、白名单校验 | 采用黑名单还是白名单 |
| 危险接收点 | 页面结构写入、文档写入 | 是否使用安全替代接口 |
| 触发条件 | 打开特定链接、点击特定元素 | 复现步骤是否完整 |
修复视角：改用文本写入等安全接口；确需写页面结构时先统一编码，或使用可信模板渲染。
第三方脚本库内部的页面操作也要纳入排查：问题不一定出现在自研代码里，但修复仍归应用方。