XSS绕过实战指南：从编码原理到防御全解析

写这篇的原因是，我自己早期学XSS的时候，走了太多弯路。网上大多数资料只会丢payload列表，告诉你“这样打就完事了”，但没人讲清楚为什么能绕过、什么时候无效、以及真正决定绕过成败的那几步判断到底怎么做。后来做了一段时间的实际测试和防护审计，才慢慢整理出一套自己的判断逻辑。这篇把多年积累的XSS绕过姿势、触发原理和排错思路全部摊开来讲，从零基础视角切入，但内容深度也适合已经入门的同学用来补全自己的武器库。

如果你眼下正卡在“明明payload没错，但就是不弹窗”或者“过滤规则一变就不知道怎么打了”，这篇就是给你准备的。

1. 认知起点：绕过的本质不是对抗过滤，而是争夺解释权

很多初学者有一个误区，觉得绕过XSS过滤器就是不断堆更复杂的payload，像是魔高一尺道高一丈的拼刺刀。其实不是。绕过的本质比这个优雅得多：你和防御系统在争夺对同一段字符串的最终解释权。

一段数据进入Web应用之后，至少要经过几层处理才落到浏览器里。服务端可能先做输入校验、过滤、编码、截断，输出时又有各种模板引擎的转义，浏览器收到之后还要按HTML解析器、URL解析器、JavaScript解析器的规则分别去解释。每一层都有自己理解的“语言”，关键问题在于：你的payload最终被哪一层解释，用什么字符集解释，解释完剩下什么东西。

理解这一点之后，所有绕过姿势都可以归结为同一个思路：找一个过滤规则没覆盖到的解释层，把恶意代码藏进去，等更内层的解析器把它还原出来。

举个直白的类比。一座仓库门口有安检，检查员只检查纸箱外有没有写“危险品”三个字。你往纸箱里塞一个贴着“易碎品”标签的小盒子，小盒子里面才是真东西。检查员放行了，仓库内部的人拆开小盒子才知道原来是危险品。服务端过滤器是门口检查员，浏览器内部的各个解析器是仓库里负责拆箱的人。你每次要做的，就是找到那个“检查员不查，但拆箱人会认”的包装方式。

理解了这一点，下面所有姿势就不是死记硬背的payload集合，而是你自己可以推演出来的方法分支。遇到任何新过滤器，你都可以先问三个问题：

• 这个过滤器作用在哪一层？它过滤的是原始输入、解码后的数据、还是输出渲染后的数据？
• 我输入的数据随后会进入哪个上下文？HTML标签里、属性里、JS字符串里、URL里，还是CSS里？
• 浏览器从接收到渲染要经过哪几次解码？有哪些解码结果过滤器没算到？

这三个问题，才是XSS攻防的真正主线。后面的每一节，都是这条主线上不同节点的展开。

2. 编码绕过：所有编码都是包装纸，关键是过滤器拆到哪层停手

编码类绕过，是入门XSS时最早接触、也最容易被低估的一类姿势。我见过的初学者常犯的错误是：把所有编码方式堆在一起乱试，%3C,\u003c,<,<,<……一把梭，问为什么不生效，没人能答上来。这就是典型的没有建立“解码链路”观念。

2.1 先搞懂你面对的是哪种解码器

Web里有几套互不相通的编码体系，而且它们只在特定的解析器里生效。这里列一个简洁的对应关系，建议先刻在脑子里：

每一种编码，只有在对应解析器里才有意义。你把\u003c直接放进HTML文本节点，浏览器不会把它当成<来解析；你把<直接放进JS字符串里，它也不会自动变成<。所以编码绕过的第一步，不是选编码，而是先判断你的数据落点落在哪个解析器管辖范围。

有次我测一个搜索框，输出被原封不动反映到页面的<title>标签里，试了一整轮%3Cscript%3E和\u003cscript\u003e都没反应，当时差点以为过滤很强。后来才反应过来，<title>是HTML文本解析上下文，URL编码和JS转义在那一层根本不会被还原，只有HTML实体编码才会被解析器翻译成尖括号。

2.2 多层解码的叠罗汉效应

真正的难点在于，很多数据不是只经过一次解码。服务器可能在接收时对输入做一次URL解码，模板引擎又对输出做一次HTML实体转义，浏览器随后再做一次HTML实体解码。如果其中有任何一层过滤器只检查解码前的原始形态，或者只检查解码后的最终形态，就可能留下解码链路中的时间差漏洞。

