1 基本概念

1.1 定义与含义

XSS，即 Cross-Site Scripting，中文通常译作“跨站脚本攻击”。它指攻击者将恶意脚本内容注入网页或应用返回的数据中，并在其他用户打开页面时由浏览器自动执行的安全问题。其核心特征不是“网站被直接入侵”，而是网站对用户输入、输出或脚本执行环境的处理不当，导致原本不应运行的代码被当作页面内容的一部分执行。

XSS 常见于动态网页、表单交互、评论系统、搜索结果页以及单页应用等场景。由于浏览器会信任来自同一页面上下文中的脚本，攻击一旦成功，便可能在受害者不知情的情况下完成页面篡改、信息读取或操作冒用。

1.2 产生原因

XSS 的出现通常与“输入未充分限制、输出未正确编码、上下文边界被混淆”有关。很多漏洞并非来自复杂的程序错误，而是开发者将用户可控内容直接拼接进 HTML、JavaScript、URL 或属性值中，从而给了恶意脚本可乘之机。

1.2.1 输入过滤不足

当网站仅依赖简单的关键词替换或黑名单过滤时，攻击者往往可以通过变形字符、编码绕过、大小写切换或标签拆分等方式规避限制。输入过滤如果缺乏完整性，往往只能拦住一部分明显载荷，却难以覆盖复杂的注入形式。

1.2.2 输出编码缺失

很多 XSS 并不是“输入本身危险”，而是“输出时没有按场景转义”。同一段数据如果被放入 HTML 文本、属性值、脚本字符串或 URL 参数中，需要使用不同的编码策略。若直接原样输出，浏览器可能将其中的特殊字符解释为标签、属性或代码片段。

1.2.3 信任边界混淆

当系统把“来自数据库的数据”“来自后端接口的数据”或“来自内部服务的数据”默认视为安全内容时，就容易放松防护。实际上，只要数据最终来源于用户、第三方或可被污染的渠道，都应当重新进行安全处理，否则会在多层传递后形成潜伏型漏洞。

1.3 与其他 Web 漏洞的区别

XSS 的重点在于“在受害者浏览器中执行脚本”，其攻击目标通常是前端会话、页面内容或用户操作。它与 SQL 注入不同，后者主要利用的是服务器端数据库查询语句的拼接缺陷；也不同于 SSRF，这类漏洞主要借助服务器向内网或远端发起请求；而与 CSRF 相比，XSS 更强调脚本执行能力，往往能够进一步辅助发起更复杂的操作。

2 类型分类

2.1 存储型 XSS

存储型 XSS 指恶意脚本被提交到服务器并保存下来，随后在后续页面展示时被执行的漏洞类型。由于载荷会进入数据库、日志、评论区或其他持久化介质，这类漏洞通常影响面更广，且更容易反复触发。

2.1.1 攻击流程

典型流程通常包括：攻击者先在输入点提交恶意内容，服务器将其存储；当其他用户访问相关页面时，页面把该内容原样或不当处理后输出；浏览器解析时执行脚本，攻击便完成。因为脚本已经“落地”，所以即便最初提交者离线，风险仍然持续存在。

2.1.2 常见场景

常见于论坛帖子、用户评论、个人简介、商品评价、工单备注等允许多用户编辑或展示的区域。只要页面会把用户提交内容直接渲染到浏览器，且缺少严格转义，就可能成为存储型 XSS 的入口。

2.2 反射型 XSS

反射型 XSS 是指恶意内容并未长期保存，而是通过请求参数、表单提交或跳转链接被服务器立即反射回页面并执行。它通常依赖诱导受害者点击特殊构造的链接，因此与社交工程结合较为紧密。

2.2.1 URL 参数注入

攻击者常把载荷放入 URL 查询参数、路径片段或表单字段中，再通过构造链接引导用户访问。服务器在生成响应时如果把这些参数直接插入页面，就可能让浏览器把其中的脚本内容当作可执行代码。

