1. 从一次“无害”的输入框测试说起那天下午测试同事在群里发了一张截图附带了一个哭笑不得的表情。截图里是我们正在开发的后台管理系统一个普通的用户昵称输入框里赫然显示着一段完整的HTML代码包括一个硕大的红色警告弹窗。他只是在昵称里输入了scriptalert(xss)/script然后点击保存再刷新页面这个弹窗就跳了出来。整个办公室里前端、后端、产品经理都沉默了。这可不是什么高深的渗透测试只是一个最基础、最经典的XSS跨站脚本攻击测试。但就是这样一个“入门级”漏洞却实实在在地躺在我们即将上线的系统里。这件事让我意识到XSS远不是教科书里一个简单的alert(1)演示。它像水一样无孔不入形态多变从最显眼的弹窗到悄无声息的数据窃取危害程度天差地别。很多开发者包括曾经的我对XSS的理解可能还停留在“对用户输入做一下HTML转义就安全了”的层面。但现实是随着前端技术的复杂化尤其是单页面应用SPA和富文本编辑器的普及XSS的攻击面早已大大拓宽。反射型、存储型、DOM型每一种都有其独特的触发场景和绕过防御的手法。今天我们就抛开那些泛泛而谈的安全原则深入到XSS的肌理之中。我会结合自己踩过的坑、修复过的漏洞以及像DVWA、Pikachu这些经典靶场的实战经验带你重新认识XSS。我们不仅要弄明白为什么一个简单的脚本标签能执行更要搞清楚在不同技术栈比如Spring Boot下如何系统性地防御它以及当你在若依RuoYi这类开源框架里遇到因XSS防护导致功能异常时该如何正确地分析和解决。这不是一篇扫盲文而是一份写给一线开发者的“攻防”体检手册。2. XSS的三副面孔反射、存储与DOM很多人知道XSS但未必能清晰地说出它的几种类型及其核心区别。这就像医生看病必须首先明确病因。XSS主要分为三类反射型、存储型和DOM型。它们的“感染”途径和“发病”机制截然不同。2.1 反射型XSS一次性的“钓鱼”攻击反射型XSS也叫非持久型XSS是最常见、也相对容易理解的一种。它的攻击过程可以概括为“诱导点击-立即执行”。攻击原理攻击者构造一个含有恶意脚本的URL然后通过邮件、社交网站等渠道诱导用户点击。当用户点击这个链接恶意脚本会作为请求的一部分通常是查询参数发送到服务器。服务器在未加过滤的情况下直接将这部分数据嵌入到返回的HTML页面中并发送给用户的浏览器。浏览器将其作为页面内容的一部分解析导致恶意脚本执行。一个典型场景一个搜索功能URL形如https://example.com/search?q用户输入。后端代码可能这样写以JSP为例p您搜索的关键词是: % request.getParameter(q) %/p如果用户搜索的是“手机”页面正常显示。但如果攻击者构造这样一个URLhttps://example.com/search?qscriptalert(你的cookie是document.cookie)/script并且后端直接输出request.getParameter(q)那么这段脚本就会被原样插入到页面中并执行弹窗显示用户的Cookie。核心特点非持久化恶意脚本没有存储在服务器上只是“反射”在当次请求的响应中。需要交互必须诱骗用户主动点击那个精心构造的链接。影响面通常只对点击链接的单个用户生效。在DVWADamn Vulnerable Web Application的Low难度反射型XSS关卡中你可以直接输入脚本进行测试这正是因为它没有对输入做任何处理。而Pikachu靶场则提供了更丰富的场景比如通过GET或POST方式提交帮助你理解不同请求方式下的反射型XSS。2.2 存储型XSS潜伏的“定时炸弹”存储型XSS或称持久型XSS是危害性最大的一种。它的恶意脚本被永久地保存到了服务器端如数据库、文件系统或缓存中。攻击原理攻击者通过网站正常的交互功能如论坛发帖、用户评论、个人信息填写提交一段包含恶意脚本的内容。服务器在未经验证和过滤的情况下将其存储起来。之后任何其他用户在浏览包含这些内容的页面时恶意脚本都会从服务器加载到他们的浏览器中并自动执行。一个典型场景一个博客的评论系统。攻击者在评论框中输入这篇文章真棒img src\x\ onerror\stealCookie()\如果后端没有过滤onerror这种事件处理器前端也没有转义这条评论就会被存入数据库。此后每一个加载这篇文章页面的访客其浏览器都会尝试加载一个不存在的图片src\x\触发onerror事件从而执行stealCookie()函数导致Cookie被盗。核心特点持久化恶意脚本存储在服务器上具有长期危害性。自动传播无需诱导点击所有访问受影响页面的用户都会中招。危害巨大常用于盗取用户会话、发起钓鱼攻击、篡改页面内容、传播蠕虫等。Pikachu靶场中的存储型XSS关卡模拟的就是一个留言板功能你可以提交一条带脚本的留言然后观察其他页面或刷新后如何自动执行它直观感受其“潜伏”特性。2.3 DOM型XSS纯前端的“密室作案”DOM型XSS是一种比较特殊的类型它的整个攻击过程不涉及服务器端的数据处理。恶意代码的注入和执行完全发生在客户端的JavaScript逻辑中。攻击原理攻击的根源在于前端JavaScript代码不安全地操作了DOM。例如使用innerHTML、document.write()、eval()等危险方法将用户可控的数据如URL片段location.hash、document.referrer等直接拼接到HTML中或作为脚本执行。一个典型场景一个页面根据URL中的锚点hash来动态显示内容。// 假设URL是https://example.com/page#img srcx onerroralert(1) var userInput window.location.hash.substring(1); // 获取#后面的部分 document.getElementById(\content\).innerHTML userInput; // 危险操作这段代码的本意可能是显示一个动态片段但它直接将URL的hash部分未经处理就赋值给了innerHTML。攻击者只需让用户访问一个构造好的URL恶意脚本就会被执行。核心特点纯客户端服务器返回的响应可能是完全“干净”的漏洞出在前端JS代码逻辑。难以追踪因为不经过服务器传统的WAFWeb应用防火墙和服务器端日志可能无法发现此类攻击。触发源多样除了URLdocument.referrer来源页面、用户本地存储LocalStorage等都可能成为输入源。DOM型XSS与反射型的区别这是最容易混淆的一点。关键在于数据流。反射型XSS恶意脚本来自服务器响应。流程是用户请求带参数的URL - 服务器接收参数并拼接到HTML模板 - 返回带脚本的HTML - 浏览器执行。DOM型XSS恶意脚本来自客户端本地解析。流程是用户请求URL可能带hash- 服务器返回一个静态的、不带恶意代码的HTML - 页面内的JS代码读取URL的hash或其他客户端数据 - JS代码将其不安全地写入DOM - 浏览器解析执行新写入的脚本。简单说反射型的“脏数据”是服务器“喂”给浏览器的而DOM型的“脏数据”是浏览器页面上的JS自己“生产”并“吃下去”的。在Pikachu或一些专门的XSS Lab中会有针对innerHTML、location对象操作的关卡专门训练识别DOM型XSS的能力。3. 深入攻击向量不止于script标签当我们谈论XSS payload攻击载荷时如果只想到scriptalert(1)/script那就把攻击想得太简单了。现代浏览器的安全机制如CSP和开发者的基础防护已经能很大程度上阻断这种明显的攻击。攻击者必须更有创造力。3.1 事件处理器隐藏在属性中的杀手HTML元素有很多事件属性如onclick、onmouseover、onload、onerror等。这些属性本意是增强交互但一旦允许用户控制就成了绝佳的攻击入口。!-- 最常见的图片加载错误触发 -- img src\invalid\ onerror\alert(XSS via onerror)\ !-- 鼠标悬停触发 -- div onmouseover\alert(XSS via onmouseover)\悬停看我/div !-- 甚至可以利用SVG矢量图 -- svg onload\alert(XSS in SVG)\/svg这些payload可以绕过仅过滤script标签的简单防御。在DVWA的XSS关卡中尝试使用img srcx onerroralert(1)往往在Medium难度下依然能成功因为防御规则可能只关注了脚本标签和部分属性。3.2 JavaScript伪协议与数据协议javascript:伪协议允许在URL的地方直接执行JS代码。a href\javascript:alert(XSS via href)\点击我看似正常的链接/a iframe src\javascript:alert(XSS in iframe)\/iframedata:协议则可以用来嵌入HTML或脚本。object data\data:text/html;base64,PHNjcmlwdD5hbGVydCgnWFNTJyk8L3NjcmlwdD4\/object !-- 上面base64解码后是 scriptalert(XSS)/script --在查找XSS漏洞时所有可以设置URL的属性href、src、action等都是需要重点检查的对象。3.3 绕过常见的过滤与编码开发者会采用一些过滤方法但攻击者总有对策。大小写绕过如果过滤是大小写敏感的ScRiPt可能被放过。标签属性分割利用空格、换行符、制表符或其它属性来分隔。img src\x\onerror\alert(1)\ !-- src属性后紧跟onerror无空格 --使用未闭合的标签在某些上下文解析差异中未闭合的标签可能导致后续内容被解释为属性。input type\text\ value\\ scriptalert(1)/script 编码绕过对关键字符进行HTML实体编码或URL编码寄希望于某些环节会错误地解码。HTML实体变成lt;变成gt;\变成quot;URL编码变成%3C变成%3E如果服务器过滤了但未过滤lt;而浏览器在渲染时又将其解码就可能产生漏洞。或者如果数据经过多次解码如先URL解码再HTML解码也可能产生绕过机会。利用CSS表达式旧版IE虽然现在很少见但在一些遗留系统中expression()在CSS中也能执行JS。div style\width: expression(alert(XSS));\.../div在真实的漏洞查找XSS漏洞查找过程中需要像测试“XSS输入框语句有哪些”一样准备一个丰富的payload字典针对不同的上下文HTML标签内、属性值内、JavaScript字符串内、CSS内进行测试。4. 构建防线从Spring Boot到前端的纵深防御知道了攻击怎么来我们就要构建防线。防御XSS必须是纵深、多层次的不能只依赖某一环。4.1 服务器端的输入过滤与输出编码以Spring Boot为例这是防御的基石。原则是对输入进行严格的校验和过滤对输出进行上下文相关的编码。输入校验使用Java Bean Validation (JSR 380) 或 Spring的Valid注解对用户输入的数据格式、长度、类型进行约束。这能过滤掉大量畸形数据。public class UserDto { NotBlank Size(max 50) Pattern(regexp \^[a-zA-Z0-9_\\-\\s]$\) // 只允许字母数字下划线空格和短横线 private String username; // ... getters and setters }输出编码这是最关键的一步。必须在数据输出到页面时根据其所在的上下文进行编码。HTML正文上下文将,,,\,等字符转换为HTML实体。Spring Boot默认使用的Thymeleaf模板引擎会自动进行HTML转义。对于JSP可以使用JSTL的c:out标签或fn:escapeXml()函数。HTML属性上下文除了上述字符空格和引号也需要特别注意。应该始终用引号包裹属性值并对值进行HTML属性编码。JavaScript上下文将数据放入script标签内时需要对其进行JavaScript Unicode转义例如将\转义为\\\将换行符转义为\\n。最佳实践是避免在JS中拼接HTML而是使用textContent或setAttribute。URL上下文在拼接URL参数时使用URL编码java.net.URLEncoder。Spring Boot中可以借助org.springframework.web.util.HtmlUtils来进行HTML转义但更推荐依赖模板引擎的自动转义功能并确保没有使用th:utextThymeleaf的不转义输出或JSP的% rawData %来输出不可信数据。关于“SpringBoot解决PDF XSS攻击”这是一个特定场景。当后端动态生成PDF内容并将用户输入填入PDF模板时如果模板支持HTML/JS如某些PDF生成库也可能引入XSS。防御手段同样是在生成PDF前对注入模板的所有用户数据进行严格的HTML/JS编码或者使用纯文本/安全的标记语言来生成PDF内容避免解析任何活动内容。4.2 内容安全策略最后的堡垒内容安全策略是一种由浏览器提供的、声明式的强大安全层。它通过HTTP响应头Content-Security-Policy来告诉浏览器哪些外部资源可以被加载和执行从而从根本上减少XSS的风险。一个严格的CSP策略示例Content-Security-Policy: default-src self; script-src self https://trusted.cdn.com; style-src self unsafe-inline; img-src *; font-src selfdefault-src self默认只允许加载同源资源。script-src self https://trusted.cdn.com脚本只允许来自同源和指定的可信CDN。这直接阻止了内联脚本包括script.../script和事件处理器的执行除非特别允许不推荐。style-src self unsafe-inline样式允许同源和内联考虑到CSS开发习惯。img-src *图片可以从任何地方加载。font-src self字体只能从同源加载。在Spring Boot中配置CSP非常方便可以通过过滤器或安全配置类Configuration public class SecurityConfig extends WebSecurityConfigurerAdapter { Override protected void configure(HttpSecurity http) throws Exception { http // ... 其他配置 .headers() .contentSecurityPolicy(\default-src self; script-src self\); } }启用CSP后即使网站存在XSS漏洞攻击者也无法加载和执行外部的恶意脚本大大增加了攻击难度。在DVWA的高难度XSS关卡中往往就需要绕过CSP这通常需要结合其他漏洞如JSONP劫持。4.3 前端框架的安全实践与现代浏览器特性现代前端框架如React, Vue, Angular在默认情况下提供了一定的XSS防护。React在JSX中直接插入变量{userInput}时React会自动进行转义将其作为文本处理而不是HTML。只有使用dangerouslySetInnerHTML时才会原样输出因此必须慎用。Vue使用双花括号插值{{ userInput }}也会自动转义。只有使用v-html指令时才会输出原始HTML同样需要确保内容安全。Angular插值表达式和属性绑定默认也是安全的使用[innerHTML]属性绑定时需谨慎。永远不要相信用户输入即使使用了安全框架。框架的自动转义是针对特定上下文的如果你错误地将用户输入拼接到了危险的位置比如eval()或setTimeout的第一个字符串参数防护就会失效。此外利用现代浏览器的安全特性HttpOnly Cookie设置会话Cookie的HttpOnly属性可以阻止JavaScript通过document.cookieAPI访问它这样即使发生XSS攻击者也无法直接窃取Cookie进行会话劫持。输入类型限制对于明确的输入类型如邮箱、URL使用input type\email\或input type\url\浏览器会进行初步的格式验证。5. 实战排查以“若依RuoYi的XSS导致新建模块无法写入”为例在实际开发中有时过于严格或错误的XSS防护反而会导致功能异常。比如社区中提到的“ruoyipro的xss导致新建模块无法写入问题”这是一个非常典型的案例。我们来模拟分析一下这类问题的排查思路。问题现象在若依后台管理系统中新建或编辑某个模块比如新闻、产品时内容提交后前端显示成功但数据库中没有写入数据或者写入的数据被截断、篡改。排查链路确认问题范围首先确定是所有富文本字段出问题还是特定字段是只有包含特定字符如,,的内容无法写入还是所有内容通过输入简单文本、带HTML标签的文本、带特殊符号的文本进行测试。检查网络请求打开浏览器开发者工具的“网络(Network)”选项卡提交表单查看发送到后端的POST请求的Payload。确认前端发送的数据是否是完整的、未经修改的。比如你输入了p测试内容/p查看请求体里这个字段的值是否正确。定位后端拦截点如果前端发送的数据正确问题很可能出在后端。若依框架通常会有全局的XSS过滤器如XssFilter或参数处理组件。查找过滤器在Java代码中搜索XssFilter、XssHttpServletRequestWrapper这类类名。查看其doFilter方法或filter方法。分析过滤逻辑核心是看它如何“清洗”请求参数。常见问题有过度过滤可能配置了过于激进的规则比如直接删除所有HTML标签包括p,br等合法的富文本标签导致富文本内容变成空字符串后端校验失败。错误转义将转义为lt;但转义后的字符串lt;pgt;测试lt;/pgt;被直接存入数据库。当页面显示时它被作为文本“p测试/p”显示而不是被渲染为HTML段落。处理时机不当过滤器可能在Spring MVC的参数绑定RequestBody或RequestParam之前或之后执行导致处理对象不一致。验证数据库直接查询数据库看写入的数据到底是什么。是空了是转义后的字符串还是被截断了这能直接验证过滤器的效果。解决方案区分场景不是所有字段都需要同样的过滤强度。对于纯文本字段如标题、作者应该进行严格的HTML转义或标签剥离。对于富文本字段如文章内容、商品详情则需要一个“安全的HTML”过滤器只允许一组预设的安全标签和属性如p,b,img src但禁止script,onerror。使用成熟库不要自己写复杂的HTML净化器容易出错。使用像Jsoup这样的Java库它提供了强大的HTML解析和净化功能。import org.jsoup.Jsoup; import org.jsoup.safety.Safelist; // 定义一个宽松但安全的规则允许基本的文本格式和图片 Safelist safelist Safelist.relaxed() .addAttributes(\img\, \src\, \alt\, \width\, \height\) // 允许img的特定属性 .preserveRelativeLinks(true); // 保留相对链接 String cleanHtml Jsoup.clean(rawHtml, safelist);调整过滤规则修改框架的XSS过滤器配置对特定的URL路径或参数名称进行排除或采用不同的净化策略。例如对于/admin/content/save这个保存富文本的接口可以配置过滤器放行或者使用专门的富文本净化器。前端配合如果后端期望接收纯净的HTML前端富文本编辑器如WangEditor、TinyMCE也应配置只允许输出安全的HTML。这个排查过程的核心思想是数据流追踪。从用户输入开始跟踪数据经过前端表单、网络请求、后端过滤器、控制器、服务层、持久层直到最终存入数据库和再次渲染出来的完整路径在每个环节检查数据的形态是否如预期。6. 高级话题JSONP与XSS的纠缠JSONPJSON with Padding是一种古老的前端跨域数据获取技术。由于其设计上的安全性缺陷它常常成为XSS攻击的帮凶甚至本身就能造成严重的XSS漏洞。JSONP原理简述由于浏览器的同源策略XMLHttpRequest不能直接请求不同域的接口。JSONP利用script标签可以跨域加载资源的特性来绕过这一限制。客户端定义一个回调函数然后将函数名作为参数传递给服务器。服务器将数据包裹在这个回调函数调用中返回例如返回callbackFunction({\data\: \value\})。浏览器加载这个脚本后就会执行这个函数从而获取到数据。安全风险回调函数名可控如果服务器没有严格校验callback参数攻击者可以将其设置为恶意的代码如alert(1);//。那么服务器返回的可能是alert(1);//({\data\: \value\})//注释掉了后面的合法代码导致alert(1)执行。数据未过滤即使回调函数名是固定的如果服务器返回的JSON数据中包含了用户可控的、未经过滤的HTML或脚本内容并且前端直接将其插入到DOM中例如document.getElementById(\result\).innerHTML data.userContent;也会导致DOM型XSS。防御“JSONP XSS”弃用JSONP使用CORS在现代Web开发中应优先使用更安全、功能更强大的CORS跨源资源共享来实现跨域请求。严格校验回调函数名如果必须使用JSONP后端必须对callback参数进行严格的白名单校验只允许字母数字和下划线组成的、预定义的函数名。设置正确的Content-Type响应头应设置为Content-Type: application/javascript而不是application/json避免被某些浏览器不当解析。对输出数据进行编码即使使用JSONP返回数据中如果包含要显示在页面上的内容也应在前端进行适当的编码后再插入DOM。在漏洞查找中如果看到一个接口支持callback参数并且返回的内容类型是JS就要立刻警惕是否存在JSONP XSS的风险。7. 持续安全将XSS防御融入开发流程XSS防御不是一次性的任务而应该融入整个软件开发生命周期。安全需求与设计在项目初期就将安全考虑进去。明确哪些字段是富文本哪些是纯文本定义好各字段的安全处理等级。安全编码规范制定团队内的安全编码规范强制要求所有输出到HTML的数据必须经过上下文相关的编码。禁止使用innerHTML、document.write、eval()、setTimeout(string)等危险函数直接处理用户数据。使用参数化查询或ORM防止SQL注入这虽然不直接防XSS但能减少攻击面。代码审计与自动化扫描将静态代码安全扫描SAST工具集成到CI/CD流程中自动检测代码中的XSS风险点。同时定期进行人工代码审查重点关注数据流。自动化安全测试在QA环节使用动态应用安全测试DAST工具或编写专门的XSS测试用例对系统进行自动化漏洞扫描。可以构建一个包含各种XSS payload的测试集在每次构建后对关键接口进行模糊测试。依赖项管理保持第三方库包括前端框架、后端组件的更新及时修补已知的安全漏洞。一个存在XSS漏洞的旧版富文本编辑器插件可能会让你所有的防御功亏一篑。安全教育最终所有防御措施都依赖于人。定期对开发、测试、运维团队进行安全意识培训让大家理解XSS的原理、危害和防御方法才能在每一次代码编写和审查中保持警惕。防御XSS是一场持久战。攻击技术在进化我们的防御手段也需要不断升级。从最基础的输入输出处理到严格的CSP策略再到开发流程中的安全左移每一层都在增加攻击者的成本。记住那个下午的弹窗它提醒我们安全无小事任何一个疏忽都可能打开潘多拉的魔盒。
XSS攻击深度解析：从反射型到DOM型，Spring Boot防御实战指南
1. 从一次“无害”的输入框测试说起那天下午测试同事在群里发了一张截图附带了一个哭笑不得的表情。截图里是我们正在开发的后台管理系统一个普通的用户昵称输入框里赫然显示着一段完整的HTML代码包括一个硕大的红色警告弹窗。他只是在昵称里输入了scriptalert(xss)/script然后点击保存再刷新页面这个弹窗就跳了出来。整个办公室里前端、后端、产品经理都沉默了。这可不是什么高深的渗透测试只是一个最基础、最经典的XSS跨站脚本攻击测试。但就是这样一个“入门级”漏洞却实实在在地躺在我们即将上线的系统里。这件事让我意识到XSS远不是教科书里一个简单的alert(1)演示。它像水一样无孔不入形态多变从最显眼的弹窗到悄无声息的数据窃取危害程度天差地别。很多开发者包括曾经的我对XSS的理解可能还停留在“对用户输入做一下HTML转义就安全了”的层面。但现实是随着前端技术的复杂化尤其是单页面应用SPA和富文本编辑器的普及XSS的攻击面早已大大拓宽。反射型、存储型、DOM型每一种都有其独特的触发场景和绕过防御的手法。今天我们就抛开那些泛泛而谈的安全原则深入到XSS的肌理之中。我会结合自己踩过的坑、修复过的漏洞以及像DVWA、Pikachu这些经典靶场的实战经验带你重新认识XSS。我们不仅要弄明白为什么一个简单的脚本标签能执行更要搞清楚在不同技术栈比如Spring Boot下如何系统性地防御它以及当你在若依RuoYi这类开源框架里遇到因XSS防护导致功能异常时该如何正确地分析和解决。这不是一篇扫盲文而是一份写给一线开发者的“攻防”体检手册。2. XSS的三副面孔反射、存储与DOM很多人知道XSS但未必能清晰地说出它的几种类型及其核心区别。这就像医生看病必须首先明确病因。XSS主要分为三类反射型、存储型和DOM型。它们的“感染”途径和“发病”机制截然不同。2.1 反射型XSS一次性的“钓鱼”攻击反射型XSS也叫非持久型XSS是最常见、也相对容易理解的一种。它的攻击过程可以概括为“诱导点击-立即执行”。攻击原理攻击者构造一个含有恶意脚本的URL然后通过邮件、社交网站等渠道诱导用户点击。当用户点击这个链接恶意脚本会作为请求的一部分通常是查询参数发送到服务器。服务器在未加过滤的情况下直接将这部分数据嵌入到返回的HTML页面中并发送给用户的浏览器。浏览器将其作为页面内容的一部分解析导致恶意脚本执行。一个典型场景一个搜索功能URL形如https://example.com/search?q用户输入。后端代码可能这样写以JSP为例p您搜索的关键词是: % request.getParameter(q) %/p如果用户搜索的是“手机”页面正常显示。但如果攻击者构造这样一个URLhttps://example.com/search?qscriptalert(你的cookie是document.cookie)/script并且后端直接输出request.getParameter(q)那么这段脚本就会被原样插入到页面中并执行弹窗显示用户的Cookie。核心特点非持久化恶意脚本没有存储在服务器上只是“反射”在当次请求的响应中。需要交互必须诱骗用户主动点击那个精心构造的链接。影响面通常只对点击链接的单个用户生效。在DVWADamn Vulnerable Web Application的Low难度反射型XSS关卡中你可以直接输入脚本进行测试这正是因为它没有对输入做任何处理。而Pikachu靶场则提供了更丰富的场景比如通过GET或POST方式提交帮助你理解不同请求方式下的反射型XSS。2.2 存储型XSS潜伏的“定时炸弹”存储型XSS或称持久型XSS是危害性最大的一种。它的恶意脚本被永久地保存到了服务器端如数据库、文件系统或缓存中。攻击原理攻击者通过网站正常的交互功能如论坛发帖、用户评论、个人信息填写提交一段包含恶意脚本的内容。服务器在未经验证和过滤的情况下将其存储起来。之后任何其他用户在浏览包含这些内容的页面时恶意脚本都会从服务器加载到他们的浏览器中并自动执行。一个典型场景一个博客的评论系统。攻击者在评论框中输入这篇文章真棒img src\x\ onerror\stealCookie()\如果后端没有过滤onerror这种事件处理器前端也没有转义这条评论就会被存入数据库。此后每一个加载这篇文章页面的访客其浏览器都会尝试加载一个不存在的图片src\x\触发onerror事件从而执行stealCookie()函数导致Cookie被盗。核心特点持久化恶意脚本存储在服务器上具有长期危害性。自动传播无需诱导点击所有访问受影响页面的用户都会中招。危害巨大常用于盗取用户会话、发起钓鱼攻击、篡改页面内容、传播蠕虫等。Pikachu靶场中的存储型XSS关卡模拟的就是一个留言板功能你可以提交一条带脚本的留言然后观察其他页面或刷新后如何自动执行它直观感受其“潜伏”特性。2.3 DOM型XSS纯前端的“密室作案”DOM型XSS是一种比较特殊的类型它的整个攻击过程不涉及服务器端的数据处理。恶意代码的注入和执行完全发生在客户端的JavaScript逻辑中。攻击原理攻击的根源在于前端JavaScript代码不安全地操作了DOM。例如使用innerHTML、document.write()、eval()等危险方法将用户可控的数据如URL片段location.hash、document.referrer等直接拼接到HTML中或作为脚本执行。一个典型场景一个页面根据URL中的锚点hash来动态显示内容。// 假设URL是https://example.com/page#img srcx onerroralert(1) var userInput window.location.hash.substring(1); // 获取#后面的部分 document.getElementById(\content\).innerHTML userInput; // 危险操作这段代码的本意可能是显示一个动态片段但它直接将URL的hash部分未经处理就赋值给了innerHTML。攻击者只需让用户访问一个构造好的URL恶意脚本就会被执行。核心特点纯客户端服务器返回的响应可能是完全“干净”的漏洞出在前端JS代码逻辑。难以追踪因为不经过服务器传统的WAFWeb应用防火墙和服务器端日志可能无法发现此类攻击。触发源多样除了URLdocument.referrer来源页面、用户本地存储LocalStorage等都可能成为输入源。DOM型XSS与反射型的区别这是最容易混淆的一点。关键在于数据流。反射型XSS恶意脚本来自服务器响应。流程是用户请求带参数的URL - 服务器接收参数并拼接到HTML模板 - 返回带脚本的HTML - 浏览器执行。DOM型XSS恶意脚本来自客户端本地解析。流程是用户请求URL可能带hash- 服务器返回一个静态的、不带恶意代码的HTML - 页面内的JS代码读取URL的hash或其他客户端数据 - JS代码将其不安全地写入DOM - 浏览器解析执行新写入的脚本。简单说反射型的“脏数据”是服务器“喂”给浏览器的而DOM型的“脏数据”是浏览器页面上的JS自己“生产”并“吃下去”的。在Pikachu或一些专门的XSS Lab中会有针对innerHTML、location对象操作的关卡专门训练识别DOM型XSS的能力。3. 深入攻击向量不止于script标签当我们谈论XSS payload攻击载荷时如果只想到scriptalert(1)/script那就把攻击想得太简单了。现代浏览器的安全机制如CSP和开发者的基础防护已经能很大程度上阻断这种明显的攻击。攻击者必须更有创造力。3.1 事件处理器隐藏在属性中的杀手HTML元素有很多事件属性如onclick、onmouseover、onload、onerror等。这些属性本意是增强交互但一旦允许用户控制就成了绝佳的攻击入口。!-- 最常见的图片加载错误触发 -- img src\invalid\ onerror\alert(XSS via onerror)\ !-- 鼠标悬停触发 -- div onmouseover\alert(XSS via onmouseover)\悬停看我/div !-- 甚至可以利用SVG矢量图 -- svg onload\alert(XSS in SVG)\/svg这些payload可以绕过仅过滤script标签的简单防御。在DVWA的XSS关卡中尝试使用img srcx onerroralert(1)往往在Medium难度下依然能成功因为防御规则可能只关注了脚本标签和部分属性。3.2 JavaScript伪协议与数据协议javascript:伪协议允许在URL的地方直接执行JS代码。a href\javascript:alert(XSS via href)\点击我看似正常的链接/a iframe src\javascript:alert(XSS in iframe)\/iframedata:协议则可以用来嵌入HTML或脚本。object data\data:text/html;base64,PHNjcmlwdD5hbGVydCgnWFNTJyk8L3NjcmlwdD4\/object !-- 上面base64解码后是 scriptalert(XSS)/script --在查找XSS漏洞时所有可以设置URL的属性href、src、action等都是需要重点检查的对象。3.3 绕过常见的过滤与编码开发者会采用一些过滤方法但攻击者总有对策。大小写绕过如果过滤是大小写敏感的ScRiPt可能被放过。标签属性分割利用空格、换行符、制表符或其它属性来分隔。img src\x\onerror\alert(1)\ !-- src属性后紧跟onerror无空格 --使用未闭合的标签在某些上下文解析差异中未闭合的标签可能导致后续内容被解释为属性。input type\text\ value\\ scriptalert(1)/script 编码绕过对关键字符进行HTML实体编码或URL编码寄希望于某些环节会错误地解码。HTML实体变成lt;变成gt;\变成quot;URL编码变成%3C变成%3E如果服务器过滤了但未过滤lt;而浏览器在渲染时又将其解码就可能产生漏洞。或者如果数据经过多次解码如先URL解码再HTML解码也可能产生绕过机会。利用CSS表达式旧版IE虽然现在很少见但在一些遗留系统中expression()在CSS中也能执行JS。div style\width: expression(alert(XSS));\.../div在真实的漏洞查找XSS漏洞查找过程中需要像测试“XSS输入框语句有哪些”一样准备一个丰富的payload字典针对不同的上下文HTML标签内、属性值内、JavaScript字符串内、CSS内进行测试。4. 构建防线从Spring Boot到前端的纵深防御知道了攻击怎么来我们就要构建防线。防御XSS必须是纵深、多层次的不能只依赖某一环。4.1 服务器端的输入过滤与输出编码以Spring Boot为例这是防御的基石。原则是对输入进行严格的校验和过滤对输出进行上下文相关的编码。输入校验使用Java Bean Validation (JSR 380) 或 Spring的Valid注解对用户输入的数据格式、长度、类型进行约束。这能过滤掉大量畸形数据。public class UserDto { NotBlank Size(max 50) Pattern(regexp \^[a-zA-Z0-9_\\-\\s]$\) // 只允许字母数字下划线空格和短横线 private String username; // ... getters and setters }输出编码这是最关键的一步。必须在数据输出到页面时根据其所在的上下文进行编码。HTML正文上下文将,,,\,等字符转换为HTML实体。Spring Boot默认使用的Thymeleaf模板引擎会自动进行HTML转义。对于JSP可以使用JSTL的c:out标签或fn:escapeXml()函数。HTML属性上下文除了上述字符空格和引号也需要特别注意。应该始终用引号包裹属性值并对值进行HTML属性编码。JavaScript上下文将数据放入script标签内时需要对其进行JavaScript Unicode转义例如将\转义为\\\将换行符转义为\\n。最佳实践是避免在JS中拼接HTML而是使用textContent或setAttribute。URL上下文在拼接URL参数时使用URL编码java.net.URLEncoder。Spring Boot中可以借助org.springframework.web.util.HtmlUtils来进行HTML转义但更推荐依赖模板引擎的自动转义功能并确保没有使用th:utextThymeleaf的不转义输出或JSP的% rawData %来输出不可信数据。关于“SpringBoot解决PDF XSS攻击”这是一个特定场景。当后端动态生成PDF内容并将用户输入填入PDF模板时如果模板支持HTML/JS如某些PDF生成库也可能引入XSS。防御手段同样是在生成PDF前对注入模板的所有用户数据进行严格的HTML/JS编码或者使用纯文本/安全的标记语言来生成PDF内容避免解析任何活动内容。4.2 内容安全策略最后的堡垒内容安全策略是一种由浏览器提供的、声明式的强大安全层。它通过HTTP响应头Content-Security-Policy来告诉浏览器哪些外部资源可以被加载和执行从而从根本上减少XSS的风险。一个严格的CSP策略示例Content-Security-Policy: default-src self; script-src self https://trusted.cdn.com; style-src self unsafe-inline; img-src *; font-src selfdefault-src self默认只允许加载同源资源。script-src self https://trusted.cdn.com脚本只允许来自同源和指定的可信CDN。这直接阻止了内联脚本包括script.../script和事件处理器的执行除非特别允许不推荐。style-src self unsafe-inline样式允许同源和内联考虑到CSS开发习惯。img-src *图片可以从任何地方加载。font-src self字体只能从同源加载。在Spring Boot中配置CSP非常方便可以通过过滤器或安全配置类Configuration public class SecurityConfig extends WebSecurityConfigurerAdapter { Override protected void configure(HttpSecurity http) throws Exception { http // ... 其他配置 .headers() .contentSecurityPolicy(\default-src self; script-src self\); } }启用CSP后即使网站存在XSS漏洞攻击者也无法加载和执行外部的恶意脚本大大增加了攻击难度。在DVWA的高难度XSS关卡中往往就需要绕过CSP这通常需要结合其他漏洞如JSONP劫持。4.3 前端框架的安全实践与现代浏览器特性现代前端框架如React, Vue, Angular在默认情况下提供了一定的XSS防护。React在JSX中直接插入变量{userInput}时React会自动进行转义将其作为文本处理而不是HTML。只有使用dangerouslySetInnerHTML时才会原样输出因此必须慎用。Vue使用双花括号插值{{ userInput }}也会自动转义。只有使用v-html指令时才会输出原始HTML同样需要确保内容安全。Angular插值表达式和属性绑定默认也是安全的使用[innerHTML]属性绑定时需谨慎。永远不要相信用户输入即使使用了安全框架。框架的自动转义是针对特定上下文的如果你错误地将用户输入拼接到了危险的位置比如eval()或setTimeout的第一个字符串参数防护就会失效。此外利用现代浏览器的安全特性HttpOnly Cookie设置会话Cookie的HttpOnly属性可以阻止JavaScript通过document.cookieAPI访问它这样即使发生XSS攻击者也无法直接窃取Cookie进行会话劫持。输入类型限制对于明确的输入类型如邮箱、URL使用input type\email\或input type\url\浏览器会进行初步的格式验证。5. 实战排查以“若依RuoYi的XSS导致新建模块无法写入”为例在实际开发中有时过于严格或错误的XSS防护反而会导致功能异常。比如社区中提到的“ruoyipro的xss导致新建模块无法写入问题”这是一个非常典型的案例。我们来模拟分析一下这类问题的排查思路。问题现象在若依后台管理系统中新建或编辑某个模块比如新闻、产品时内容提交后前端显示成功但数据库中没有写入数据或者写入的数据被截断、篡改。排查链路确认问题范围首先确定是所有富文本字段出问题还是特定字段是只有包含特定字符如,,的内容无法写入还是所有内容通过输入简单文本、带HTML标签的文本、带特殊符号的文本进行测试。检查网络请求打开浏览器开发者工具的“网络(Network)”选项卡提交表单查看发送到后端的POST请求的Payload。确认前端发送的数据是否是完整的、未经修改的。比如你输入了p测试内容/p查看请求体里这个字段的值是否正确。定位后端拦截点如果前端发送的数据正确问题很可能出在后端。若依框架通常会有全局的XSS过滤器如XssFilter或参数处理组件。查找过滤器在Java代码中搜索XssFilter、XssHttpServletRequestWrapper这类类名。查看其doFilter方法或filter方法。分析过滤逻辑核心是看它如何“清洗”请求参数。常见问题有过度过滤可能配置了过于激进的规则比如直接删除所有HTML标签包括p,br等合法的富文本标签导致富文本内容变成空字符串后端校验失败。错误转义将转义为lt;但转义后的字符串lt;pgt;测试lt;/pgt;被直接存入数据库。当页面显示时它被作为文本“p测试/p”显示而不是被渲染为HTML段落。处理时机不当过滤器可能在Spring MVC的参数绑定RequestBody或RequestParam之前或之后执行导致处理对象不一致。验证数据库直接查询数据库看写入的数据到底是什么。是空了是转义后的字符串还是被截断了这能直接验证过滤器的效果。解决方案区分场景不是所有字段都需要同样的过滤强度。对于纯文本字段如标题、作者应该进行严格的HTML转义或标签剥离。对于富文本字段如文章内容、商品详情则需要一个“安全的HTML”过滤器只允许一组预设的安全标签和属性如p,b,img src但禁止script,onerror。使用成熟库不要自己写复杂的HTML净化器容易出错。使用像Jsoup这样的Java库它提供了强大的HTML解析和净化功能。import org.jsoup.Jsoup; import org.jsoup.safety.Safelist; // 定义一个宽松但安全的规则允许基本的文本格式和图片 Safelist safelist Safelist.relaxed() .addAttributes(\img\, \src\, \alt\, \width\, \height\) // 允许img的特定属性 .preserveRelativeLinks(true); // 保留相对链接 String cleanHtml Jsoup.clean(rawHtml, safelist);调整过滤规则修改框架的XSS过滤器配置对特定的URL路径或参数名称进行排除或采用不同的净化策略。例如对于/admin/content/save这个保存富文本的接口可以配置过滤器放行或者使用专门的富文本净化器。前端配合如果后端期望接收纯净的HTML前端富文本编辑器如WangEditor、TinyMCE也应配置只允许输出安全的HTML。这个排查过程的核心思想是数据流追踪。从用户输入开始跟踪数据经过前端表单、网络请求、后端过滤器、控制器、服务层、持久层直到最终存入数据库和再次渲染出来的完整路径在每个环节检查数据的形态是否如预期。6. 高级话题JSONP与XSS的纠缠JSONPJSON with Padding是一种古老的前端跨域数据获取技术。由于其设计上的安全性缺陷它常常成为XSS攻击的帮凶甚至本身就能造成严重的XSS漏洞。JSONP原理简述由于浏览器的同源策略XMLHttpRequest不能直接请求不同域的接口。JSONP利用script标签可以跨域加载资源的特性来绕过这一限制。客户端定义一个回调函数然后将函数名作为参数传递给服务器。服务器将数据包裹在这个回调函数调用中返回例如返回callbackFunction({\data\: \value\})。浏览器加载这个脚本后就会执行这个函数从而获取到数据。安全风险回调函数名可控如果服务器没有严格校验callback参数攻击者可以将其设置为恶意的代码如alert(1);//。那么服务器返回的可能是alert(1);//({\data\: \value\})//注释掉了后面的合法代码导致alert(1)执行。数据未过滤即使回调函数名是固定的如果服务器返回的JSON数据中包含了用户可控的、未经过滤的HTML或脚本内容并且前端直接将其插入到DOM中例如document.getElementById(\result\).innerHTML data.userContent;也会导致DOM型XSS。防御“JSONP XSS”弃用JSONP使用CORS在现代Web开发中应优先使用更安全、功能更强大的CORS跨源资源共享来实现跨域请求。严格校验回调函数名如果必须使用JSONP后端必须对callback参数进行严格的白名单校验只允许字母数字和下划线组成的、预定义的函数名。设置正确的Content-Type响应头应设置为Content-Type: application/javascript而不是application/json避免被某些浏览器不当解析。对输出数据进行编码即使使用JSONP返回数据中如果包含要显示在页面上的内容也应在前端进行适当的编码后再插入DOM。在漏洞查找中如果看到一个接口支持callback参数并且返回的内容类型是JS就要立刻警惕是否存在JSONP XSS的风险。7. 持续安全将XSS防御融入开发流程XSS防御不是一次性的任务而应该融入整个软件开发生命周期。安全需求与设计在项目初期就将安全考虑进去。明确哪些字段是富文本哪些是纯文本定义好各字段的安全处理等级。安全编码规范制定团队内的安全编码规范强制要求所有输出到HTML的数据必须经过上下文相关的编码。禁止使用innerHTML、document.write、eval()、setTimeout(string)等危险函数直接处理用户数据。使用参数化查询或ORM防止SQL注入这虽然不直接防XSS但能减少攻击面。代码审计与自动化扫描将静态代码安全扫描SAST工具集成到CI/CD流程中自动检测代码中的XSS风险点。同时定期进行人工代码审查重点关注数据流。自动化安全测试在QA环节使用动态应用安全测试DAST工具或编写专门的XSS测试用例对系统进行自动化漏洞扫描。可以构建一个包含各种XSS payload的测试集在每次构建后对关键接口进行模糊测试。依赖项管理保持第三方库包括前端框架、后端组件的更新及时修补已知的安全漏洞。一个存在XSS漏洞的旧版富文本编辑器插件可能会让你所有的防御功亏一篑。安全教育最终所有防御措施都依赖于人。定期对开发、测试、运维团队进行安全意识培训让大家理解XSS的原理、危害和防御方法才能在每一次代码编写和审查中保持警惕。防御XSS是一场持久战。攻击技术在进化我们的防御手段也需要不断升级。从最基础的输入输出处理到严格的CSP策略再到开发流程中的安全左移每一层都在增加攻击者的成本。记住那个下午的弹窗它提醒我们安全无小事任何一个疏忽都可能打开潘多拉的魔盒。