实际操作中我总结了一个固定套路：对你的payload做双重或三重包装，让最外层的包装属于过滤器认识但也容易被内层解码还原的那一类。经典的例子是：

%3Cscript%3E

这里的%是%的HTML实体编码。浏览器解析HTML时先把它还原成%，于是整个值在后续URL解析阶段又变成%3Cscript%3E，再被URL解码还原成<script>。如果过滤器只查了一层，看原始输入时发现没有尖括号和script字样，直接放行，等于你成功用叠罗汉骗过了安检。

类似的组合还有：在JS上下文中，把字符做\u转义之后再对反斜杠本身做HTML实体编码。过滤系统如果只做正则去匹配\u003c字样，就可能被\u003c这类形态混淆，因为浏览器先把\还原成\，JS引擎随后才把\u003c还原成<。

2.3 编码绕过的三个实操判断节点

这里给出我每次遇到编码场景时都会走的检查清单，用于快速判断哪些编码组合值得尝试：

1. 先确认输出点上下文。文本节点、属性值、JS字符串、URL参数、CSS值，这五类上下文决定了初始编码方向。
2. 再确认到达输出点之前经历了哪些转换。去看服务端有没有urldecode、htmlspecialchars、stripslashes这类操作，模板有没有二次转义，数据库存储是否做了额外的字符集转换。每一层转换，都是一次可以用来藏东西的机会。
3. 最后做验证时不要只试一次。正确的验证方式是逐层手动解码：把payload按照你推测的解码顺序亲手解一遍，如果最终能还原出<script>、javascript:或onerror=，那这条链路就是通的。

编码绕过的本质，不是“多套几层总有侥幸”，而是你能够复现浏览器完整的解码流程图。能复现，你就能找到过滤盲区；不能复现，你只是在掷骰子。

3. 标签与属性姿势：从“找标签”变成“找解析器的宽容度”

很多人一提到XSS就只会说<script>和<img onerror>，但实际测试里，你会发现<script>是最容易被拦的，<img>的老套payload也早被各种黑名单盯上了。标签层面的绕过，真正有价值的是站在HTML解析器视角去思考：哪些标签的解析方式天然给攻击者留了空间？

3.1 不带script字样也能执行JS的标签家族

HTML里能触发脚本的标签远不止<script>。常见的可执行脚本标签包括<img>、<svg>、<video>、<audio>、<body>、<input>、<details>、<math>等，关键在于配合事件属性或特殊的自动触发机制。为什么有些标签反而好打？因为它们不需要用户交互就能触发，或者触发条件在解析阶段就满足了。

一个很典型的场景是黑名单过滤了常见的事件名，比如把onerror、onload都换掉了。这时候<details>配合ontoggle往往有用，因为很多过滤器根本没有把ontoggle写进黑名单。同样的逻辑，<marquee>的onstart、<video>的oncanplay、<audio>的onplay也都能用。原理很简单：黑名单永远追不齐所有事件属性，而HTML规范允许的事件属性有上百个。

3.2 属性值的闭合与“不闭合”策略

属性闭合的经典形态是：

"><svg/onload=alert(1)>

这行的意思是，提前用双引号闭合前面的属性，再用>关闭当前标签，然后自己构造一个新的<svg>标签并配合事件属性执行脚本。这是最基础的思路，但实际测试中经常会遇到两种情况让它失效：

第一种，开发者做了引号转义，把双引号变成了"。此时可以尝试单引号，或者尝试不闭合引号，而是利用某些属性允许“非法字符”被解析器自动跳过。比如：

' autofocus onfocus=alert(1) x='

这段在不闭合引号的情况下，通过autofocus让元素自动获得焦点，onfocus立刻触发，后面的x='只是用来吞掉原来的闭合引号。这种技巧在过滤引号的场景里特别好用，因为攻击者根本不需要输出一个干净的引号。

另一种情况更隐蔽，过滤器把尖括号也处理了，属性值里不能构造新标签。这时候就不能把攻击点放在创建新元素上，而是利用当前元素本身的属性和事件。比如输入被插到一个<div>属性链里：

<input value="用户输入" id="x">

如果输入没做输出编码，可以直接构造：

" onmouseover="alert(1)

输入里的引号闭合了value，后面补了事件属性，再补一个引号让属性链继续闭合。整个过程没有新标签、没有尖括号，只靠拼接事件属性完成注入。这种“在原标签内部做文章”的思路，在过滤器对尖括号严防死守时非常重要。