2.2.2 即时触发特征

反射型 XSS 的特点是“请求即触发、响应即执行”。它不需要持久化存储，因此生命周期较短，但可通过钓鱼邮件、短链、即时消息等方式快速传播，常见于搜索结果页、错误提示页和重定向页面。

2.3 DOM 型 XSS

DOM 型 XSS 主要发生在客户端，由前端脚本读取 URL、hash、localStorage、表单值等可控数据，并将其写入 DOM 时触发。此类漏洞往往不依赖服务器直接回显，而是由页面中的 JavaScript 自行完成危险拼接。

2.3.1 前端脚本驱动

在单页应用或富交互页面中，前端代码经常根据地址栏参数动态更新内容。如果开发者将这些数据未经处理地送入 innerHTML、模板字符串或动态脚本环境，就可能让攻击载荷在浏览器端被执行。

2.3.2 受影响的 DOM 操作

高风险操作通常包括直接设置 innerHTML、outerHTML、document.write()、insertAdjacentHTML() 等会解析 HTML 的接口；以及将用户数据拼接到 eval()、setTimeout() 字符串、事件属性或脚本模板中的场景。相较之下，采用纯文本插入或安全属性赋值更为稳妥。

2.4 其他变种

除常见三类外，XSS 还可能以复合方式出现，表现出更强的隐蔽性和环境依赖性。

2.4.1 混合型 XSS

混合型 XSS 往往兼具存储和反射特征，例如攻击载荷先被保存，再在特定查询条件或渲染路径中触发；也可能是前后端共同参与，既有服务器回显，又有前端二次拼接，导致漏洞链条更长。

2.4.2 事件驱动型注入

这类注入利用页面中的事件绑定机制，在鼠标悬停、点击、加载或失焦等时机触发脚本。它常借助 HTML 事件属性、动态绑定回调或不安全的富文本渲染实现，外观上不一定显眼，但一旦条件满足便会执行。

3 攻击原理

3.1 浏览器执行机制

浏览器会对 HTML、CSS、JavaScript 和 DOM 结构进行解析与协同处理。只要恶意内容被放入可执行上下文，浏览器就可能把它解释为脚本而非普通文本。XSS 的关键，正是利用了解析器对不同上下文的区分边界。

3.1.1 同源策略相关性

同源策略本意是限制不同来源脚本之间的敏感访问，但当攻击脚本成功运行在目标站点的同源上下文中时，它就可以使用原站点权限访问页面数据、发起同源请求或读取可见信息。也就是说，XSS 并非“绕过同源策略”，而是“借用同源环境”。

3.1.2 脚本上下文切换

很多载荷之所以有效，是因为它能在文本、属性、脚本、URL 等上下文之间切换。例如，原本应当作为普通字符串显示的内容，若进入脚本字符串内部，就可能通过引号闭合、标签插入或转义逃逸改变语义，从而触发执行。

3.2 载荷构造

XSS 载荷的设计通常围绕“打断原有结构、插入可执行片段、尽量隐蔽触发”展开。实际形态并不固定，开发者对输入的限制方式、输出位置和解析规则，都会影响载荷样式。

3.2.1 标签注入

标签注入是较为直观的一种方式，攻击者通过插入脚本标签、伪装标签或可触发执行的媒体标签来影响页面结构。只要页面允许未转义的 HTML 进入，就可能出现这种风险。

3.2.2 属性注入

当用户输入被放进 HTML 属性值中时，若引号、空格或尖括号未正确处理，攻击者可借此关闭原属性并新增危险属性。属性注入常见于图片地址、链接地址、按钮标题、表单字段等位置。

3.2.3 事件处理器注入

借助 onload、onclick、onerror 等事件处理器，攻击者可以让脚本在特定时刻自动或半自动执行。此类方式常被用于绕开简单的标签拦截，因为即使主标签被限制，事件属性仍可能成为入口。

