说到XSS不少人脑子里第一反应就是弹窗alert。我以前带新人时总有人背了一堆payload真到测试环境全被拦下来就开始怀疑人生。这篇就是我从日常工作中沉淀出来的XSS常用语句和绕过思路不讨论宏大的攻击链只讲最实用的探测语句、事件写法、编码对抗和应对过滤的办法。适合三类人一是刚入门做Web安全测试的二是写业务代码被安全扫描结果追着跑的开发三是想给自研系统做防护测试的运维。老规矩先划重点文里所有内容只能在你有授权的目标上测没授权的系统碰都不要碰。1. 先搞懂XSS的判定标准再谈语句怎么写很多新手喜欢直接拿scriptalert(1)/script去试弹出来就说有漏洞弹不出来就说没漏洞。这种判断方式其实很危险因为你可能踩在“上下文不对”或“被浏览器过滤”这两个坑里还不自知。想要写出有效的XSS常用语句第一步不是背payload而是理解XSS到底在哪里触发。1.1 XSS本质是把用户输入变成了可执行代码XSS的全称是Cross-Site Scripting跨站脚本。它的本质是开发者把用户输入的内容拼接到了HTML页面里而浏览器在解析HTML时把这些内容当成了可以执行的代码。你可以把HTML解析器想象成一台自动分拣机它把页面内容分成三种包裹HTML标签、标签属性、纯文本。如果你的输入落在标签位置那它就是标签落在属性位置那它就是属性值只有极少数情况下它才是“你希望的纯文本”。一个典型的例子就是搜索框input typetext value用户输入的内容如果用户输入的是scriptalert(1)/script拼接后就变成了input typetext valuescriptalert(1)/script前一个双引号闭合了value属性后面的script就成了一个新的HTML标签浏览器照单全收直接执行。这就是“注入”的由来。判断XSS的核心标准只有一条输入是否被拼接到HTML中并且是否被浏览器当作代码执行。弹窗只是证明执行的一种方式不是唯一方式。更隐蔽也更实用的证明方式是console.log(document.domain)因为控制台的输出不会打断页面流程也不会触发一大堆安全扩展的拦截。1.2 反射型、存储型、DOM型的本质区别我见过不少人把三种XSS混为一谈结果测试时思路全乱。其实它们的区别就在于“恶意数据在哪里存、从哪里取”。反射型XSSReflected XSS恶意数据是一次性的包含在URL参数里提交给服务端服务端把参数拼到返回的HTML里。比如http://example.com/search?kwscriptalert(1)/script。数据不落库只在这一次请求-响应中生效。实际利用场景一般是诱导用户点击一个精心构造的链接。存储型XSSStored XSS恶意数据被保存到服务端数据库里评论、留言、昵称、个人签名等之后任何用户打开页面都会从库里取出这段数据并渲染执行。它最危险因为不需要诱导点击只要有人访问页面就中招。我以前接触过一个内部系统的例子有人在昵称里写了img srcx onerroralert(document.cookie)结果后台上千条审计日志全部弹窗排查起来非常痛苦。DOM型XSSDOM-based XSS这个最骗人因为它不经过服务端。整个注入过程都发生在浏览器里。常见写法是let name decodeURIComponent(location.hash.substring(1)); document.getElementById(hello).innerHTML Hello, name;这段代码在浏览器端把URL里的内容直接写进innerHTML浏览器解析后执行了恶意代码。由于请求会正常发给服务器服务器日志里看不到任何异常。我见过不少安全测试人员拿着扫描器扫了半天什么都扫不出来因为扫描器扫的是服务端响应而DOM XSS的payload只在客户端发生作用。三种形态的对比可以总结成一张表类型数据存放位置触发过程危害特点反射型URL参数不落库服务端拼接返回浏览器解析需要诱导点击一次一效存储型服务端数据库页面加载时从数据库读取持久化影响所有访问者DOM型浏览器内存/URL前端JS读写DOM时触发不经过服务端日志难追查判定思路也很简单输入框内容刷新页面后还在不在在的话优先考虑存储型URL参数里写着payload、刷新就触发优先考虑反射型页面上没有网络请求、纯前端渲染导致的优先考虑DOM型。2. 可以直接抄作业的XSS常用语句清单理解了原理下面进入正题。这部分我整理的是自己一直在维护的payload字典按使用频率排序每一条都标注触发条件和适用上下文。不需要全背挑几条记熟遇事不慌。2.1 探测阶段最稳的几条语句先说一个基本流程先输入普通唯一值比如zqzq123刷新后用F12查看这个值被渲染在HTML的哪个位置。是直接出现在页面文本里还是出现在某个标签的value属性里或者出现在JS代码里确认位置之后再决定用哪条payload。如果输入被直接拼在标签外也就是页面的纯文本区域最经典的写法是scriptalert(1)/script但这条在现代浏览器里越来越难弹出来因为很多框架默认做了输出转义标签会被转成lt;scriptgt;。另一个问题是如果系统启用了严格CSP内联脚本直接就被拦了。所以我现在更推荐用scriptconsole.log(1)/script原因很简单console.log不需要额外交互也不弹窗干扰测试而且如果页面开启了CSP控制台会明确打印“拒绝执行内联脚本因为违反了CSP策略”这个报错本身就是非常关键的信息。如果输入落在HTML标签的属性值里就需要先闭合属性scriptconsole.log(document.domain)/script如果输入落在JS代码的字符串里通常是这样;console.log(document.domain);//闭合前面的引号和括号后面用//把多余的代码注释掉保证语法不报错。2.2 事件属性不依赖script标签的触发方式实战里script标签被过滤是非常常见的事于是事件属性成了主力。事件属性的原理很简单HTML标签上有一个以on开头的事件属性当某个交互动作或生命周期事件发生时浏览器会执行这个属性里的JS代码。比如onerror是加载资源失败时触发onload是加载成功时触发onclick是点击时触发。几个高频且值得记牢的img srcx onerroralert(1)这是出镜率最高的一条。srcx指向一个不存在的资源图片加载必然失败onerror立刻执行。svg onloadalert(1)svg不需要额外属性页面加载到它时onload就会触发不用等资源失败。input onfocusalert(1) autofocusautofocus让输入框自动获得焦点焦点事件触发了alert不需要用户点任何东西。details open ontogglealert(1)details元素的ontoggle在open状态改变时触发配合open属性实现自动执行。video srcx onerroralert(1) audio srcx onerroralert(1)这两个和img的写法类似只是标签不同。当src资源加载失败时触发事件。a hrefjavascript:alert(1)点击我/a这个就不是事件属性了而是伪协议。href里写javascript:协议点击链接时执行后面的JS代码。这类语句虽然需要用户点击但如果系统过滤了所有on开头的事件它就是很好的替补。事件属性的执行条件各不相同我在项目里一般按触发条件把它们分成几组触发条件语句示例资源加载失败img srcx onerroralert(1)自动加载完成svg onloadalert(1)自动获得焦点input onfocusalert(1) autofocus页面/表单状态变化details open ontogglealert(1)用户主动交互a hrefjavascript:alert(1)点击/a如果只是为了证明漏洞存在优先选前四组不需要交互的。第五组永远可以作为兜底因为有些场景下服务端就是会过滤掉所有事件属性但不会过滤href。2.3 伪协议、iframe与data协议的补充当HTML标签和事件都不好使时还有几条容易忽略的路径。iframe srcjavascript:alert(1)/iframe这段的意思是iframe的src使用了javascript:协议浏览器加载iframe时执行代码。iframe srcdocscriptalert(1)/script/iframesrcdoc属性可以直接声明iframe内部要渲染的HTML内容它比src更灵活因为载荷是HTML而不是URL。object datadata:text/html,scriptalert(1)/script/objectdata:协议允许用URL直接携带文本内容。这里写的是data:text/html后面跟HTML源码。这条在旧版浏览器兼容性尚可现代浏览器对object的限制越来越多但作为绕过话术的参考资料仍然值得保留。还有一条容易漏的math hrefjavascript:alert(1)X/mathmath是数学标记语言它同样能识别href和javascript:伪协议。这类冷门标签的价值在于很多过滤规则只拦了script、img、svg这类常见标签根本没想到math和table也能执行代码。3. 核心内容常见过滤场景下的绕过思路拆解前面的语句都是“裸奔”状态下的而实际系统的过滤规则五花八门。有的过滤标签有的过滤关键字有的过滤引号有的干脆上了WAF。绕过思路的本质就一句话探测过滤规则寻找它漏掉的那条路。3.1 标签被过滤时的绕过思路如果提交script后显示为空说明标签被直接剥掉了。此时先不要盲目去换payload先做一个小实验输入scripttest123/script刷新看看页面里剩下什么。如果test123还在、标签没了说明是“剥标签”的过滤用标签双写就能绕过scscriptriptalert(1)/script。如果标签和内容全没了说明是“整体删除”双写不一定有用需要考虑闭合闭合符或者转占位。如果script被替换成lt;scriptgt;那就是输出编码光靠绕过字符串没用得考虑上下文是否还有其他闭合点。“标签双写”能绕过是因为很多简单的过滤实现是这样写的input.replace(script, )它只替换一次而且替换结果不重新检查。所以输入scscriptriptalert(1)/script第一次替换删除的是一对script剩下的字符拼起来正好又是一个script。这类问题在自研的搜索替换过滤里很常见。另一种常见的绕过思路是利用换行、制表符和注释符。HTML解析器在处理标签名时对制表符、换行、空格是宽松的但很多正则过滤是^script$这种严格匹配换行一进去正则就懵了scr iptalert(1)/scr ipt用/**/拆分也经常有效scr/**/iptalert(1)/scr/**/ipt这里的规则是能被HTML解析器容忍的“空白”和“注释”不一定被正则规则接受。3.2 关键字被过滤时的绕过思路很多系统把alert、prompt、confirm这几个函数名直接拉黑。这时候思路有两条一是换函数二是拼字符串。换函数最简单img srcx onerrorprompt(1) img srcx onerrorconfirm(1)如果这三个都被拉黑了再考虑拼字符串。JS是动态语言函数名可以来自字符串img srcx onerroreval(atob(YWxlcnQoMSk))atob把Base64字符串解码成alert(1)eval执行它。YWxlcnQoMSk解码后就是alert(1)这条能同时绕过硬编码关键字的过滤。字符串拼接也常用img srcx onerrortop[alert](1)top[alert]实际上等于top[alert]也就是top.alert照样能调用。如果eval被过滤了就用新版的Function构造器img srcx onerrorFunction(alert(1))()Function构造器可以从字符串生成一个函数然后立即调用。这条虽然偏进阶但确实能绕开只过滤eval的系统。3.3 引号被过滤和空格被过滤的处理办法引号过滤也很常见。比如后台把双引号和单引号全部替换为空。这时候事件属性就没法写onerroralert(1)了但HTML属性本身就支持不带引号的值img srcx onerroralert(1)没错属性值不写引号是完全合法的。但如果载荷里还需要字符串比如document.cookie可以直接用模板字符串反引号img srcx onerroralert(xss)反引号被过滤的概率比单双引号低得多这是我实测下来很稳的一个小技巧。空格被过滤的情况更恶心因为HTML标签的属性和属性之间必须有空格。替代方案是用换行、制表符甚至/。例如svg/onloadalert(1)这里用/代替了onload前面的空格。svg/onload在浏览器解析时会被当成svg onload语法合法。如果换行也被过滤可以试制表符Tab;或者HTML实体里的#9;不过兼容性要具体测。3.4 编码对抗必须理解解码顺序编码是最让人头大的一块也是踩坑重灾区。绕过的核心不是“写出好看的花体字”而是搞明白解码顺序。HTML实体编码的例子img srcx onerror#97;lert(1)#97;是a的HTML实体编码浏览器解析HTML属性时先解码实体然后执行JS所以#97;lert(1)最终变成alert(1)。但要注意这个方式只在HTML上下文有效。如果输入点在JS代码内部HTML实体不会再次解码直接写\x61lert(1)才是正解。JS字符串里的Unicode/十六进制转义img srcx onerroreval(\x61lert(1))在JS解析时\x61被解码成a于是\x61lert(1)变成alert(1)。如果系统拦截的是“alert(”这个连续字符串十六进制转义能直接打穿。URL编码的典型例子%3Cimg%20srcx%20onerroralert(1)%3EURL编码是给传输层看的服务端收到后先解码一次浏览器渲染HTML时再解码一次。如果过滤规则是在服务端解码前匹配的那么编码后的字符串大概率能绕过。但要注意如果你输入的URL编码里包含%3Cscript%3E服务端解码后变成了script然后又被输出编码那就没戏。全流程客户端URL编码 - 服务端解码 - 服务端过滤 - 服务端拼接HTML - 浏览器解码HTML实体 - 执行JS。任何一层多一次或少一次解码结果都不一样。Base64只能配合atob使用单独丢在HTML里不会自动解码。比如img srcx onerroreval(atob(YWxlcnQoMSk))atob(YWxlcnQoMSk)解码得到alert(1)eval再执行。它的作用不是绕过浏览器而是绕过那些简单的关键字正则匹配。还有一个容易混淆的点javascript:伪协议里的URL编码。比如a hrefjavascript:alert(1)click/a如果过滤了javascript:可以用java%0asc ript:这类换行编码或者#106;avascript:实体编码。具体用哪一种取决于过滤是在哪个环节生效。4. 实战记录一次测试从定位到修复的完整闭环光讲理论和语句太干了我拿一个模拟场景把这套流程串起来也是我平时自查自测时的标准动作。假设有一个内部搜索页面输入框name叫kw疑似的XSS输出点在value属性里。4.1 定位输入点的渲染上下文第一步输入一个普通字符串zqzq123比如?kwzqzq123然后打开F12的Elements面板搜索zqzq123。如果它出现在input typetext namekw valuezqzq123这说明输入点就在HTML属性里。第二步尝试闭合这个属性?kwzqzq123 onmouseoverconsole.log(document.domain)拼出来是input typetext namekw valuezqzq123 onmouseoverconsole.log(document.domain)页面加载后鼠标划过输入框控制台就会输出当前域名。如果控制台有输出说明属性闭合成功并且事件执行了。如果没反应看看是不是输出被转义成了quot;如果是就要切到其他思路比如测一下解析顺序看看HTML实体是否被二次解析。第三步如果是存储型场景就把同样的内容提交到一个评论表单然后以另一个浏览器角色访问页面看是否触发。这一步是为了区分“当前用户会话内的反射”和“所有访问者都触发的存储”。用两个完全隔离的浏览器会话测能有效避免缓存和登录态的干扰。4.2 测试过程中常见的五个坑我把这几年带新人时反复出现的问题整理成了排查表每条都对应具体的现场表现坑位现场表现排查方法输出被HTML实体编码payload显示为源码不执行看F12里是script还是lt;scriptgt;后者需要找标签外的闭合点CSP拦截内联脚本控制台报“拒绝执行内联脚本”检查响应头里的Content-Security-Policy重新评估上下文过滤规则替换为空尖括号内容被删掉输入scripttest/script观察剩余内容判断具体拦截方式触发条件不满足语句没毛病就是不执行确认是onload、onerror还是onfocus手动模拟对应行为JS语法被截断控制台报语法错误重新闭合末尾多用//注释掉后面的干扰代码其中CSP那一项最容易被误判成“没有XSS”。实际运营中的系统如果配了script-src self那么内联脚本全都会被拦但攻击者仍然可能利用同源的jsonp接口等方式绕过。作为测试人员看到CSP报错后的正确操作是确认这个报错是不是真的拦住了所有注入而不是简单得出“没漏洞”的结论。4.3 防御侧修复从同一段语句反推问题测试的目的是推动修复。如果我把上面的payload成功打出来了那修复方案其实很清晰。最底层的修复原则是针对输出位置做编码而不是拦输入。比如在Java里如果是HTML标签内输出要对、、、、做HTML实体编码如果是JS字符串内输出要用\x十六进制转义如果是URL属性里输出要用URL编码。一个简单的对比// 错误做法只过滤script String s input.replace(script, ); // 正确做法HTML属性上下文做编码 String s HtmlUtils.htmlEscape(userInput);再往上一层是启用CSP让即使有注入点也不轻易执行脚本Content-Security-Policy: script-src self unsafe-inline但unsafe-inline本身就是隐患能不开就不开。最理想的是完全禁掉内联脚本所有JS走外部文件。同时给Cookie加上HttpOnly和SameSite属性这样即使XSS能执行脚本也没法直接读到document.cookie能把“从XSS到会话劫持”这条路堵掉一半。5. 常见问题速查根据现场表现快速决策最后整理一张按“现场表现”来查症状表比对着原理慢慢推要快很多。遇到情况直接查表选下一步。出现以下现象优先怀疑这些原因弹窗不弹但控制台没有报错大概率是payload被输出编码了去看F12渲染出来的源码。弹窗不弹控制台有CSP报错系统启用了安全策略换个上下文再试或者确认同源可利用的资源。事件属性全部失效过滤规则可能直接删on开头的字符串改用伪协议或标签嵌套。alert、prompt、confirm全被拦系统对函数名做了黑名单考虑atobeval或字符串拼接。只有第一次请求成功后面全失败可能是WAF学习模式或人工临时加了封禁规则换参数名重新测。存储型XSS在其他电脑上不触发可能是前端渲染在部分版本浏览器不兼容换个浏览器看看。DOM型XSS扫描器扫不出扫描器看服务端响应DOM型问题就要手工审前端JS重点看innerHTML、document.write、eval、location相关的赋值。如果你的页面里怀疑DOM XSS最快的排查办法是全局搜索这几个JS关键词innerHTML、outerHTML、document.write、eval、setTimeout(字符串)、location、srcdoc。凡是用户输入能影响到这些API参数的地方都是高危点。我排查历史项目时发现写得很烂的旧后台系统里十个DOM XSS有八个死在innerHTML直接拼接URL参数上。还有个小技巧自己维护一个payload字典不要只存最终payload还要记录它的“适用上下文”。比如svg onloadalert(1)适合标签外直接插入 onfocusconsole.log(1) autofocus适合HTML属性闭合;alert(1);//适合JS字符串闭合。把每条语句写清楚使用前提比背100条裸payload有用得多。最后说点经验层面的东西。我见过不少人测试XSS时执着于“一定要弹窗”仿佛不弹窗就不算漏洞。其实弹窗只是证明手段真正影响危害程度的是“能执行什么代码、影响多少人、会话是否可被窃取”。同样一条console.log的payload在一个允许内联脚本的低危页面上和在一个存储了管理员会话的页面上意义完全不同。测试语句永远为场景服务绕过思路也永远从上下文出发。先把这条想明白再谈积累多少payload都不迟。