做Web安全这几年只要一聊漏洞我头一个想起的不是SQL注入也不是文件上传而是XSS攻击。原因很简单大部分高危漏洞都有清晰的攻击边界要么是参数校验不到位要么是服务端配置有疏漏而XSS攻击是真正把战场拖进用户浏览器的“内鬼行为”。多数情况下攻击者甚至不需要入侵任何服务器也不需要爆破任何口令只需要让正常用户点击一个精心构造的链接或者打开一个已被污染的页面恶意脚本就能在用户的浏览器里悄悄运行起来。这篇文章我想把XSS攻击这件事彻底聊透它到底是什么、为什么浏览器会被“摆了一道”、业界常说的三大分类各自有什么特征以及我在实际测试和防御过程中踩过哪些坑。不管你是刚开始接触Web安全的新人还是写过不少接口的后端开发又或者是每天和页面样式斗智斗勇的前端工程师这篇文章都值得你花点时间读完至少能让你下次听别人说“这里有个XSS”的时候脑子里能立刻冒出清晰的三类分类和对应的排查路径。1. XSS攻击是什么先看浏览器是怎样被“摆了”一道的1.1 一句话讲透XSS原理XSS的全称是Cross-Site Scripting直译过来叫跨站脚本。有人会好奇缩写不应该是CSS吗就是因为CSS早被层叠样式表占了名字安全圈才约定俗成改用XSS。原理其实不复杂。浏览器在渲染网页时会把服务器返回的HTML、CSS、JavaScript当成“指令”去执行。正常流程下这些指令都是开发者写好的、可信的代码。可一旦攻击者能在指令里掺入自己控制的脚本情况就变了。XSS攻击本质上就是攻击者利用网站对用户输入过滤不严的漏洞把自己的恶意脚本注入到页面中浏览器在毫不知情的情况下替攻击者执行了这段脚本。打个比方你租了一个房子用户浏览器房东网站服务器给了你一把钥匙告诉你进门后可以开灯、烧水、看电视。攻击者趁房东不注意偷偷在灯泡开关里塞了一个“按下去就报警”的小机关。你回到家正常开灯机关触发小区的保安网站后台收到报警以为你家里出事了。整个过程里开灯的人是你执行命令的是房间里的电路真正获利的是那个偷偷塞机关的坏人。放在Web场景下攻击者注入的脚本一般能做什么呢它能读取当前页面里的Cookie拿到用户的登录凭证能伪造用户操作比如发一条微博、转一笔账能篡改页面内容诱导用户输入更多敏感信息甚至能把用户当前浏览器里所有能访问的接口都轮询一遍做横向探测。这些行为全部发生在用户自己浏览器中从后端日志里看请求全都来自正常用户很难追溯。1.2 攻击者为什么死盯着XSS不放这些年企业做安全建设往往对SQL注入、越权访问这些服务端漏洞投入大量精力把接口加固、数据库脱敏都做得不错但XSS却经常被忽略。原因在于它不直接攻击服务器也不会立刻造成数据泄露所以很多研发团队会把它归类为“低危问题”。但真正做过攻防演练的人都知道XSS往往是撬动整个系统的第一块砖。攻击者拿到一个存储型XSS之后根本不需要直接打服务器而是先打这个网站的使用者。比如说一个后台管理系统的某个输入框存在XSS攻击者构造请求让管理员中招管理员浏览器里的会话凭证直接被偷走攻击者拿着凭证大摇大摆进了后台——所有的防线在这一刻都形同虚设。所以不要小看任意一个能反弹参数的地方。XSS的危险程度取决于这个页面所处的位置以及能影响到的用户权限级别。普通博客的评论区XSS可能只是弹个窗但一个运维平台的告警页面出现XSS那问题就大了。1.3 XSS与CSRF的“兄弟恩怨”经常有人把XSS和CSRF搞混。两者确实容易同时出现在同一个功能里但思路完全不同。CSRF是攻击者借用户的浏览器冒充用户身份去发请求它的核心是利用了Cookie自动携带的特性而XSS是攻击者把代码直接塞进页面让浏览器在渲染时执行这段代码。换句话说CSRF是“替你做”XSS是“指挥你做”。二者最致命的组合是攻击者先用XSS往页面里注入一段脚本脚本里再藏CSRF请求这时候用户点哪儿都躲不开防御方就需要同时考虑CSP、Token校验、Cookie属性等多层机制才能压住风险。2. XSS攻击的三大分类别再傻傻分不清业内的划分方式经历了多次演变但最主流的还是按照“恶意脚本是否经过服务器存储并反射回页面”这一维度分成三大类反射型、存储型和DOM型。2.1 反射型XSS非持久型一次性打击骗的就是你的点击反射型XSS又叫非持久型XSS特点可以概括为“一锤子买卖”。恶意脚本并不存储在目标网站上而是藏在URL参数、搜索关键词或者表单提交的数据里。当用户访问这个Carry了恶意参数的链接时服务器端把参数内容原样拼接进了页面HTML返回给浏览器脚本随之被解析执行。一个很典型的场景是搜索功能。比如某个新闻网站有一个站内搜索搜索关键词会直接拼在结果页的“您搜索的关键词是XXX”这个位置并且没有做任何转义。攻击者把[脚本]作为关键词塞进链接用户一旦点击这个链接浏览器就把[脚本]当作HTML解析恶意脚本瞬间执行——攻击结束URL里的参数再也没有第二次利用机会所以叫非持久型。这类攻击的触发前提是“用户必须点链接”。攻击者一般会把恶意URL包装成短链接、二维码或者直接隐藏在邮件正文里诱导用户点击。我见过很骚的操作是攻击者把这个恶意URL嵌入到一条打折促销的短信里前面加上极具诱惑力的文案普通用户根本分辨不出链接里的特殊字符有什么危险。从防御角度看反射型XSS的检测相对容易最简单的手段是抓包看响应把参数改成alert(1)如果响应里出现同样的字符串并且浏览器弹窗了那基本就是反射型XSS。修复方式也很直接在输出点做HTML实体编码即可。2.2 存储型XSS持久型不需要点链接看一眼就中招存储型XSS也叫持久型XSS这名字一听就知道问题更严重。恶意脚本不是藏在URL里而是被完整地保存到了服务器端——可能是存进了数据库、缓存、日志文件里。之后任何用户访问包含这段恶意内容的页面脚本都会自动执行完全不需要点击任何攻击者构造的链接。最有代表性的位置是评论区、留言板、用户昵称、个人简介、富文本编辑器。攻击者在这些位置提交一段包含恶意脚本的内容网站把它存进数据库当别的用户浏览到这个评论区或者打开攻击者的个人主页时服务器从数据库里取出这段内容原样塞进HTML脚本再次执行。这类XSS的杀伤力是整个XSS家族里最强的因为它的影响范围是所有访问该页面的用户而不是特定被诱导的那几个。攻击者完全可以利用存储型XSS做一个“偷Cookie并自动回传”的小脚本只要有人浏览这个被污染的评论Cookie就会被发送到攻击者控制的收集站点。在论坛、电商评价、后台工单系统里存储型XSS一旦被确认几乎都是立即走应急响应流程的。我在实际项目里修复过一个很有意思的存储型XSS某个工单系统的附件名称字段没有做输出编码攻击者把文件名改成包含脚本的字符串每次管理员打开工单列表浏览器都会把那段脚本当作文件名解析折腾了很久才发现是列表渲染逻辑没有对文本节点做特殊处理而非数据库本身被污染。2.3 DOM型XSS纯前端问题服务器干干净净DOM型XSS和前两类有一个本质区别恶意脚本的“注入点”和“执行点”都在浏览器端服务器不参与拼接过程甚至后端响应里根本看不到恶意参数。整个过程是JavaScript在读取URL参数、location.hash、document.referrer、window.name等浏览器环境对象时没有做安全检查直接把不可信数据交给了innerHTML、document.write、eval、setTimeout这类能解析并执行代码的接口。举个我最常用来演示的例子页面里有一段接收URL参数并动态改DOM的代码——let name new URLSearchParams(window.location.search).get(name); document.getElementById(welcome).innerHTML 欢迎你 name;当用户访问https://example.com/?name张三时页面正常显示“欢迎你张三”。但如果访问https://example.com/?name[脚本]innerHTML会把这段脚本直接解析成HTML元素并执行。整个过程中服务端返回的HTML是固定的没有任何一个字节来自用户输入。这也是DOM型XSS最难排查的原因你在服务端日志里翻烂了也找不到恶意请求因为它压根没到后端。那怎么区分反射型和DOM型呢最直观的测试方法是发送恶意参数后右键查看网页源代码如果在源代码里能看到恶意字符串说明是反射型如果源代码干干净净但页面却执行了脚本那就是DOM型。这个方法论我后面还会细讲。2.4 关于“变异型XSS”的一点延伸随着前端框架和WAF的普及安全圈也有人在讨论第四类叫“变异型XSS”mXSS。它的核心思路是攻击者构造的输入在上一个处理环节里看起来完全无害但是经过浏览器的解析器、DOM修改、脱敏过滤等多次处理后内容发生了“变异”原本安全的字符串最终被还原成了可执行脚本。这个地方给所有做过滤系统的开发者提了一个醒不要迷信“输入过滤”可以一劳永逸因为你不知道字符串在浏览器端会被引擎还原成什么样。真正的纵深防御一定是在输出点设卡而不是在输入端堵。3. 直接在本地搭个靶场亲手复现三类XSS攻击很多理论知识听着明白但落到实际写代码时又抓瞎。我建议每个接触Web安全的人——尤其是前端工程师——都在本地搭一个属于自己的微型靶场把三类XSS各复现一遍看到“叮”一声弹窗的那一刻你对这个漏洞的理解会瞬间从“知道”变成“懂”。3.1 搭建实验环境这里不需要云服务器也不需要买任何商业产品就用本地开发环境就好。我自己习惯用PHP内置服务器因为它不需要任何额外配置装好PHP环境后一条命令就能跑起来。在本地建一个实验目录xss-lab/里面放三个PHP文件分别模拟三类XSS。先看反射型?php // reflect.php $keyword $_GET[keyword] ?? ; echo p您搜索的关键词是 . $keyword . /p; ?再看存储型的“存储端”逻辑我用一个简单的JSON文件模拟数据库写入?php // store.php if ($_SERVER[REQUEST_METHOD] POST) { $comment $_POST[comment] ?? ; file_put_contents(comments.json, json_encode([comment $comment])); header(Location: store.php); exit; } $data json_decode(file_get_contents(comments.json), true); echo div最新评论 . ($data[comment] ?? ) . /div; ? form methodpost textarea namecomment/textarea button typesubmit提交评论/button /formDOM型用一个纯静态页面就可以创建一个dom.html!DOCTYPE html html headmeta charsetutf-8titleDOM XSS Demo/title/head body h1 idwelcome/h1 script let name new URLSearchParams(window.location.search).get(name); document.getElementById(welcome).innerHTML 欢迎你 name; /script /body /html然后在xss-lab/目录下执行php -S 127.0.0.1:8080实验环境就起来了。3.2 分别复现三类攻击的完整流程反射型访问这个地址http://127.0.0.1:8080/reflect.php?keywordscriptalert(reflected)/script回车之后如果弹窗了反射型XSS存在。这时再右击查看页面源代码你能在响应HTML里看到一句话完整的scriptalert(reflected)/script这就是“服务器直接把参数反射回页面”的铁证。存储型先正常访问store.php在评论框里提交scriptalert(stored)/script然后刷新页面弹窗出现。注意这里不需要在URL里带任何恶意参数脚本是服务器从“数据库”里取出来渲染出来的。你可以把这个恶意评论想象成新闻下的热门回复看的人越多中招的人越多。DOM型访问这个地址http://127.0.0.1:8080/dom.html?namescriptalert(dom)/script页面同样弹窗但诡异的是右击查看源代码你看到的只有那几句正常的HTML和JavaScript完全没有恶意串的踪影。恶意代码全部在浏览器内被生成和执行这就是DOM型教科书式的表现。3.3 观察三类XSS的“数据流走向”复现完后我建议你用一个表格把三类攻击的数据流梳理清楚这是建立XSS全局观最快的方法。类型恶意脚本存储位置是否经过服务器拼接用户需要点击链接吗影响范围反射型XSS不存储仅存在于URL参数是服务器拼接到响应中必须点击构造的URL仅点击者自身存储型XSS存储在服务器数据库/文件是服务器从库里取出后拼接不需要只需访问受害页面所有访问页面的用户DOM型XSS不存储仅存在于浏览器环境否纯前端JS读取并执行必须点击构造的URL仅点击者自身取决于场景这个表格每次看都有意义。它直观地解释了为什么存储型的危害最大因为影响面从“单人”扩大为“所有人”。同时它也能帮你在排查问题时快速缩小范围一看到报错点是在前端渲染逻辑里就直接把DOM型排在优先级前面。4. 三类XSS的诊断与排查技巧从“瞎找”到“精准定位”排查XSS和排查普通Bug的逻辑完全不一样。普通Bug你盯着一行代码反复看就行了XSS则必须顺着数据流走一遍数据从哪来、在哪拼接、在哪解析、在哪执行。只有把整条链路摸清楚才能确定漏洞到底属于哪一类修复位置才不会找错。4.1 先看数据流源头、中继、汇聚点排查的第一步是确认这个页面有没有接收外部数据的地方。外部数据的来源包括URL参数、表单提交、JSONP回调、跨域消息postMessage、localStorage读取值、甚至浏览器插件注入的内容。你先把所有能进入页面的数据入口列出来再看它们在代码里被引用的位置。如果数据是服务端模板变量渲染比如PHP的?php echo $var; ?、Java的${param}、Python的{{ value|safe }}且没有经过转义那大概率是反射型或存储型。如果数据是被前端JS直接读取window.location或document.referrer然后赋给DOM操作API那就是DOM型。这里有一个重要的排查心法不要只盯着alert弹窗看。很多研发习惯随便输入一个scriptalert(1)/script试一下没弹就说没漏洞。我见过太多漏报的案例其实是因为浏览器做了拦截、脚本放到了错误节点、或者输入被截断。工程师应该学会使用无害的探测向量比如在输入框里提交img srcx onerroralert(1)或者svg/onloadalert(1)尽量覆盖不同浏览器对HTML解析的差异。4.2 用浏览器开发者工具定位执行点一旦确认存在XSS下一步是在开发者工具里定位脚本到底在哪一步被执行了。我常用的方法是在Console面板里输入debugger;或者直接在关键执行API处打断点在Elements面板里看到被解析出来的恶意DOM节点右键选择“Break on”——“attribute modifications”一旦节点被修改浏览器会直接暂停在Sources面板里通过调用栈回溯看是哪个函数把恶意串传入innerHTML、eval、document.write的。举一个我实际排查过的例子。某次测试一个数据可视化大屏页面渲染千分位数字时总是不对后来发现在data.map(item item.replace(/[^\d.]/g, ))这个数据处理函数里有人把字符串直接拼到了HTML模板中导致用户可控的数据成为可执行的DOM片段。断点一打下去两步就定位了问题修复只改了一行把innerHTML换成了textContent。4.3 常见误判与排查实录这些年帮不同团队Review过不少XSS问题总结下来三个最典型的误判这里特意写出来第一“前端转义了后端就安全”。很多项目在前端用了一个escapeHtml函数就觉得问题解决了。实际上后端接口如果同时被App端、小程序、第三方系统调用前端做的转义在其他端根本不会生效。只要是输出动态内容到HTML的场景后端永远必须独立做一份输出编码不能把信任建立在别人家的代码上。第二“过滤了尖括号就安全”。只看输入方有没有过滤和这已经是很老的思路了。现在的绕过姿势五花八门全角尖括号配合浏览器解析修复、svg/onload...这种合法但不含常规脚本标签的载体、CSS中的expression()、data:协议的伪协议跳转。单纯过滤尖括号只是把攻击者从1级难度推到2级远远谈不上安全。第三“用框架就不存在XSS了”。React、Vue这些主流框架默认对插值表达式做了转义但只要你用了v-html、dangerouslySetInnerHTML、template字符串拼接生成组件源码就等于手动打开了XSS大门。框架的安全只是默认值你主动跳出去的那一刻责任就回到了自己手里。5. 防御方案别只在入口堵要在出口设卡XSS的防御并不是一件事而是一套组合拳。我按优先级从高到低给你拆开讲每一步都可以直接落地到工程里。5.1 输出编码是底线没有例外核心原则很简单所有动态内容输出到HTML上下文时都必须按位置做正确的编码。输出到HTML标签内容里进行HTML实体编码把转成lt;把转成gt;把转成amp;输出到HTML标签属性值里除HTML实体编码外还要对引号做编码防止提前闭合属性输出到JavaScript字符串里进行JavaScript转义至少处理\、、、换行符、/script输出到URL属性里进行URL编码并且检查协议白名单。我在代码Review中几乎每一次都会追问这个输出点的“上下文”是什么因为同一个字符串放在div标签里和放在a href...属性里防御转义的要求完全不同。用同一个编码函数应付所有场景是最容易出漏洞的习惯。5.2 CSP和HttpOnly是第二道防线CSP内容安全策略的意义在于“即使代码被注入也不一定执行得出来”。你可以通过响应头告诉浏览器当前页面只信任哪些来源的脚本。一旦某个不速之客的脚本尝试运行浏览器直接阻止。最基础的策略配置是Content-Security-Policy: default-src self; script-src self;这意味着页面只允许加载同源脚本所有外联脚本和内联脚本都会被拦下。当然线上业务不可能这么绝对但你要学会在这些配置里加白名单而不是图省事直接放行所有内联执行。HttpOnly属性和CSP功能互补它不能让浏览器拒绝恶意脚本但能让恶意脚本偷不到Cookie。只要敏感Cookie设置了HttpOnly它就不会暴露给JavaScript读取攻击者光有XSS也没法直接拿走会话凭证。这一对配置搭配起来用等于给系统加了两道锁。5.3 开发流程里怎么把XSS挡在发布前说了这么多防护手段真正落地时最怕的就是“知道该做但没人管”。我自己的经验是把XSS防护嵌进开发流程的每一个环节需求评审阶段PM和研发一起标注“用户输入在页面哪些位置展示”生成数据流清单技术设计阶段明确每个数据出口使用的编码API统一团队规范代码Review阶段固定增加一条检查项——“新改动是否引入了不可信的变量到innerHTML/v-html/dangerouslySetInnerHTML”测试阶段除了手工输入探测把常用XSS Payload做成自动化用例每次回归必跑上线阶段检查Nginx或网关层是否加了CSP响应头Cookie是否有Secure和HttpOnly。这些步骤看起来多但每一件都是日常开发顺手就能做的事。真等到线上被攻击者利用再复盘改造的成本比这些步骤多出十倍不止。6. 日常练手怎么从普通功能里“嗅”出潜在XSS很多朋友问过我光看完文章不去实战过两周就忘光了。这里分享几个我在日常开发中自己总结出的“嗅探”技巧你可以直接拿来用。看到一个输入框先别管它功能是什么脑子里立刻问三个问题这个输入内容会展示给谁看展示在页面的哪个位置展示的时候有没有走统一的编码组件看到一个innerHTML赋值语句不管右边是常量还是变量都养成条件反射如果右边出现了字符串拼接立刻去看拼接内容里有没有来自网络请求或地址栏的数据。看到一个后端接口把某个字段原样返回思考一下这个字段有没有可能被用户控制。不要觉得“用户只会传正常值”攻击者的想象力永远比开发更丰富。我平时在Review时甚至会专门搜索代码库里的危险API调用比如innerHTML、document.write、v-html、eval、new Function。每看到一个就追踪一次数据来源确认是否可控。这套流程熟练之后一个人Review一个几十个页面的后台项目通常半天内能筛出所有值得深挖的点。我还习惯保存一份自己的XSS速查笔记把每次遇到的不同类型的绕过姿势、不同浏览器的解析差异都记录下来。比如某些浏览器会修复不完整的标签img srcx onerroralert(1)几乎在所有现代浏览器都能触发而script标签在部分场景下会被innerHTML忽略。这些细节不靠重复实验很难记住但每次记一笔下次排查时就快一分。7. 写到最后我对XSS这条线的真实体会XSS攻击从提出到现在已经过去了很多年但它从来没有退出主流攻击面反而随着前后端分离、SPA应用的普及DOM型XSS越来越多地出现在企业应用里。原因也很好理解以前服务器渲染是主流后端对输出编码的管控相对集中现在前端框架把渲染逻辑分散到了海量的浏览器端代码里每一个开发者都有可能在某一行v-html或innerHTML里留下隐患。我个人最深的体会是防御XSS不是学几个编码函数就完事而是建立一套“永远不信外部数据”的肌肉记忆。你得清楚每一个变量从哪来、凭什么能放到这个位置、如果它不是字符串而是脚本会发生什么。这套思维一旦养成你不仅在写代码时会自动规避风险在Review别人代码时也能一眼看出问题。如果你有条件我建议每个Web开发者都在本地花一下午时间亲手把三类XSS、对应的绕过姿势、以及修复前后代码差异跑一遍。技术会议上听十遍“输出编码的重要性”不如在自己电脑上看到一次弹窗印象深刻。等到你在真实项目里再次遇到页面渲染异常脑子里能立刻出现那条数据流向图这篇文章的目的也就达到了。
做Web安全这几年只要一聊漏洞我头一个想起的不是SQL注入也不是文件上传而是XSS攻击。原因很简单大部分高危漏洞都有清晰的攻击边界要么是参数校验不到位要么是服务端配置有疏漏而XSS攻击是真正把战场拖进用户浏览器的“内鬼行为”。多数情况下攻击者甚至不需要入侵任何服务器也不需要爆破任何口令只需要让正常用户点击一个精心构造的链接或者打开一个已被污染的页面恶意脚本就能在用户的浏览器里悄悄运行起来。这篇文章我想把XSS攻击这件事彻底聊透它到底是什么、为什么浏览器会被“摆了一道”、业界常说的三大分类各自有什么特征以及我在实际测试和防御过程中踩过哪些坑。不管你是刚开始接触Web安全的新人还是写过不少接口的后端开发又或者是每天和页面样式斗智斗勇的前端工程师这篇文章都值得你花点时间读完至少能让你下次听别人说“这里有个XSS”的时候脑子里能立刻冒出清晰的三类分类和对应的排查路径。1. XSS攻击是什么先看浏览器是怎样被“摆了”一道的1.1 一句话讲透XSS原理XSS的全称是Cross-Site Scripting直译过来叫跨站脚本。有人会好奇缩写不应该是CSS吗就是因为CSS早被层叠样式表占了名字安全圈才约定俗成改用XSS。原理其实不复杂。浏览器在渲染网页时会把服务器返回的HTML、CSS、JavaScript当成“指令”去执行。正常流程下这些指令都是开发者写好的、可信的代码。可一旦攻击者能在指令里掺入自己控制的脚本情况就变了。XSS攻击本质上就是攻击者利用网站对用户输入过滤不严的漏洞把自己的恶意脚本注入到页面中浏览器在毫不知情的情况下替攻击者执行了这段脚本。打个比方你租了一个房子用户浏览器房东网站服务器给了你一把钥匙告诉你进门后可以开灯、烧水、看电视。攻击者趁房东不注意偷偷在灯泡开关里塞了一个“按下去就报警”的小机关。你回到家正常开灯机关触发小区的保安网站后台收到报警以为你家里出事了。整个过程里开灯的人是你执行命令的是房间里的电路真正获利的是那个偷偷塞机关的坏人。放在Web场景下攻击者注入的脚本一般能做什么呢它能读取当前页面里的Cookie拿到用户的登录凭证能伪造用户操作比如发一条微博、转一笔账能篡改页面内容诱导用户输入更多敏感信息甚至能把用户当前浏览器里所有能访问的接口都轮询一遍做横向探测。这些行为全部发生在用户自己浏览器中从后端日志里看请求全都来自正常用户很难追溯。1.2 攻击者为什么死盯着XSS不放这些年企业做安全建设往往对SQL注入、越权访问这些服务端漏洞投入大量精力把接口加固、数据库脱敏都做得不错但XSS却经常被忽略。原因在于它不直接攻击服务器也不会立刻造成数据泄露所以很多研发团队会把它归类为“低危问题”。但真正做过攻防演练的人都知道XSS往往是撬动整个系统的第一块砖。攻击者拿到一个存储型XSS之后根本不需要直接打服务器而是先打这个网站的使用者。比如说一个后台管理系统的某个输入框存在XSS攻击者构造请求让管理员中招管理员浏览器里的会话凭证直接被偷走攻击者拿着凭证大摇大摆进了后台——所有的防线在这一刻都形同虚设。所以不要小看任意一个能反弹参数的地方。XSS的危险程度取决于这个页面所处的位置以及能影响到的用户权限级别。普通博客的评论区XSS可能只是弹个窗但一个运维平台的告警页面出现XSS那问题就大了。1.3 XSS与CSRF的“兄弟恩怨”经常有人把XSS和CSRF搞混。两者确实容易同时出现在同一个功能里但思路完全不同。CSRF是攻击者借用户的浏览器冒充用户身份去发请求它的核心是利用了Cookie自动携带的特性而XSS是攻击者把代码直接塞进页面让浏览器在渲染时执行这段代码。换句话说CSRF是“替你做”XSS是“指挥你做”。二者最致命的组合是攻击者先用XSS往页面里注入一段脚本脚本里再藏CSRF请求这时候用户点哪儿都躲不开防御方就需要同时考虑CSP、Token校验、Cookie属性等多层机制才能压住风险。2. XSS攻击的三大分类别再傻傻分不清业内的划分方式经历了多次演变但最主流的还是按照“恶意脚本是否经过服务器存储并反射回页面”这一维度分成三大类反射型、存储型和DOM型。2.1 反射型XSS非持久型一次性打击骗的就是你的点击反射型XSS又叫非持久型XSS特点可以概括为“一锤子买卖”。恶意脚本并不存储在目标网站上而是藏在URL参数、搜索关键词或者表单提交的数据里。当用户访问这个Carry了恶意参数的链接时服务器端把参数内容原样拼接进了页面HTML返回给浏览器脚本随之被解析执行。一个很典型的场景是搜索功能。比如某个新闻网站有一个站内搜索搜索关键词会直接拼在结果页的“您搜索的关键词是XXX”这个位置并且没有做任何转义。攻击者把[脚本]作为关键词塞进链接用户一旦点击这个链接浏览器就把[脚本]当作HTML解析恶意脚本瞬间执行——攻击结束URL里的参数再也没有第二次利用机会所以叫非持久型。这类攻击的触发前提是“用户必须点链接”。攻击者一般会把恶意URL包装成短链接、二维码或者直接隐藏在邮件正文里诱导用户点击。我见过很骚的操作是攻击者把这个恶意URL嵌入到一条打折促销的短信里前面加上极具诱惑力的文案普通用户根本分辨不出链接里的特殊字符有什么危险。从防御角度看反射型XSS的检测相对容易最简单的手段是抓包看响应把参数改成alert(1)如果响应里出现同样的字符串并且浏览器弹窗了那基本就是反射型XSS。修复方式也很直接在输出点做HTML实体编码即可。2.2 存储型XSS持久型不需要点链接看一眼就中招存储型XSS也叫持久型XSS这名字一听就知道问题更严重。恶意脚本不是藏在URL里而是被完整地保存到了服务器端——可能是存进了数据库、缓存、日志文件里。之后任何用户访问包含这段恶意内容的页面脚本都会自动执行完全不需要点击任何攻击者构造的链接。最有代表性的位置是评论区、留言板、用户昵称、个人简介、富文本编辑器。攻击者在这些位置提交一段包含恶意脚本的内容网站把它存进数据库当别的用户浏览到这个评论区或者打开攻击者的个人主页时服务器从数据库里取出这段内容原样塞进HTML脚本再次执行。这类XSS的杀伤力是整个XSS家族里最强的因为它的影响范围是所有访问该页面的用户而不是特定被诱导的那几个。攻击者完全可以利用存储型XSS做一个“偷Cookie并自动回传”的小脚本只要有人浏览这个被污染的评论Cookie就会被发送到攻击者控制的收集站点。在论坛、电商评价、后台工单系统里存储型XSS一旦被确认几乎都是立即走应急响应流程的。我在实际项目里修复过一个很有意思的存储型XSS某个工单系统的附件名称字段没有做输出编码攻击者把文件名改成包含脚本的字符串每次管理员打开工单列表浏览器都会把那段脚本当作文件名解析折腾了很久才发现是列表渲染逻辑没有对文本节点做特殊处理而非数据库本身被污染。2.3 DOM型XSS纯前端问题服务器干干净净DOM型XSS和前两类有一个本质区别恶意脚本的“注入点”和“执行点”都在浏览器端服务器不参与拼接过程甚至后端响应里根本看不到恶意参数。整个过程是JavaScript在读取URL参数、location.hash、document.referrer、window.name等浏览器环境对象时没有做安全检查直接把不可信数据交给了innerHTML、document.write、eval、setTimeout这类能解析并执行代码的接口。举个我最常用来演示的例子页面里有一段接收URL参数并动态改DOM的代码——let name new URLSearchParams(window.location.search).get(name); document.getElementById(welcome).innerHTML 欢迎你 name;当用户访问https://example.com/?name张三时页面正常显示“欢迎你张三”。但如果访问https://example.com/?name[脚本]innerHTML会把这段脚本直接解析成HTML元素并执行。整个过程中服务端返回的HTML是固定的没有任何一个字节来自用户输入。这也是DOM型XSS最难排查的原因你在服务端日志里翻烂了也找不到恶意请求因为它压根没到后端。那怎么区分反射型和DOM型呢最直观的测试方法是发送恶意参数后右键查看网页源代码如果在源代码里能看到恶意字符串说明是反射型如果源代码干干净净但页面却执行了脚本那就是DOM型。这个方法论我后面还会细讲。2.4 关于“变异型XSS”的一点延伸随着前端框架和WAF的普及安全圈也有人在讨论第四类叫“变异型XSS”mXSS。它的核心思路是攻击者构造的输入在上一个处理环节里看起来完全无害但是经过浏览器的解析器、DOM修改、脱敏过滤等多次处理后内容发生了“变异”原本安全的字符串最终被还原成了可执行脚本。这个地方给所有做过滤系统的开发者提了一个醒不要迷信“输入过滤”可以一劳永逸因为你不知道字符串在浏览器端会被引擎还原成什么样。真正的纵深防御一定是在输出点设卡而不是在输入端堵。3. 直接在本地搭个靶场亲手复现三类XSS攻击很多理论知识听着明白但落到实际写代码时又抓瞎。我建议每个接触Web安全的人——尤其是前端工程师——都在本地搭一个属于自己的微型靶场把三类XSS各复现一遍看到“叮”一声弹窗的那一刻你对这个漏洞的理解会瞬间从“知道”变成“懂”。3.1 搭建实验环境这里不需要云服务器也不需要买任何商业产品就用本地开发环境就好。我自己习惯用PHP内置服务器因为它不需要任何额外配置装好PHP环境后一条命令就能跑起来。在本地建一个实验目录xss-lab/里面放三个PHP文件分别模拟三类XSS。先看反射型?php // reflect.php $keyword $_GET[keyword] ?? ; echo p您搜索的关键词是 . $keyword . /p; ?再看存储型的“存储端”逻辑我用一个简单的JSON文件模拟数据库写入?php // store.php if ($_SERVER[REQUEST_METHOD] POST) { $comment $_POST[comment] ?? ; file_put_contents(comments.json, json_encode([comment $comment])); header(Location: store.php); exit; } $data json_decode(file_get_contents(comments.json), true); echo div最新评论 . ($data[comment] ?? ) . /div; ? form methodpost textarea namecomment/textarea button typesubmit提交评论/button /formDOM型用一个纯静态页面就可以创建一个dom.html!DOCTYPE html html headmeta charsetutf-8titleDOM XSS Demo/title/head body h1 idwelcome/h1 script let name new URLSearchParams(window.location.search).get(name); document.getElementById(welcome).innerHTML 欢迎你 name; /script /body /html然后在xss-lab/目录下执行php -S 127.0.0.1:8080实验环境就起来了。3.2 分别复现三类攻击的完整流程反射型访问这个地址http://127.0.0.1:8080/reflect.php?keywordscriptalert(reflected)/script回车之后如果弹窗了反射型XSS存在。这时再右击查看页面源代码你能在响应HTML里看到一句话完整的scriptalert(reflected)/script这就是“服务器直接把参数反射回页面”的铁证。存储型先正常访问store.php在评论框里提交scriptalert(stored)/script然后刷新页面弹窗出现。注意这里不需要在URL里带任何恶意参数脚本是服务器从“数据库”里取出来渲染出来的。你可以把这个恶意评论想象成新闻下的热门回复看的人越多中招的人越多。DOM型访问这个地址http://127.0.0.1:8080/dom.html?namescriptalert(dom)/script页面同样弹窗但诡异的是右击查看源代码你看到的只有那几句正常的HTML和JavaScript完全没有恶意串的踪影。恶意代码全部在浏览器内被生成和执行这就是DOM型教科书式的表现。3.3 观察三类XSS的“数据流走向”复现完后我建议你用一个表格把三类攻击的数据流梳理清楚这是建立XSS全局观最快的方法。类型恶意脚本存储位置是否经过服务器拼接用户需要点击链接吗影响范围反射型XSS不存储仅存在于URL参数是服务器拼接到响应中必须点击构造的URL仅点击者自身存储型XSS存储在服务器数据库/文件是服务器从库里取出后拼接不需要只需访问受害页面所有访问页面的用户DOM型XSS不存储仅存在于浏览器环境否纯前端JS读取并执行必须点击构造的URL仅点击者自身取决于场景这个表格每次看都有意义。它直观地解释了为什么存储型的危害最大因为影响面从“单人”扩大为“所有人”。同时它也能帮你在排查问题时快速缩小范围一看到报错点是在前端渲染逻辑里就直接把DOM型排在优先级前面。4. 三类XSS的诊断与排查技巧从“瞎找”到“精准定位”排查XSS和排查普通Bug的逻辑完全不一样。普通Bug你盯着一行代码反复看就行了XSS则必须顺着数据流走一遍数据从哪来、在哪拼接、在哪解析、在哪执行。只有把整条链路摸清楚才能确定漏洞到底属于哪一类修复位置才不会找错。4.1 先看数据流源头、中继、汇聚点排查的第一步是确认这个页面有没有接收外部数据的地方。外部数据的来源包括URL参数、表单提交、JSONP回调、跨域消息postMessage、localStorage读取值、甚至浏览器插件注入的内容。你先把所有能进入页面的数据入口列出来再看它们在代码里被引用的位置。如果数据是服务端模板变量渲染比如PHP的?php echo $var; ?、Java的${param}、Python的{{ value|safe }}且没有经过转义那大概率是反射型或存储型。如果数据是被前端JS直接读取window.location或document.referrer然后赋给DOM操作API那就是DOM型。这里有一个重要的排查心法不要只盯着alert弹窗看。很多研发习惯随便输入一个scriptalert(1)/script试一下没弹就说没漏洞。我见过太多漏报的案例其实是因为浏览器做了拦截、脚本放到了错误节点、或者输入被截断。工程师应该学会使用无害的探测向量比如在输入框里提交img srcx onerroralert(1)或者svg/onloadalert(1)尽量覆盖不同浏览器对HTML解析的差异。4.2 用浏览器开发者工具定位执行点一旦确认存在XSS下一步是在开发者工具里定位脚本到底在哪一步被执行了。我常用的方法是在Console面板里输入debugger;或者直接在关键执行API处打断点在Elements面板里看到被解析出来的恶意DOM节点右键选择“Break on”——“attribute modifications”一旦节点被修改浏览器会直接暂停在Sources面板里通过调用栈回溯看是哪个函数把恶意串传入innerHTML、eval、document.write的。举一个我实际排查过的例子。某次测试一个数据可视化大屏页面渲染千分位数字时总是不对后来发现在data.map(item item.replace(/[^\d.]/g, ))这个数据处理函数里有人把字符串直接拼到了HTML模板中导致用户可控的数据成为可执行的DOM片段。断点一打下去两步就定位了问题修复只改了一行把innerHTML换成了textContent。4.3 常见误判与排查实录这些年帮不同团队Review过不少XSS问题总结下来三个最典型的误判这里特意写出来第一“前端转义了后端就安全”。很多项目在前端用了一个escapeHtml函数就觉得问题解决了。实际上后端接口如果同时被App端、小程序、第三方系统调用前端做的转义在其他端根本不会生效。只要是输出动态内容到HTML的场景后端永远必须独立做一份输出编码不能把信任建立在别人家的代码上。第二“过滤了尖括号就安全”。只看输入方有没有过滤和这已经是很老的思路了。现在的绕过姿势五花八门全角尖括号配合浏览器解析修复、svg/onload...这种合法但不含常规脚本标签的载体、CSS中的expression()、data:协议的伪协议跳转。单纯过滤尖括号只是把攻击者从1级难度推到2级远远谈不上安全。第三“用框架就不存在XSS了”。React、Vue这些主流框架默认对插值表达式做了转义但只要你用了v-html、dangerouslySetInnerHTML、template字符串拼接生成组件源码就等于手动打开了XSS大门。框架的安全只是默认值你主动跳出去的那一刻责任就回到了自己手里。5. 防御方案别只在入口堵要在出口设卡XSS的防御并不是一件事而是一套组合拳。我按优先级从高到低给你拆开讲每一步都可以直接落地到工程里。5.1 输出编码是底线没有例外核心原则很简单所有动态内容输出到HTML上下文时都必须按位置做正确的编码。输出到HTML标签内容里进行HTML实体编码把转成lt;把转成gt;把转成amp;输出到HTML标签属性值里除HTML实体编码外还要对引号做编码防止提前闭合属性输出到JavaScript字符串里进行JavaScript转义至少处理\、、、换行符、/script输出到URL属性里进行URL编码并且检查协议白名单。我在代码Review中几乎每一次都会追问这个输出点的“上下文”是什么因为同一个字符串放在div标签里和放在a href...属性里防御转义的要求完全不同。用同一个编码函数应付所有场景是最容易出漏洞的习惯。5.2 CSP和HttpOnly是第二道防线CSP内容安全策略的意义在于“即使代码被注入也不一定执行得出来”。你可以通过响应头告诉浏览器当前页面只信任哪些来源的脚本。一旦某个不速之客的脚本尝试运行浏览器直接阻止。最基础的策略配置是Content-Security-Policy: default-src self; script-src self;这意味着页面只允许加载同源脚本所有外联脚本和内联脚本都会被拦下。当然线上业务不可能这么绝对但你要学会在这些配置里加白名单而不是图省事直接放行所有内联执行。HttpOnly属性和CSP功能互补它不能让浏览器拒绝恶意脚本但能让恶意脚本偷不到Cookie。只要敏感Cookie设置了HttpOnly它就不会暴露给JavaScript读取攻击者光有XSS也没法直接拿走会话凭证。这一对配置搭配起来用等于给系统加了两道锁。5.3 开发流程里怎么把XSS挡在发布前说了这么多防护手段真正落地时最怕的就是“知道该做但没人管”。我自己的经验是把XSS防护嵌进开发流程的每一个环节需求评审阶段PM和研发一起标注“用户输入在页面哪些位置展示”生成数据流清单技术设计阶段明确每个数据出口使用的编码API统一团队规范代码Review阶段固定增加一条检查项——“新改动是否引入了不可信的变量到innerHTML/v-html/dangerouslySetInnerHTML”测试阶段除了手工输入探测把常用XSS Payload做成自动化用例每次回归必跑上线阶段检查Nginx或网关层是否加了CSP响应头Cookie是否有Secure和HttpOnly。这些步骤看起来多但每一件都是日常开发顺手就能做的事。真等到线上被攻击者利用再复盘改造的成本比这些步骤多出十倍不止。6. 日常练手怎么从普通功能里“嗅”出潜在XSS很多朋友问过我光看完文章不去实战过两周就忘光了。这里分享几个我在日常开发中自己总结出的“嗅探”技巧你可以直接拿来用。看到一个输入框先别管它功能是什么脑子里立刻问三个问题这个输入内容会展示给谁看展示在页面的哪个位置展示的时候有没有走统一的编码组件看到一个innerHTML赋值语句不管右边是常量还是变量都养成条件反射如果右边出现了字符串拼接立刻去看拼接内容里有没有来自网络请求或地址栏的数据。看到一个后端接口把某个字段原样返回思考一下这个字段有没有可能被用户控制。不要觉得“用户只会传正常值”攻击者的想象力永远比开发更丰富。我平时在Review时甚至会专门搜索代码库里的危险API调用比如innerHTML、document.write、v-html、eval、new Function。每看到一个就追踪一次数据来源确认是否可控。这套流程熟练之后一个人Review一个几十个页面的后台项目通常半天内能筛出所有值得深挖的点。我还习惯保存一份自己的XSS速查笔记把每次遇到的不同类型的绕过姿势、不同浏览器的解析差异都记录下来。比如某些浏览器会修复不完整的标签img srcx onerroralert(1)几乎在所有现代浏览器都能触发而script标签在部分场景下会被innerHTML忽略。这些细节不靠重复实验很难记住但每次记一笔下次排查时就快一分。7. 写到最后我对XSS这条线的真实体会XSS攻击从提出到现在已经过去了很多年但它从来没有退出主流攻击面反而随着前后端分离、SPA应用的普及DOM型XSS越来越多地出现在企业应用里。原因也很好理解以前服务器渲染是主流后端对输出编码的管控相对集中现在前端框架把渲染逻辑分散到了海量的浏览器端代码里每一个开发者都有可能在某一行v-html或innerHTML里留下隐患。我个人最深的体会是防御XSS不是学几个编码函数就完事而是建立一套“永远不信外部数据”的肌肉记忆。你得清楚每一个变量从哪来、凭什么能放到这个位置、如果它不是字符串而是脚本会发生什么。这套思维一旦养成你不仅在写代码时会自动规避风险在Review别人代码时也能一眼看出问题。如果你有条件我建议每个Web开发者都在本地花一下午时间亲手把三类XSS、对应的绕过姿势、以及修复前后代码差异跑一遍。技术会议上听十遍“输出编码的重要性”不如在自己电脑上看到一次弹窗印象深刻。等到你在真实项目里再次遇到页面渲染异常脑子里能立刻出现那条数据流向图这篇文章的目的也就达到了。