3.3 语法噪音也能救命：空格、换行、注释的解析规则

HTML解析器在标签和属性名的识别上有相当高的宽容度，大量不可见字符和格式字符可以混进标签结构里，而浏览器根本不在乎。这意味着过滤器里的正则如果写得太严格，很容易被这些噪音字符拆碎绕过。

常见的可插入字符包括：水平制表符（\t）、换行符（\n）、回车符（\r）、以及各种Unicode空白字符。比如：

<svg\nonload=alert(1)>

标签名和属性之间的正统语法是空格，但换行符同样被HTML解析器当作合法分隔符。过滤器如果只匹配<svg onload这种带空格的模式，而对换行版本没做映射，这一条就直接穿过去了。

我早期做渗透测试时，遇到过一次过滤规则相当严格的情况，把常见标签和事件属性全部替换成空。我当时的突破点就是用注释符<!--切断了标签名，构造出这种形态：

<scr<!-- -->ipt>alert(1)</scr<!-- -->ipt>

HTML解析器在读取标签名时看到<scr，随后进入注释状态跳过中间内容，直到遇到>后恢复，最终解析出的标签名依然是完整的script。过滤器的正则匹配的是原文，它看到的script被注释切成了两半，自然匹配不上；浏览器却不这么认为，它在语法分析时把注释部分当作token之间的空隙忽略掉了。这个思路后来被我扩展到属性名和事件名上，只要HTML允许的空白和注释位都能做文章，效果出奇地好。

值得注意的是，注释绕过对现代浏览器的部分标签场景不一定总是生效，因为不同标签的解析容错细节有差异，所以测试时必须现场验证，不能看完一篇资料就认定某个姿势在所有浏览器里都通用。

4. 脏数据与大写小写、字符集的边角料利用

很多人在过滤器面前容易犯“洁癖”，payload看起来不够干净就觉得不该试。实际上，大量绕过恰恰是靠脏数据完成的。脏数据本身的恶意代码不多，但它本质上是用来扰乱过滤器判断的噪音信号。

4.1 大小写混写真的过时了吗

有一种说法是，大小写绕过早就被所有过滤器防住了。这个说法不完全对。确实，大部分现代过滤器都加了strtolower一类的规范化步骤，对<sCrIpT>这种直接大小写混写做了处理，但问题在于：过滤器的规范化经常只做一层，而且不一定覆盖到所有解析阶段。

我实际测过不少系统，虽然服务端做了小写化，但输出模板在渲染时使用的是原本输入。也就是说，如果过滤发生在A阶段，而模板最终输出的是B阶段的原始值，大小写混合依然能钻空子。另外，事件属性名在HTML里也是大小写不敏感的，oNeRrOr、ONERROR、OnError都能触发，完全没必要只写小写。所以我的建议是：大小写混写不必作为首选姿势，但是不能把它从测试字典里删掉，尤其是遇到自定义黑名单过滤器的场景，先花30秒试一遍大小写组合的成本非常低。

4.2 空白字符和控制字符的“隐形武器”

XSS过滤器的本质大多是基于正则表达式的黑名单匹配。黑名单的弱点在于：它只能匹配预先写好的字节序列，遇到“长得像但不是它记住的那串”就会失手。而HTML规范对字符的宽松程度，正好给这种失手提供了海量机会。

举个例子。HTML标签属性之间的分隔符，按规范其实是“空白字符”（whitespace），而不是单纯的空格。哪些字符算空白字符？空格、换行、回车、制表符，还有Unicode里一大票像\u000B（垂直制表符）、\u000C（换页符）、\u00A0（不间断空格）之类的隐形字符。如果过滤器只挑空格和Tab做分隔符校验，用这些冷门空白字符替换一试就知道结果了。

控制字符也有类似效果。有些系统会直接过滤/、=等符号，但如果你用HTML实体把等号编码成=，再用前面说的多层解码链路还原，过滤器可能完全没感觉。脏数据绕过的核心，就是让过滤器的正则匹配不到一个“干净”的恶意token，但浏览器的解析结果依然能还原成那个token。

4.3 引号的“换一种写法”思路

过滤引号是常见防护措施，尤其当开发者知道自己的输出点在属性里时，他们总会对双引号和单引号做转义。但引号本身并不是属性的必需字符，HTML规范允许属性值不加引号。例如：