3.3 利用链

XSS 的危害并不止于弹窗或页面改写，它常作为更长攻击链的一环，进一步影响账户安全和业务数据。

如果页面中的认证信息未做充分保护，恶意脚本可能尝试读取会话相关数据、页面令牌或本地存储中的敏感字段，并将其发送到攻击者可控位置。具体能否成功，取决于站点对 Cookie 属性和前端存储方式的设置。

3.3.2 页面内容篡改

脚本执行后可以直接修改 DOM，替换表单、插入提示、伪造按钮或改变链接指向。用户表面上看到的是“原网站”，实际上操作路径可能已被偷偷改写，这也是 XSS 常用于钓鱼引导的原因之一。

3.3.3 CSRF 辅助利用

XSS 往往能够读取页面中的动态令牌、自动提交表单，或在用户已登录的上下文中发起同源请求，因此可用于增强 CSRF 攻击效果。相比单纯伪造请求，XSS 提供了更高的自动化和交互操控能力。

4 危害与影响

4.1 对用户的影响

对普通用户而言，XSS 的直接风险通常体现在账户、隐私和操作安全三个方面。

4.1.1 账号劫持

一旦攻击者获取会话信息或诱导用户在伪造页面中输入凭据，就可能造成账号被冒用。对于具有支付、发帖、消息或管理权限的账户，这类后果尤其严重。

4.1.2 隐私泄露

脚本可读取页面中可见的个人资料、消息内容、收货信息、地址簿索引或临时缓存数据，并在后台外传。即使不能直接拿到全部敏感数据，也可能通过页面结构和交互细节推断出用户画像。

4.1.3 钓鱼与欺骗

XSS 还常被用于在真实站点内嵌入假提示、假登录框或伪装通知。由于页面域名和外观都与原站一致，用户更容易放松警惕，从而在不知情的情况下输入敏感信息。

4.2 对网站的影响

对于网站运营者，XSS 不仅是技术漏洞，也会带来长期的业务和声誉成本。

4.2.1 品牌信誉受损

一旦用户发现站点会被利用来弹出异常内容、跳转可疑页面或诱导输入信息，信任度会迅速下降。即便漏洞后续被修复，用户对平台安全性的印象也可能长期受影响。

4.2.2 数据安全风险

XSS 可能影响后台管理页面、内部工具或工单系统，导致更高权限的数据被间接访问。若脚本在管理员会话中执行，后果往往比普通用户场景更严重。

4.2.3 业务流程干扰

页面被篡改、按钮被替换、表单被自动提交时，正常业务流程可能被打断。轻则导致用户体验下降，重则造成订单异常、内容污染或大量错误操作。

5 防护措施

5.1 输入验证

输入验证的目标不是“把所有危险字符都删掉”，而是尽量保证进入系统的数据符合预期格式。它应与输出编码配合使用，而不能单独替代后者。

5.1.1 白名单策略

白名单策略优先允许明确合法的内容类型、字符集合和结构形式，例如仅接受数字、日期、固定枚举值或受限的富文本标签。与黑名单相比，它更容易形成稳定规则，减少绕过空间。

5.1.2 长度与格式校验

限制输入长度可以降低异常载荷的复杂度，也能减少日志污染和资源消耗。格式校验则用于确认数据是否符合邮箱、手机号、编号、URL 等既定结构，从源头减少不必要的自由文本进入关键位置。

5.2 输出编码

输出编码是防御 XSS 的核心手段之一。其原则是：在不同上下文中，将特殊字符转换为浏览器不会误解释的安全形式。

5.2.1 HTML 编码

当内容要显示在 HTML 文本节点中时，应对 <、>、&、"、' 等字符进行转义，避免其被解析为标签或属性的一部分。这样可确保用户输入只作为文本展示。

5.2.2 JavaScript 编码

