XSS这个知识点说简单也简单无非就是往页面里塞一段脚本但说复杂它可以从一枚alert(1)一路延伸到一个完整的攻击链。我刚入行那会儿也以为这题目太基础结果在真实项目里被一个文件上传点卡了半天才意识到自己对XSS的理解停留在会弹窗这个层面。后来认真做了一轮系统性复习把发现、利用、修复整条链路重新捋了一遍收获远比预期大。这篇就当是我自己的复习笔记也希望能帮到正在补这块知识的人。为什么XSS值得系统性复习而不是背几个payload1.1 XSS在真实攻防中的定位很多人在复习XSS时容易陷入一个误区刷几个payload能在靶场里弹个窗就觉得过关了。但实际情况是XSS在不同的场景里表现完全不同。比如在CTF比赛中XSS频繁和CSRF、越权、DOM Clobbering组合出场在渗透测试里XSS往往是从一个低危信息泄露升级到存储型蠕虫的跳板在开发修复时XSS又是最能体现过滤不如编码、黑名单不如白名单这一原则的典型漏洞。我后来发现真正重要的不是记住多少个Payload而是建立起一条完整的思考链用户输入在哪个位置进入页面进入时经过了什么样的过滤或编码这个上下文里浏览器会如何解析它被解析后能做什么这条思考链在面试、实战、代码审计中都能复用。所以我把这次复习的重点从记忆转向推理从利用转向理解边界。1.2 一套可复用的复习路线我给自己定的复习路线分四层这一整套走下来才敢说自己对XSS复习过第一层搞清楚三类XSS的本质区别以及它们在请求中的位置。第二层自己做实验把过滤条件一个个拆掉观察浏览器在不同上下文中的行为。第三层回到真实项目场景想清楚一个XSS从被发现到被修复的完整闭环。第四层把防御机制过滤、转义、CSP、HttpOnly、SameSite每一条都落到实际代码上而不是停留在概念里。下面我把这四层拆开来讲每部分都会带上我实际操作中踩过的坑和验证过的思路。三种XSS类型的边界反射型、存储型、DOM型2.1 反射型请求参数是唯一舞台反射型XSS最常见也最好理解。它的核心特征是服务端从请求参数中拿数据拼接进HTML响应再直接返回给客户端。整个过程没有落库所以被称为反射。判断一个注入点是否为反射型我用过一个很朴素的方法把参数值改成一个独特字符串比如xsstest2024然后看响应HTML里这个字符串出现在什么位置。如果直接出现在p标签内容里那就要尝试闭合标签如果出现在input value...的属性里就要考虑通过双引号闭合后注入事件属性。我记得自己在某个本地Demo里测过一个搜索框它的HTML是这么写的p您搜索的关键词是strong${keyword}/strong/p直接提交scriptalert(document.domain)/script确实能弹窗因为浏览器解析HTML时script标签不会显示脚本会执行。但如果我们把目光放远一点这种场景其实有个很实际的问题如果过滤脚本标签但没过滤事件属性我们就应该改成img srcx onerroralert(1)。这就是同一漏洞多种利用姿势的第一步。我强烈建议在复习反射型时自己搭一个极简服务端Express、Flask或Spring Boot随便一个都行手动把参数拼进不同的HTML上下文然后逐个测试不同payload的触发条件。只看文档永远记不牢动手试一次就懂了。2.2 存储型持久化攻击的危害升级存储型和反射型的最大区别在于数据是否入库。评论、留言、昵称、文档标题、签名档这些只要能把内容保存到数据库下一次任何用户访问这个页面时都会被注入脚本。存储型之所以厉害一是因为它不需要诱导受害者点击一个精心构造的链接二是因为受害者的访问是自然发生的命中率极高三是它可以做持久化控制比如恶意脚本修改页面显示、自动发布新评论从而形成XSS Worm。我在靶场里专门对比过存储型和反射型的请求差异反射型的关键参数在URL里日志、WAF、流量分析都能看到存储型的恶意代码在数据库里URL看起来完全正常。这解释了为什么存储型XSS在企业内网、后台管理系统中往往危害更大——安全检测的盲区更多。2.3 DOM型不经过服务端的隐形攻击DOM型XSS是我在复习时花时间最多的一种因为它最反直觉数据根本不出现在HTTP响应里服务端全程不知道攻击发生。它的本质问题出现在JavaScript代码里。常见写法是const params new URLSearchParams(window.location.search); const name params.get(name); document.getElementById(greeting).innerHTML 欢迎 name;攻击者只需要构建一个恶意URL当用户打开这个URL时location.search里的攻击代码被innerHTML渲染成DOM节点脚本同样会执行。整个过程服务端没参与、数据库没参与、响应内容里也没有script页面在开发者工具里看到的源码也是正常的。复习DOM型时光看Payload毫无意义必须要读前端JS代码找到三条关键链路输入源(Sources) → 处理逻辑 → 危险出口(Sinks)。我列几个最常见的危险出口document.write()或document.writeln()innerHTML、outerHTML、insertAdjacentHTML()eval()、new Function()location.href、location.assign()setTimeout/setInterval的字符串参数每次看到这些方法我都会下意识地回溯它们的参数来源。如果参数来自location、document.referrer、postMessage、window.name就存在DOM型XSS的疑点。这个判断方式我现在做前端代码审计时还在用。触发点与Payload构造从闭合上下文到任意JS执行3.1 找触发点的思路复习到这一步我开始丢掉弹窗思维改用上下文思维。所谓上下文就是我们的输入最终落在HTML文档的哪个结构里。我常用一个快速分类表来整理输入出现的位置典型场景核心利用思路标签内容区p{输入}/p直接插入script或img onerror标签属性值input value{输入}闭合引号后插入onfocus、onmouseoverJavaScript字符串var name {输入}闭合引号和括号注入alert(1)CSS区域内style后面的值旧版本可通过expression()或url()利用URL跳转location.href {输入}使用javascript:伪协议这个表的意义在于把找触发点变成一种条件反射。看到输入位置先问自己是哪一类上下文然后再决定用哪一组payload去验证而不是把所有payload都试一遍。3.2 Payload构造的分层验证我在实际测试里会把payload分成三个层次去构造第一层验证漏洞是否存在。最稳妥的方式是用一个非破坏性、能明确看到执行结果的payload比如scriptalert(document.domain)/script或者img srcx onerrorconsole.log(xss)。这个阶段的目标不是证明危害而是确认输入确实被当作代码执行了。第二层验证可利用性。比如能否调用函数、能否读取cookie前提是cookie未设置HttpOnly、能否发送网络请求。这一层跟业务挂钩安全测试报告要写清楚攻击者能做什么而不是只有一个弹窗截图。第三层在修复防线面前验证绕过能力。这个放到下一节详细展开。我自己的习惯是不管在哪一层都不会直接使用带cookie读取、fetch发送的payload来做破坏性试验而是把证明过程停留在能执行任意脚本这个层面避免对测试环境造成不可控影响。3.3 编码在payload里的角色编码问题是我复习时收获最大的一块。很多人以为HTML解析里只有一层解码实际不是。浏览器解析HTML的时候会先做HTML实体解码再在特定上下文比如script标签里做JavaScript解析甚至还有URL解码。这带来了一个反直觉的结论很多Payload写在URL里和最终执行时的形态完全不同。比如URL里的一段内容如果被服务端原样拼入HTML并且目标位置在事件属性里那么URL编码、HTML实体编码甚至JavaScript转义都可能被逐层还原并执行。我之前在测试一个自定义搜索功能时输入被放到一个onclick事件中。直接写onclickalert(1)触发不了因为引号被转义成了quot;。但当我用HTML实体编码方式提交quot; onmouseoverquot;alert(1)时浏览器先把实体解码成双引号闭合了原有属性注入了新事件最终成功触发了XSS。这个案例让我彻底理解了一次编码不一定够用的道理。绕过过滤的常见思路与判断依据4.1 黑名单过滤如何被绕过复习绕过时我的态度是不是为了炫技而是为了理解过滤为什么会失效。黑名单方案在XSS防御里是最脆弱的因为攻击者的输入空间远大于防御者写死的名单。最常见的一类绕过是大小写变形比如ScRiPt在某些只做了小写匹配的过滤规则下能直接通过。更常见的是标签替换型过滤比如把script整体替换为空字符串此时双写scrscriptipt就能绕过因为过滤后剩下的恰好是script。我的做法是把绕过思路整理成一套变形矩阵用不同输入逐个尝试大小写变形ScRiPtalert(1)/sCrIpT双写绕过scrscriptiptalert(1)/scriptHTML实体编码#60;script#62;alert(1)#60;/script#62;标签混淆用svg onloadalert(1)、details open ontogglealert(1)、videosource onerroronerroralert(1)事件属性组合img srcx onerroralert(1)、body onpageshowalert(1)这里我想强调一个判断方法过滤一旦存在就会有回显的指纹。比如把script替换为空响应里多出来的字符长度会有差异如果直接拦截返回400/403那我们面对的就是WAF或应用层强制拦截。先根据响应行为猜测过滤规则再针对性构造Payload去验证比盲猜高效得多。4.2 不同上下文下的绕过变体我总结出三种最常见的绕过变体每一条都有自己的试验场景第一种是上下文混淆型。比如过滤了script标签但输入出现在属性值里时用 autofocus onfocusalert(1) x能绕开标签检测过滤了alert关键字时可以用\u0061lert(1)或top[alert]来拼接函数名。第二种是解析器差异型。HTML解析器在遇到畸形标签时会有容错性。比如svgscriptalert(1)/script在很多浏览器里可执行是因为SVG命名空间对script标签的处理和普通HTML不同。理解这一点后我在PortSwigger的题目里看到svg onload就明白这不是偶然而是利用了SVG内联事件。第三种是编码层层递进型。先用URL编码过WAF到服务端解码后进入HTML再经过HTML实体解码进入JavaScript解析。这种情况下Payload在每一层都是隐蔽的直到最后一步才还原成可执行代码。我在复习时用一个双重编码的案例验证过输入前: %253Cscript%253Ealert(1)%253C%252Fscript%253E 服务端第一次URL解码: %3Cscript%3Ealert(1)%3C%2Fscript%3E 渲染时浏览器解码: scriptalert(1)/script这种攻击链在真实项目里很难防御因为服务端如果只做一层解码过滤根本看不到最原始的攻击代码。4.3 判断能不能用的核心方法面对一个疑似存在XSS的输入点我不是一股脑地把payload全暴力试一遍而是按顺序走这几步确认数据流输入能否到达服务端或者是否只在前端被处理后端是否把数据原样回显确认输出位置响应HTML里输入落在哪里HTML标签内属性内还是JavaScript区域确认过滤策略尝试改变编码、大小写、闭合方式根据响应差异反推规则。确认执行环境目标浏览器有没有CSP策略HttpOnly是否生效SameSite是否阻止了跨站请求确认影响面如果能执行JS能读取哪些数据能调用哪些API能在什么权限范围内操作这套方法帮我避开了很多看起来能弹窗但实际无法利用的假漏洞。比如有的CTF题目虽然页面有alert执行但JSONP接口设置了大量CSP头根本没法外传cookie这时候正确结论应该是存在DOM-XSS但可利用性受限还得继续找绕过CSP的方法。靶场里的高频考点DVWA、Pikachu、PortSwigger、CTFHub5.1 DVWA三个等级的设计逻辑DVWA的XSS模块是我最推荐的入门复现环境不是因为它防护多严密而是因为它把黑名单过滤强度变化这件事讲得很直白。Low级别基本没过滤直接scriptalert(1)/script就可以。Medium级别用了str_replace把script标签替换为空但没考虑大小写、双写、事件属性所以用ScRiPt或img srcx onerroralert(1)就能过。High级别换成正则匹配/(script|php|...)/只针对部分标签但依然没防住img onerror或svg onload。我建议在DVWA上做三件事第一把每一个级别的payload都完整记录下来注明为什么能过、为什么被拦第二用开发者工具看网络请求的差异第三把High级别的代码读完理解它到底过滤了什么、漏了什么。做完这三步你会很自然地意识到黑名单防不住XSS这句话的真正含义。5.2 典型靶场考点横向对比我把几个常见靶场的XSS考点理成了一张对照表方便复习时按图索骥靶场特点高频考点DVWA等级递进清晰黑名单绕过、HTML实体处理Pikachu中文注释友好、贴近业务表单输入、URL参数、DOM型PortSwigger难度梯度大贴近真实场景上下文逃逸、CSP绕过、Angular模板注入CTFHub/CTFShow技巧导向编码绕过、DOM Clobbering、落地过滤Pikachu里的XSS题目和DVWA的最大区别是场景更贴业务不像DVWA那种纯教学页面。比如留言板、搜索框、个人信息修改这些场景更接近真实系统的输入点分布。我在复习时会把Pikachu的题目当成业务逻辑题来做先找出所有能提交并回显的位置再看每个位置的数据流。PortSwigger的XSS Lab是进阶阶段必须刷的。它的题目往往设计了复杂的上下文有的输入在script标签内部需要先逃逸出字符串有的在a标签的href属性里需要用javascript:伪协议还有的页面有CSP策略需要根据script-src里的白名单域名找绕过方式。这些题目和CTF比赛的出题思路很像。5.3 靶场练习的正确姿势我的刷靶场方式和大多数人可能不太一样同一道题至少做两遍。第一遍允许看提示目标是把题目跑通第二遍完全凭记忆和推理独立把payload构造出来并且要尝试至少三种不同解法。这种训练方式最大的收获是提高了payload构造的肌肉记忆。比如遇到输入在标签内时我的第一反应不再是script而是思考这个上下文有哪些标签可以执行JS有没有事件属性可以利用。在CTF里这种反应速度往往比掌握几个高级技巧更重要。另外强烈建议在靶场练习时同时打开Burp Suite或浏览器开发者工具观察每个请求的完整链路。很多选手刷题快却连这个payload最终是如何被浏览器解析的都说不清。我自己的习惯是每打完一道题就在笔记里画一遍数据流输入 → 过滤 → 输出位置 → 浏览器解析 → 执行。画完这个链路这道题才算是真正吸收了。真实项目修复SpringBoot全局过滤器与文件上传XSS6.1 SpringBoot全局过滤器的实现边界从靶场回到真实项目XSS的修复又是另一套逻辑。搜索热词里SpringBoot全局过滤器处理上传pdf文件时xss攻击反复出现说明很多人在这块遇到了实际问题。一个常规的SpringBoot全局XSS过滤器思路一般是用HttpServletRequestWrapper包装原始请求在getParameter()、getHeader()、getInputStream()等方法里统一做HTML标签清洗或特殊字符转义。然后再配合类似Jsoup.clean()的白名单过滤把script、iframe、事件属性等清掉。但这里有几个非常容易踩的坑第一个坑getParameter()只覆盖了URL参数和表单参数。如果接口使用的是JSON格式的application/json请求体过滤器的getInputStream()读取了一次输入流后续RequestBody反序列化时就可能因为流被消费而读不到数据。正确做法是把清理逻辑写成OncePerRequestFilter并用ContentCachingRequestWrapper缓存输入流或者结合Jackson的DeserializationFeature对JSON字段做递归清洗。第二个坑过滤器对上传文件无能为力。HttpServletRequestWrapper能清洗的是请求参数和请求体但multipart/form-data里的文件流并不会经过这些方法。如果业务里允许用户上传PDF、SVG、HTML文件那全局过滤器根本覆盖不到这个攻击面。这就回答了热词里处理上传PDF文件时XSS攻击的疑惑——过滤器只能拦截一部分真正的风险在文件本身。6.2 文件上传场景的XSS风险与修复文件上传导致的XSS常见的路径有两条。第一条是上传HTML/SVG文件。HTML文件本身就能包含scriptSVG本质是XML同样能嵌入脚本。这类文件只要被浏览器以text/html或image/svgxml类型加载攻击代码就会执行。修复思路是禁止直接访问上传文件或者强制以附件形式下载设置Content-Disposition: attachment并加上X-Content-Type-Options: nosniff防止类型混淆。第二条是PDF文件内嵌JavaScript。PDF规范允许文档包含JavaScript当用户用浏览器内置的PDF阅读器打开时脚本可以执行。很多项目只校验了文件扩展名是.pdf没有校验文件Magic Number攻击者把一个恶意PDF改名为.jpg或者伪造Content-Type上传很容易绕过去。修复方案的核心是不要以原始文件名和Content-Type作为唯一信任依据要校验文件头比如PDF的%PDF-前缀并把上传文件放到独立域名或对象存储中这样即使文件有问题也和主站应用隔离。我在处理这类问题时用过的一个组合拳是这样的服务端校验MIME类型、文件后缀、Magic Number三者一致。上传文件重命名用UUID当文件名避免用户可控文件名写入HTML或下载响应头。设置响应头X-Content-Type-Options: nosniff、Content-Disposition: attachment。对SVG这类高危文件类型直接设置为仅允许下载不在线预览无法保证安全时干脆禁止上传。加强CSP比如Content-Security-Policy: default-src none; sandbox限制所有上传资源的执行能力。这里还要特别提一句不要把过滤当成修复的全部。一个全局过滤器只能挡住一部分反射型/存储型XSS的注入入口但对文件型、DOM型、绕过CSP的情况必须配合输出编码和策略加固才能形成闭环。6.3 输出编码、CSP与HttpOnly的协同防御真正落地的XSS防御从来不是靠某一个组件而是靠多层协同。我的建议是把防线分成四层缺一不可。第一层是输入侧。能做白名单就用白名单能做类型校验就做类型校验过滤规则必须同时覆盖参数、Header、JSON Body和文件流。但永远不要假设这层能挡住所有攻击。第二层是输出侧。这是最容易漏的一层。HTML上下文中要转义、、和引号属性值上下文里要做属性编码JavaScript上下文里要做JavaScript转义URL上下文中要校验协议白名单。如果都转义了很多存储型XSS根本走不到浏览器执行那一步。第三层是浏览器侧策略。HttpOnly能防cookie被脚本读取但防不了XSS本身CSP能从策略层面限制脚本来源但对内联事件和javascript:伪协议的清理也需要单独配置。一个合理的CSP至少应该包含script-src白名单和object-src none。第四层是隔离侧。上传文件独立域名、资源加载用保守的CSP、管理后台强制使用独立部署和更强认证这些措施即便前几层被绕过也能把危害半径控制住。我在复盘真实项目时发现大多数XXS过滤器无效的case本质上不是过滤器本身写得不对而是整个系统把防御责任全压在了过滤器这一层。完美的情况应该是输入过滤负责减负输出编码负责保底CSP和HttpOnly负责兜底。这三层同时工作系统才谈得上对XSS有基本的防控能力。在我实际操作中的体会是复习XSS最忌讳只看篇幅不练手。从靶场上手理解漏洞原理再从真实项目反推修复方案两边走了一遍之后以后再看到输入点回显位置脑子里自动就会出现整条防御链的轮廓。这套思考方式比记住任何一条Payload都值。 
长河君 · 2026/9/24 18:55:21 · 阅读 1.2k XSS系统性复习：从三类漏洞原理到SpringBoot与文件上传实战修复
XSS这个知识点说简单也简单无非就是往页面里塞一段脚本但说复杂它可以从一枚alert(1)一路延伸到一个完整的攻击链。我刚入行那会儿也以为这题目太基础结果在真实项目里被一个文件上传点卡了半天才意识到自己对XSS的理解停留在会弹窗这个层面。后来认真做了一轮系统性复习把发现、利用、修复整条链路重新捋了一遍收获远比预期大。这篇就当是我自己的复习笔记也希望能帮到正在补这块知识的人。为什么XSS值得系统性复习而不是背几个payload1.1 XSS在真实攻防中的定位很多人在复习XSS时容易陷入一个误区刷几个payload能在靶场里弹个窗就觉得过关了。但实际情况是XSS在不同的场景里表现完全不同。比如在CTF比赛中XSS频繁和CSRF、越权、DOM Clobbering组合出场在渗透测试里XSS往往是从一个低危信息泄露升级到存储型蠕虫的跳板在开发修复时XSS又是最能体现过滤不如编码、黑名单不如白名单这一原则的典型漏洞。我后来发现真正重要的不是记住多少个Payload而是建立起一条完整的思考链用户输入在哪个位置进入页面进入时经过了什么样的过滤或编码这个上下文里浏览器会如何解析它被解析后能做什么这条思考链在面试、实战、代码审计中都能复用。所以我把这次复习的重点从记忆转向推理从利用转向理解边界。1.2 一套可复用的复习路线我给自己定的复习路线分四层这一整套走下来才敢说自己对XSS复习过第一层搞清楚三类XSS的本质区别以及它们在请求中的位置。第二层自己做实验把过滤条件一个个拆掉观察浏览器在不同上下文中的行为。第三层回到真实项目场景想清楚一个XSS从被发现到被修复的完整闭环。第四层把防御机制过滤、转义、CSP、HttpOnly、SameSite每一条都落到实际代码上而不是停留在概念里。下面我把这四层拆开来讲每部分都会带上我实际操作中踩过的坑和验证过的思路。三种XSS类型的边界反射型、存储型、DOM型2.1 反射型请求参数是唯一舞台反射型XSS最常见也最好理解。它的核心特征是服务端从请求参数中拿数据拼接进HTML响应再直接返回给客户端。整个过程没有落库所以被称为反射。判断一个注入点是否为反射型我用过一个很朴素的方法把参数值改成一个独特字符串比如xsstest2024然后看响应HTML里这个字符串出现在什么位置。如果直接出现在p标签内容里那就要尝试闭合标签如果出现在input value...的属性里就要考虑通过双引号闭合后注入事件属性。我记得自己在某个本地Demo里测过一个搜索框它的HTML是这么写的p您搜索的关键词是strong${keyword}/strong/p直接提交scriptalert(document.domain)/script确实能弹窗因为浏览器解析HTML时script标签不会显示脚本会执行。但如果我们把目光放远一点这种场景其实有个很实际的问题如果过滤脚本标签但没过滤事件属性我们就应该改成img srcx onerroralert(1)。这就是同一漏洞多种利用姿势的第一步。我强烈建议在复习反射型时自己搭一个极简服务端Express、Flask或Spring Boot随便一个都行手动把参数拼进不同的HTML上下文然后逐个测试不同payload的触发条件。只看文档永远记不牢动手试一次就懂了。2.2 存储型持久化攻击的危害升级存储型和反射型的最大区别在于数据是否入库。评论、留言、昵称、文档标题、签名档这些只要能把内容保存到数据库下一次任何用户访问这个页面时都会被注入脚本。存储型之所以厉害一是因为它不需要诱导受害者点击一个精心构造的链接二是因为受害者的访问是自然发生的命中率极高三是它可以做持久化控制比如恶意脚本修改页面显示、自动发布新评论从而形成XSS Worm。我在靶场里专门对比过存储型和反射型的请求差异反射型的关键参数在URL里日志、WAF、流量分析都能看到存储型的恶意代码在数据库里URL看起来完全正常。这解释了为什么存储型XSS在企业内网、后台管理系统中往往危害更大——安全检测的盲区更多。2.3 DOM型不经过服务端的隐形攻击DOM型XSS是我在复习时花时间最多的一种因为它最反直觉数据根本不出现在HTTP响应里服务端全程不知道攻击发生。它的本质问题出现在JavaScript代码里。常见写法是const params new URLSearchParams(window.location.search); const name params.get(name); document.getElementById(greeting).innerHTML 欢迎 name;攻击者只需要构建一个恶意URL当用户打开这个URL时location.search里的攻击代码被innerHTML渲染成DOM节点脚本同样会执行。整个过程服务端没参与、数据库没参与、响应内容里也没有script页面在开发者工具里看到的源码也是正常的。复习DOM型时光看Payload毫无意义必须要读前端JS代码找到三条关键链路输入源(Sources) → 处理逻辑 → 危险出口(Sinks)。我列几个最常见的危险出口document.write()或document.writeln()innerHTML、outerHTML、insertAdjacentHTML()eval()、new Function()location.href、location.assign()setTimeout/setInterval的字符串参数每次看到这些方法我都会下意识地回溯它们的参数来源。如果参数来自location、document.referrer、postMessage、window.name就存在DOM型XSS的疑点。这个判断方式我现在做前端代码审计时还在用。触发点与Payload构造从闭合上下文到任意JS执行3.1 找触发点的思路复习到这一步我开始丢掉弹窗思维改用上下文思维。所谓上下文就是我们的输入最终落在HTML文档的哪个结构里。我常用一个快速分类表来整理输入出现的位置典型场景核心利用思路标签内容区p{输入}/p直接插入script或img onerror标签属性值input value{输入}闭合引号后插入onfocus、onmouseoverJavaScript字符串var name {输入}闭合引号和括号注入alert(1)CSS区域内style后面的值旧版本可通过expression()或url()利用URL跳转location.href {输入}使用javascript:伪协议这个表的意义在于把找触发点变成一种条件反射。看到输入位置先问自己是哪一类上下文然后再决定用哪一组payload去验证而不是把所有payload都试一遍。3.2 Payload构造的分层验证我在实际测试里会把payload分成三个层次去构造第一层验证漏洞是否存在。最稳妥的方式是用一个非破坏性、能明确看到执行结果的payload比如scriptalert(document.domain)/script或者img srcx onerrorconsole.log(xss)。这个阶段的目标不是证明危害而是确认输入确实被当作代码执行了。第二层验证可利用性。比如能否调用函数、能否读取cookie前提是cookie未设置HttpOnly、能否发送网络请求。这一层跟业务挂钩安全测试报告要写清楚攻击者能做什么而不是只有一个弹窗截图。第三层在修复防线面前验证绕过能力。这个放到下一节详细展开。我自己的习惯是不管在哪一层都不会直接使用带cookie读取、fetch发送的payload来做破坏性试验而是把证明过程停留在能执行任意脚本这个层面避免对测试环境造成不可控影响。3.3 编码在payload里的角色编码问题是我复习时收获最大的一块。很多人以为HTML解析里只有一层解码实际不是。浏览器解析HTML的时候会先做HTML实体解码再在特定上下文比如script标签里做JavaScript解析甚至还有URL解码。这带来了一个反直觉的结论很多Payload写在URL里和最终执行时的形态完全不同。比如URL里的一段内容如果被服务端原样拼入HTML并且目标位置在事件属性里那么URL编码、HTML实体编码甚至JavaScript转义都可能被逐层还原并执行。我之前在测试一个自定义搜索功能时输入被放到一个onclick事件中。直接写onclickalert(1)触发不了因为引号被转义成了quot;。但当我用HTML实体编码方式提交quot; onmouseoverquot;alert(1)时浏览器先把实体解码成双引号闭合了原有属性注入了新事件最终成功触发了XSS。这个案例让我彻底理解了一次编码不一定够用的道理。绕过过滤的常见思路与判断依据4.1 黑名单过滤如何被绕过复习绕过时我的态度是不是为了炫技而是为了理解过滤为什么会失效。黑名单方案在XSS防御里是最脆弱的因为攻击者的输入空间远大于防御者写死的名单。最常见的一类绕过是大小写变形比如ScRiPt在某些只做了小写匹配的过滤规则下能直接通过。更常见的是标签替换型过滤比如把script整体替换为空字符串此时双写scrscriptipt就能绕过因为过滤后剩下的恰好是script。我的做法是把绕过思路整理成一套变形矩阵用不同输入逐个尝试大小写变形ScRiPtalert(1)/sCrIpT双写绕过scrscriptiptalert(1)/scriptHTML实体编码#60;script#62;alert(1)#60;/script#62;标签混淆用svg onloadalert(1)、details open ontogglealert(1)、videosource onerroronerroralert(1)事件属性组合img srcx onerroralert(1)、body onpageshowalert(1)这里我想强调一个判断方法过滤一旦存在就会有回显的指纹。比如把script替换为空响应里多出来的字符长度会有差异如果直接拦截返回400/403那我们面对的就是WAF或应用层强制拦截。先根据响应行为猜测过滤规则再针对性构造Payload去验证比盲猜高效得多。4.2 不同上下文下的绕过变体我总结出三种最常见的绕过变体每一条都有自己的试验场景第一种是上下文混淆型。比如过滤了script标签但输入出现在属性值里时用 autofocus onfocusalert(1) x能绕开标签检测过滤了alert关键字时可以用\u0061lert(1)或top[alert]来拼接函数名。第二种是解析器差异型。HTML解析器在遇到畸形标签时会有容错性。比如svgscriptalert(1)/script在很多浏览器里可执行是因为SVG命名空间对script标签的处理和普通HTML不同。理解这一点后我在PortSwigger的题目里看到svg onload就明白这不是偶然而是利用了SVG内联事件。第三种是编码层层递进型。先用URL编码过WAF到服务端解码后进入HTML再经过HTML实体解码进入JavaScript解析。这种情况下Payload在每一层都是隐蔽的直到最后一步才还原成可执行代码。我在复习时用一个双重编码的案例验证过输入前: %253Cscript%253Ealert(1)%253C%252Fscript%253E 服务端第一次URL解码: %3Cscript%3Ealert(1)%3C%2Fscript%3E 渲染时浏览器解码: scriptalert(1)/script这种攻击链在真实项目里很难防御因为服务端如果只做一层解码过滤根本看不到最原始的攻击代码。4.3 判断能不能用的核心方法面对一个疑似存在XSS的输入点我不是一股脑地把payload全暴力试一遍而是按顺序走这几步确认数据流输入能否到达服务端或者是否只在前端被处理后端是否把数据原样回显确认输出位置响应HTML里输入落在哪里HTML标签内属性内还是JavaScript区域确认过滤策略尝试改变编码、大小写、闭合方式根据响应差异反推规则。确认执行环境目标浏览器有没有CSP策略HttpOnly是否生效SameSite是否阻止了跨站请求确认影响面如果能执行JS能读取哪些数据能调用哪些API能在什么权限范围内操作这套方法帮我避开了很多看起来能弹窗但实际无法利用的假漏洞。比如有的CTF题目虽然页面有alert执行但JSONP接口设置了大量CSP头根本没法外传cookie这时候正确结论应该是存在DOM-XSS但可利用性受限还得继续找绕过CSP的方法。靶场里的高频考点DVWA、Pikachu、PortSwigger、CTFHub5.1 DVWA三个等级的设计逻辑DVWA的XSS模块是我最推荐的入门复现环境不是因为它防护多严密而是因为它把黑名单过滤强度变化这件事讲得很直白。Low级别基本没过滤直接scriptalert(1)/script就可以。Medium级别用了str_replace把script标签替换为空但没考虑大小写、双写、事件属性所以用ScRiPt或img srcx onerroralert(1)就能过。High级别换成正则匹配/(script|php|...)/只针对部分标签但依然没防住img onerror或svg onload。我建议在DVWA上做三件事第一把每一个级别的payload都完整记录下来注明为什么能过、为什么被拦第二用开发者工具看网络请求的差异第三把High级别的代码读完理解它到底过滤了什么、漏了什么。做完这三步你会很自然地意识到黑名单防不住XSS这句话的真正含义。5.2 典型靶场考点横向对比我把几个常见靶场的XSS考点理成了一张对照表方便复习时按图索骥靶场特点高频考点DVWA等级递进清晰黑名单绕过、HTML实体处理Pikachu中文注释友好、贴近业务表单输入、URL参数、DOM型PortSwigger难度梯度大贴近真实场景上下文逃逸、CSP绕过、Angular模板注入CTFHub/CTFShow技巧导向编码绕过、DOM Clobbering、落地过滤Pikachu里的XSS题目和DVWA的最大区别是场景更贴业务不像DVWA那种纯教学页面。比如留言板、搜索框、个人信息修改这些场景更接近真实系统的输入点分布。我在复习时会把Pikachu的题目当成业务逻辑题来做先找出所有能提交并回显的位置再看每个位置的数据流。PortSwigger的XSS Lab是进阶阶段必须刷的。它的题目往往设计了复杂的上下文有的输入在script标签内部需要先逃逸出字符串有的在a标签的href属性里需要用javascript:伪协议还有的页面有CSP策略需要根据script-src里的白名单域名找绕过方式。这些题目和CTF比赛的出题思路很像。5.3 靶场练习的正确姿势我的刷靶场方式和大多数人可能不太一样同一道题至少做两遍。第一遍允许看提示目标是把题目跑通第二遍完全凭记忆和推理独立把payload构造出来并且要尝试至少三种不同解法。这种训练方式最大的收获是提高了payload构造的肌肉记忆。比如遇到输入在标签内时我的第一反应不再是script而是思考这个上下文有哪些标签可以执行JS有没有事件属性可以利用。在CTF里这种反应速度往往比掌握几个高级技巧更重要。另外强烈建议在靶场练习时同时打开Burp Suite或浏览器开发者工具观察每个请求的完整链路。很多选手刷题快却连这个payload最终是如何被浏览器解析的都说不清。我自己的习惯是每打完一道题就在笔记里画一遍数据流输入 → 过滤 → 输出位置 → 浏览器解析 → 执行。画完这个链路这道题才算是真正吸收了。真实项目修复SpringBoot全局过滤器与文件上传XSS6.1 SpringBoot全局过滤器的实现边界从靶场回到真实项目XSS的修复又是另一套逻辑。搜索热词里SpringBoot全局过滤器处理上传pdf文件时xss攻击反复出现说明很多人在这块遇到了实际问题。一个常规的SpringBoot全局XSS过滤器思路一般是用HttpServletRequestWrapper包装原始请求在getParameter()、getHeader()、getInputStream()等方法里统一做HTML标签清洗或特殊字符转义。然后再配合类似Jsoup.clean()的白名单过滤把script、iframe、事件属性等清掉。但这里有几个非常容易踩的坑第一个坑getParameter()只覆盖了URL参数和表单参数。如果接口使用的是JSON格式的application/json请求体过滤器的getInputStream()读取了一次输入流后续RequestBody反序列化时就可能因为流被消费而读不到数据。正确做法是把清理逻辑写成OncePerRequestFilter并用ContentCachingRequestWrapper缓存输入流或者结合Jackson的DeserializationFeature对JSON字段做递归清洗。第二个坑过滤器对上传文件无能为力。HttpServletRequestWrapper能清洗的是请求参数和请求体但multipart/form-data里的文件流并不会经过这些方法。如果业务里允许用户上传PDF、SVG、HTML文件那全局过滤器根本覆盖不到这个攻击面。这就回答了热词里处理上传PDF文件时XSS攻击的疑惑——过滤器只能拦截一部分真正的风险在文件本身。6.2 文件上传场景的XSS风险与修复文件上传导致的XSS常见的路径有两条。第一条是上传HTML/SVG文件。HTML文件本身就能包含scriptSVG本质是XML同样能嵌入脚本。这类文件只要被浏览器以text/html或image/svgxml类型加载攻击代码就会执行。修复思路是禁止直接访问上传文件或者强制以附件形式下载设置Content-Disposition: attachment并加上X-Content-Type-Options: nosniff防止类型混淆。第二条是PDF文件内嵌JavaScript。PDF规范允许文档包含JavaScript当用户用浏览器内置的PDF阅读器打开时脚本可以执行。很多项目只校验了文件扩展名是.pdf没有校验文件Magic Number攻击者把一个恶意PDF改名为.jpg或者伪造Content-Type上传很容易绕过去。修复方案的核心是不要以原始文件名和Content-Type作为唯一信任依据要校验文件头比如PDF的%PDF-前缀并把上传文件放到独立域名或对象存储中这样即使文件有问题也和主站应用隔离。我在处理这类问题时用过的一个组合拳是这样的服务端校验MIME类型、文件后缀、Magic Number三者一致。上传文件重命名用UUID当文件名避免用户可控文件名写入HTML或下载响应头。设置响应头X-Content-Type-Options: nosniff、Content-Disposition: attachment。对SVG这类高危文件类型直接设置为仅允许下载不在线预览无法保证安全时干脆禁止上传。加强CSP比如Content-Security-Policy: default-src none; sandbox限制所有上传资源的执行能力。这里还要特别提一句不要把过滤当成修复的全部。一个全局过滤器只能挡住一部分反射型/存储型XSS的注入入口但对文件型、DOM型、绕过CSP的情况必须配合输出编码和策略加固才能形成闭环。6.3 输出编码、CSP与HttpOnly的协同防御真正落地的XSS防御从来不是靠某一个组件而是靠多层协同。我的建议是把防线分成四层缺一不可。第一层是输入侧。能做白名单就用白名单能做类型校验就做类型校验过滤规则必须同时覆盖参数、Header、JSON Body和文件流。但永远不要假设这层能挡住所有攻击。第二层是输出侧。这是最容易漏的一层。HTML上下文中要转义、、和引号属性值上下文里要做属性编码JavaScript上下文里要做JavaScript转义URL上下文中要校验协议白名单。如果都转义了很多存储型XSS根本走不到浏览器执行那一步。第三层是浏览器侧策略。HttpOnly能防cookie被脚本读取但防不了XSS本身CSP能从策略层面限制脚本来源但对内联事件和javascript:伪协议的清理也需要单独配置。一个合理的CSP至少应该包含script-src白名单和object-src none。第四层是隔离侧。上传文件独立域名、资源加载用保守的CSP、管理后台强制使用独立部署和更强认证这些措施即便前几层被绕过也能把危害半径控制住。我在复盘真实项目时发现大多数XXS过滤器无效的case本质上不是过滤器本身写得不对而是整个系统把防御责任全压在了过滤器这一层。完美的情况应该是输入过滤负责减负输出编码负责保底CSP和HttpOnly负责兜底。这三层同时工作系统才谈得上对XSS有基本的防控能力。在我实际操作中的体会是复习XSS最忌讳只看篇幅不练手。从靶场上手理解漏洞原理再从真实项目反推修复方案两边走了一遍之后以后再看到输入点回显位置脑子里自动就会出现整条防御链的轮廓。这套思考方式比记住任何一条Payload都值。