<input value=userinput id=x>

如果输入是onmouseover=alert(1)这样的内容，并且前边有空格分隔，它会被解析成新的属性。虽然没有引号包裹，很多浏览器照样能正常触发事件。当然，这要求输入位置恰好能构成属性分隔的形态，实际操作中需要根据输出上下文微调payload。

与此对应的是，现代浏览器对反引号在JS中字符串的识别让一些变体变得可用。比如事件属性里可以写：

onmouseover=alert(`1`)

这里用反引号完全避开单双引号，而且模板字符串在很多浏览器里等同于普通字符串，alert(1)照样能弹。如果过滤器把alert(1)这类经典形态全部拉黑，可以试着在参数里做点文章，比如alert(11)、alert(1+1)、alert(document.domain)，这些变体都不是黑名单能覆盖完的。

4.4 大小写之外：同形字符与全角半角

还有一个经常被忽略的向量是Unicode同形字符。字母a、s、c这些字符有各种看起来一模一样的全角形式，比如ｓｃｒｉｐｔ。大多数过滤器的正则只匹配ASCII字符，遇到全角字符直接放过。但是，如果服务端和浏览器的字符集处理环节存在转换，比如UTF-8转UTF-16再转UTF-8，全角字符可能在某个转换环节被标准化成ASCII，导致你的全角payload最后被浏览器还原成真正的标签名。这个技术点在实际利用中有时受到浏览器和中间件的多种条件限制，稳定性不一定好，但它属于那种“测一下不亏，试出来就是大突破”的姿势。

对于初学者，我的建议是：不必把这些脏数据姿势背到滚瓜烂熟，而是建立一张“过滤器可能不会算进去的字符表”，每次卡住了就挨个替换，效率远高于死磕单一payload。

5. 语义分割与无中生有：把长payload化整为零

长度限制和敏感词过滤经常联手出现，很多系统直接限制输入长度，导致完整的<svg onload=alert(1)>根本贴不进一个字段。这种时候，有效的方法不是压缩payload，而是利用HTML解析器的容错机制把payload分拆到多个字段或多次请求里。

5.1 利用form属性实现跨元素关联

HTML5引入了form属性，允许一个表单控件（比如input、button）挂在页面上的任意表单之下，只要form属性的值与目标表单的id一致。这个特性有一种很刁钻的用法：把真正的可执行片段分散在多个输入点，再利用浏览器支持跨元素关联的特性把它们串成一个整体。

考虑一个场景：站点允许多个字段分别输入，但每个字段都有长度限制和敏感词过滤，任何单一字段都无法承载完整的XSS payload。你可以把payload拆成两部分，一个输入点写入id=x和表单关联信息，另一个输入点写入事件触发器。虽然单看每一段都不完整，但浏览器解析后会把它们拼在一起触发完整逻辑。

5.2 利用标签的自动闭合特性拆分属性

某些标签的属性在解析时遇到特定字符会自动闭合或被忽略，攻击者可以借此把payload放在一个看似无害的属性值里。比如：

<svg/onload=alert(1)>

这里svg后面紧跟/，再跟onload属性。/在标签内表示自闭合标记，浏览器允许<svg/>后直接接属性，然后遇到>时完成标签闭合并触发onload事件。整个payload短、没有空格、没有引号，非常适合长度受限和空格被过滤的场景。

类似的短payload还有：

<svg/onload=alert(1)//

结尾的//在HTML里代表注释开头，实际上它只是让标签在语法上显得更完整。这种形态是我在长度限制比较严格的情境下经常优先测试的。

5.3 多次存储，二次拼接

还有一种思路在存储型XSS里特别有用：利用站点的多个存储点，把payload分成几段，每段自身是安全的、中性的文字，但在特定页面渲染时，几段的边界正好拼成一个完整的攻击载体。

举例来说，某个评论区允许用户输入URL和昵称，服务端分别把它们插入到同一个<a>标签的不同位置。昵称作为链接文字，URL作为href值。如果昵称控制在“闭合属性”的位置，URL控制在“事件属性”的位置，两个字段单独看都是无意义的字符串，合在一起就是一个完整的注入。这种攻击链不依赖任何危险字段的长度，只需要你对目标页面的输出结构足够了解。