若数据必须进入脚本字符串，应按 JavaScript 语法规则进行转义，防止引号、反斜杠、换行符等破坏字符串结构。更稳妥的做法通常是避免把用户输入直接拼进脚本，而改用数据属性或安全 API 传递。

5.2.3 URL 编码

当内容作为 URL 参数、跳转地址或链接片段时，应进行合适的百分号编码，防止特殊字符改变地址结构。尤其是在构造查询字符串时，编码不当可能同时引发注入和跳转问题。

5.3 安全框架与组件

合理使用成熟框架和组件，能显著减少手工拼接字符串带来的风险。

5.3.1 模板引擎默认转义

许多模板引擎默认会对变量输出进行转义，这是较为安全的默认行为。开发者应尽量保留这一机制，仅在确有必要且已确认安全的情况下使用原始输出。

5.3.2 安全渲染组件

一些前端组件或富文本处理库提供了沙盒化、白名单过滤或安全渲染能力，适合处理评论、文章正文或半结构化内容。相比直接 innerHTML 注入，这类方案更容易控制风险边界。

5.4 内容安全策略

内容安全策略，通常简称 CSP，是浏览器层面的额外防护机制，用于限制页面可加载和可执行的资源来源。它不能替代编码，但能在一定程度上抑制漏洞利用。

5.4.1 CSP 基础

CSP 通过策略头或元标签声明允许的脚本源、图片源、样式源等资源范围。若配置合理，即使页面中存在部分注入点，攻击脚本也可能因来源不被允许而无法执行。

5.4.2 非法脚本限制

较严格的策略可以禁止内联脚本、限制动态加载行为、降低 eval() 类接口的可用性。这样能压缩攻击面，阻断许多依赖内联执行的典型载荷。

Cookie 配置对 XSS 后果的大小有明显影响。即便漏洞未完全消除，合理的 Cookie 属性也能减少会话被滥用的概率。

5.5.1 HttpOnly

启用 HttpOnly 后，客户端脚本无法直接读取相关 Cookie，这有助于减轻会话信息被窃取的风险。不过它并不阻止脚本以当前用户身份发起同源请求。

5.5.2 SameSite

SameSite 用于限制 Cookie 在跨站请求中的发送方式，可减少部分跨站场景下的滥用。它对 XSS 本身并非直接修复，但能降低会话在跨站链路中的暴露面。

5.5.3 Secure

Secure 属性要求 Cookie 仅在 HTTPS 连接中传输，有助于避免在不安全网络环境中被截获。对于涉及登录态的站点，这通常是基础配置之一。

6 检测与测试

6.1 手工测试方法

人工测试通常从输入点、输出点和上下文三方面入手，观察页面是否存在未转义回显、危险 DOM 操作或异常执行迹象。

6.1.1 典型测试向量

测试时常会输入包含特殊符号、标签结构或事件属性特征的内容，以判断页面是否对其做了正确处理。若输入在页面中被原样展示、部分解析或引发异常响应，便值得进一步分析。

6.1.2 页面上下文分析

同样一段输入，在文本节点、属性值、脚本内部或 JSON 结构中的风险不同。因此测试时需要确认数据最终落在哪个上下文中，而不是只看“是否回显”。上下文决定了适用的编码方式，也决定了可利用程度。

6.2 自动化扫描

自动化扫描器可以快速发现大量疑似注入点，适用于初筛和回归测试，但通常不能完全替代人工判断。

6.2.1 扫描器原理

这类工具会向目标页面注入探测载荷，观察响应是否发生回显、解析变化或 DOM 行为异常，并据此判断是否可能存在 XSS。部分高级工具还会结合浏览器环境动态分析前端脚本。

6.2.2 误报与漏报

由于页面模板、前端框架和防护策略差异很大，扫描器容易把“已正确转义的回显”误判为漏洞，也可能漏掉需要特定交互条件才能触发的 DOM 型问题。因此，扫描结果通常需要复核。

6.3 代码审计

代码审计适合从源头发现危险模式，尤其能识别那些在测试阶段不易触发、但逻辑上已经存在的漏洞。

6.3.1 危险函数识别

审计时重点关注会直接解释 HTML 或执行字符串代码的接口，例如将用户数据写入 HTML 解析型 API、脚本拼接点或动态模板位置。凡是“把字符串当代码”的地方，都应优先检查。

6.3.2 数据流追踪

通过追踪用户输入从入口到输出的路径，可以识别哪些变量会流入浏览器可执行上下文。若缺少编码、净化或类型限制，便说明链路中存在潜在风险点。

7 典型案例与演示

7.1 常见漏洞示例

XSS 的典型场景往往出现在看似普通的交互模块中，如搜索、评论和个人资料展示等。

7.1.1 搜索框反射注入

搜索框常会把“你搜索了什么”显示在结果页顶部。如果开发者将搜索关键词直接拼接到 HTML 中，攻击者便可通过构造特殊查询使脚本在结果页中执行。由于链接传播方便，这类问题常伴随钓鱼式扩散。

7.1.2 留言板存储注入

留言板、评论区和论坛帖子是存储型 XSS 的高发区。攻击者提交的内容在发布后被长期保存，其他访客浏览时就可能触发。若目标页面还支持富文本编辑，风险通常更高，因为更多标签和属性会参与渲染。

7.2 前端框架中的注意点

现代前端框架在默认情况下通常具备一定安全措施，但不当使用仍会引入风险。

7.2.1 动态渲染风险

当应用通过模板动态渲染 HTML，或在组件中主动绕过转义机制时，风险会显著增加。特别是在展示富文本、第三方内容和用户生成内容时，应避免把不可信字符串直接交给危险渲染接口。

7.2.2 第三方脚本引入

外部统计、广告、客服或插件脚本一旦被篡改，可能成为新的执行入口。即使站点本身没有明显输入点，供应链式脚本风险也会让页面遭受间接 XSS 影响，因此应控制来源并做完整性校验。

7.3 安全编码实践示例

较稳妥的做法是：数据与代码分离，文本与结构分离，输入与输出分离。渲染用户内容时尽量采用框架默认转义；必要时用经过审计的富文本净化器；对跳转地址、属性值和脚本上下文分别使用正确编码；对高风险页面配置 CSP 和安全 Cookie。整体上，防御应以“减少可执行面”为原则，而不是依赖单一过滤规则。

8 相关概念

8.1 CSRF 与 XSS 的关系

CSRF 是借助用户已登录状态发起非授权请求，重点在“伪造操作”；XSS 则是让恶意脚本在受害者页面中执行，重点在“获得脚本能力”。二者常被放在一起讨论，因为 XSS 能帮助读取令牌、提交表单或自动触发请求，从而增强 CSRF 的效果。

8.2 SQL 注入与 XSS 的区别

SQL 注入针对的是后端数据库查询语句，目标是让服务器执行攻击者构造的 SQL；XSS 则发生在浏览器端，目标是让页面执行脚本。前者偏向服务器数据层，后者偏向客户端执行层，防护思路也分别以参数化查询和输出编码为核心。

8.3 SSTI 与 XSS 的区别

SSTI 即服务器端模板注入，攻击者利用模板引擎把输入当作模板语法执行，影响通常发生在服务器端；XSS 的执行位置在浏览器端。两者都涉及“输入被当成代码”，但所处环境、危险函数和利用结果明显不同。

8.4 SSRF 与 XSS 的区别

SSRF 利用服务器代替攻击者向内网或外部资源发起请求，核心是网络访问能力；XSS 则利用浏览器在用户会话中的脚本执行能力。前者偏重服务端出站请求，后者偏重前端上下文劫持，虽然都可能用于信息探测，但攻击面和修复重点并不相同。