我遇到过一次真实情况，某个功能把用户输入的“标题”输出在页面的<a title="...">里，“描述”输出在其他属性位。我利用标题字段插入右引号和空格，再用描述字段补上事件属性，成功拼出了一个不落地在任何一个字段里的完整注入。那次之后我意识到：存储型XSS的绕过，对象不是过滤器，而是整个页面组装逻辑。

5.4 过滤alert等函数名时怎么办

很多防护系统把常见函数名如alert也拉进了黑名单。此时可以通过间接调用来绕过。最简单的思路是使用confirm、prompt这些同样能弹窗的函数，因为黑名单往往只覆盖alert这一个最知名的名字。如果没有弹窗需求，只是想确认XSS存在，也可以用console.log、fetch、甚至throw 1来触发可见行为。

另外，可以通过给函数名补充无害的语法成分来避免直接命中黑名单：

alert(1) alert (1) alert(1+1) (window.alert)(1) top["al"+"ert"](1)

这些变体一次一次试，总有一个会绕过只看固定字样的过滤器。值得留心的是，有些过滤器会做“去除空白再检查”的预处理，所以alert (1)这种中间带空格的形态不一定有效；但表达式拼接的方式，比如top["al"+"ert"]，在字符串真正执行之前不会拼出alert，所以对很多黑名单来说反而是硬杀器。

6. 输出位置决定打法：上下文专项绕过

很多初学者最大的盲区，是不知道同一条payload在不同上下文里的命运完全不一样。如果不先判别输出位置，直接套payload模板，经常会白白浪费时间。这一节我把最常见的几个上下文场景拆开来讲，每个场景的绕过策略差异非常大。

6.1 HTML元素内的文本节点

如果用户输入直接出现在<div>、<span>、<p>等标签的内部，那么最直接的目标就是跳出文本区域，创建新标签：

<div>这里插入用户输入</div>

此时payload可以是：

<svg onload=alert(1)>

但如果尖括号被编码或过滤，就不能走这个方向，需要另想别的路。文本节点的本质是：除非能闭合当前标签并开新标签，否则事件属性不会生效。若无法突破尖括号，可以确认是否存在其他方式触发危险操作；如果确实没有，那么这里唯一能做的就是尝试前面提到的各种HTML实体编码或脏数据组合，看能否骗过过滤器还原尖括号。

6.2 HTML属性内部

属性上下文比文本节点更灵活，因为你不一定需要创建新标签，只要把当前标签改造成一个可执行事件的形态即可。比如：

<input type="text" value="用户输入">

如果用户输入被原样输出在value属性值里，可以构造：

" autofocus onfocus=alert(1) x="

这样autofocus让输入框自动聚焦，onfocus立刻执行，最终实现无交互点击的触发。

属性上下文中最大的敌人是引号被转义，所以无引号属性值的利用思路尤其重要。如果开发者使用htmlspecialchars把双引号转义成"，HTML解析器会把它还原成引号，攻击者依然可以利用；但如果服务端在存储层把引号替换成了全角引号或其他字符，那这条路就不通。

6.3 JavaScript代码字符串内部

这是最容易出成果也最容易翻车的上下文，因为浏览器执行JS时，对转义字符的宽容度很高，而对过滤器的判定却常常留下缺口。一个常见输出形态是：

var name = "用户输入";

如果输入没有被正确地JSON编码或转义，直接可以闭合字符串并拼接语句：

";alert(1);//

很多时候开发者会把双引号和反斜杠做转义，但没处理</script>闭合标签的问题。于是我们可以不走JS拼接的路，而是直接闭合当前<script>标签：

// 输入：</script><script>alert(1)//

这种“先闭合再开新块”的技巧，在过滤器只针对JS关键词做检查时非常高效，因为尖括号和标签名往往不在JS过滤器关注的范围内。

JS上下文里，Unicode转义是绝对的宝藏。因为JS引擎会在字符串被解析之前先处理\u开头和\x开头的转义序列，而过滤器的正则如果只匹配可见的危险词，看到\u0061lert时是匹配不到alert的。下面是一段实际测试中很好用的形态：

\u0061lert(1)

需要注意的是，这种转义方式只在JS字符串和JS标识符解析阶段有效，不能直接用在HTML属性里。

6.4 URL字段与javascript:协议

当用户输入被直接放进<a href="...">或location.href时，绕过的关键就是构造javascript:协议。常见的基础payload是：

<a href="javascript:alert(1)">

很多过滤器会拦截javascript:这个关键词，可以用大小写、URL编码、换行制表符来拆分。一个被广泛使用的技巧是：

javascript:alert(1)

HTML解析器在读取属性值时先做实体解码，把s还原成s，随后URL解析器和JS解析器才看到完整的javascript:。如果过滤发生在HTML实体解码之前，它就拦不到这个形态。

另外，href属性在接受HTML实体之后还会经过URL解析，而URL解析器允许很多字符被忽略，比如：

java%0ascr%0aipt:alert(1)

在部分浏览器的历史版本中，%0a这类URL编码换行符会被忽略，导致最终识别为javascript:协议。现代浏览器对这个粒度的容错有所收严，所以这条不一定通，但它揭示了URL上下文特有的测试方向：不能只看服务端过滤，还要看浏览器URL解析器自己的“清理规则”。

6.5 CSS上下文与样式属性里的旁门左道

CSS上下文相对冷门，但对绕过者来说很有价值，因为很多系统的CSS过滤器形同虚设。如果用户输入被放进style属性，可以尝试：

<div style="background:url('javascript:alert(1)')">

现代浏览器大多不允许CSS里的javascript:协议执行，但历史版本的浏览器或某些老旧Web视图组件仍可能触发。更实际的是利用CSS表达式（仅在旧版IE中生效）：

<div style="width:expression(alert(1))">

这个在今天的测试中基本不推荐，因为现代环境很难复现。比较有现实意义的是，CSS上下文可以用来做钓鱼和数据窃取，比如通过url()外带信息。从XSS角度看，CSS上下文通常不是首选，但它提醒我们：任何输入位置都值得花时间推导，而不是只盯着HTML和JS。

7. 存储生命周期与二次触发：别只盯着一次反射

反射型XSS的整个生命周期很短：输入、输出、触发，一气呵成。存储型XSS则完全不同，它的payload可以进入数据库，等到其他用户访问某个页面时才被组装、输出、触发。这中间的延迟和组装过程，为绕过提供了更多操作空间。

我第一次做存储型XSS测试时，卡了很久。原因是服务器端有很强的输入过滤，直接在提交阶段就把尖括号、引号全部转义了。按照反射型的思路，我在提交接口怎么试都不弹窗。后来我仔细梳理了数据的生命周期，发现过滤发生在“写入数据库之前”，但输出到页面时用的模板只做了简单的拼接，并没有再次做HTML实体转义。也就是说，攻击者只要能在提交阶段让数据“活着”进入数据库，后续的渲染环节根本不再设防。

这个场景下，最有用的姿势就是前面讲过的双重编码：把尖括号、引号做HTML实体编码，让过滤器盯不到“原生弹药”；但只要数据通过实体解码输出到页面，浏览器自然会把它们还原成可执行的标签和属性。过滤器在输入端拦的是<、>、"，它完全没考虑HTML实体的还原问题。

存储型XSS的二次触发还有一个反射型没有的优势：payload不一定要在提交的当下看起来完整。很多系统会把用户输入分段存储到不同字段，一个字段填“前半个payload”，另一个字段填“后半个payload”，最终页面渲染时，二者恰好拼接成一个完整的执行链。这种“拼接型绕过”极度依赖页面结构，但对过滤非常有效，因为单段数据可能在语义上完全无害。

做这种测试时我养成了一个习惯：发现有多个输入字段时，不要挨个测，而是先花时间把目标页面的输出模板完整逆向出来，弄清每个字段分别插到哪个标签的哪个位置。只有模型清楚了，才能设计出跨字段拼接的最优形态。

8. 常见问题与排查技巧实录：为什么我的payload死活不弹

到这一节，我写几个自己反复踩过、也最常见于初学者的问题，直接给排查思路。把这些问题对照着看，能让你的测试效率高很多。

8.1 我的payload在本地HTML文件里能弹，放到目标站点就不行

这是最常见的困惑。首先要意识到，本地HTML文件的上下文是纯净的，没有经过服务端过滤、模板转义、字符集转换、浏览器安全策略干预。放到目标站点不弹，不代表你的payload思路是错的，而是你的payload没能在完整链路中维持到最后。排查步骤：

1. 打开浏览器开发者工具，查看最终渲染的HTML源码，确认你的输入被输出到哪个位置，被加了什么前缀和后缀。
2. 用“右键查看源码”而不是“检查元素”，因为这个页面可能是动态DOM拼接的结果，源码才能反映服务端真正的输出。
3. 把源码截下来，手写一遍“浏览器将会如何解析它”，找出你没想到的转义或编码。

8.2 过滤了script关键词，但我拼不出有效payload

优先检查过滤方式。如果只是简单替换成空字符串（比如preg_replace('/script/i', '', $input)），可以用双写绕过：

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

替换掉中间的script后，剩下的正好是完整的<script>标签。如果过滤是替换成“安全”的占位符，双写就不奏效了，需要换用其他标签或属性方向。

8.3 单引号双引号都被转义，属性闭合打不进去

这种时候不要继续硬磕引号，转向无引号属性或者实体编码引号。无引号属性形态推荐先试：

<svg/onload=alert(1)>

如果事件属性名也被过滤，就用事件属性字典轮换测试。如果有长度限制，试着把payload拆开，利用同标签多属性和存储拼接。

8.4 事件属性被执行了，但alert被拦截

拦截函数名是现代过滤器的常见策略。解决办法是换函数，prompt、confirm在大多数浏览器同样弹窗；或者用表达式拼接：

<svg/onload=top["al"+"ert"](1)>

这种形式在执行之前，["al"+"ert"]还没被拼成字符串字面量，过滤器如果只查完整词，就匹配不到。

8.5 输出在<textarea>或<title>里，标签注入无效

这两个上下文的特殊之处在于，浏览器会进入“特殊元素”解析状态，不会识别标签内部的事件属性，直到遇到闭合标签才会回到普通HTML解析状态。所以正确的操作顺序是：先闭合当前标签，再输出新的标签和payload：

</textarea><svg onload=alert(1)>

如果过滤器对</textarea>做了处理，可以尝试HTML实体编码闭合标签，或者利用前面提到的多层解码链。

8.6 用CSP挡了内联执行，还有什么思路

现代站点如果配置了严格的CSP（Content-Security-Policy），很多内联payload会直接被策略拦下，这时传统标签+事件属性的招数基本失效。能走的方向包括：寻找CSP白名单里允许的外部JS文件域名，利用JSONP接口或上传可控JS文件；如果CSP里允许unsafe-eval，eval相关链路还有机会；实在不行就标记为“CSP限制下暂不深入”，转去测其他无CSP的页面。做XSS测试时，先看响应头的CSP字段，比什么都重要。

8.7 速查表：过滤特征与应对方向

9. 配套的防御收口：打完记得帮自己补漏洞

绕过了这么多东西，反过来看防御其实也能很清楚。每次我做完一轮测试，都会顺手帮目标把防御短板列出来，这既是对自己工作的负责，也是理解绕过的另一种训练方式。

第一道防线是输出编码。不要依赖输入过滤来防XSS，因为过滤总有盲区，而且维护黑名单的成本极高。正确做法是：在任何动态内容输出到HTML上下文时，根据上下文选择正确的编码方式。HTML实体编码用于HTML文本节点，HTML属性编码用于属性值，URL编码用于URL，JS字符串的JSON编码用于JS上下文。上下文错了，编码就白做了。

第二道防线是白名单。输入校验尽量采用白名单思维，而不是黑名单。例如只允许数字、字母和有限符号，比“禁止尖括号”可靠得多。标签白名单配合事件属性白名单做过滤，能挡住绝大多数依赖事件属性的注入。

第三道防线是CSP。即使你的编码在某处遗漏了，CSP也能作为兜底层拦截内联脚本和远程脚本。把CSP的头设置好，把unsafe-inline、unsafe-eval都关掉，攻击面会立刻减小一大截。一个配置得当的CSP，经常比前三层过滤器加在一起都管用。

最后是定期用自动化工具加手工测试做安全自查。绕过姿势更新太快，靠记忆维护黑名单根本不现实。把目标应用当成自己的实验室，测完立刻修，修完再测，这是唯一能保持安全水位的方式。

我个人做了这么久安全测试，最大的体会是：绕过与被绕过的关系永远在动态演化，没有一招鲜的万能payload，只有对解析链路、上下文模型和浏览器规范的持续理解。当你能够熟练地判断一段数据会经历哪些解码、落进哪个解析器、最终被浏览器还原成什么，你的测试思路就完全不一样了。

如果这篇对你有帮助，建议不要只收藏了事。找个本地环境，把里面的payload按上下文分类，一个一个亲手测一遍，观察每种过滤下哪些姿势失效、哪些姿势还能用。实践中踩过的坑，才是你自己的武器库。