CTFHub Web前置技能闯关

CTFHub Web 前置技能闯关：5 个入门小套路，以及它们到底在练什么

靶场：CTFHub - Web 前置技能闯关

关卡：请求方式 / 302 跳转 / Cookie / 基础认证 / 响应包源代码

这套题一共五道小题，每一道都短得让人怀疑"就这？"。但恰恰是这五个动作，对应着 Web 安全里五个最基础、也最容易在真实渗透里用上的直觉：请求是你发的你得清楚它长什么样、重定向会藏东西、客户端传来的东西不可信、编码不是加密、屏上看不见不等于没有。

下面我按"这题怎么过 + 这个套路到底能干什么 + 实战里什么时候该想到它"三层来写，把当初做题时一闪而过的念头补全。

先统一说下工具流程

这五题我都用 Yakit 做的，流程就一套，后面每题只说"改哪里"，不再重复：

打开 Yakit，启动「拦截 / 代理」；
浏览器走 Yakit 代理去访问靶场；
在 Yakit 里把抓到的请求「发送到 Web Fuzzer」；
在 Fuzzer 里改完对应字段，点发送；
看右侧响应面板的结果。

1. 请求方式：把 GET 换成 CTFHUB

题目现象：进靶场，提示大意是"把 HTTP 请求方法从 GET 改成 CTFHUB 就给 flag"。正常用浏览器访问，啥也拿不到。

怎么做：在 Yakit 拦截到的请求里，把第一行

复制代码

GET / HTTP/1.1

改成

复制代码

CTFHUB / HTTP/1.1

发到 Web Fuzzer 发送，响应里直接出 flag。

原理：HTTP 请求的第一行是「方法路径协议版本」。服务器靠"方法"来决定怎么处理这个请求------GET 取数据、POST 提交数据、HEAD 只要响应头。CTFHub 这题后端大概写了类似 if ($_SERVER['REQUEST_METHOD'] === 'CTFHUB') { 输出 flag }，所以只有用这个（甚至是不存在的）方法打过去，才触发给 flag 的分支。

这招能干什么

触达只对特定方法响应的隐藏接口。有些接口只在 POST/PUT 下才返回内容，你一直用 GET 当然啥也没有。
绕过"只允许某方法"的限制。比如某功能表面只接 GET，但真正的逻辑写在 POST 分支里，换方法就能打通。
信息收集。OPTIONS 方法会让服务器返回它支持的所有动词（Allow: GET, POST, PUT, DELETE），要是意外暴露出 PUT/DELETE，往往意味着存在未授权的写/删风险。

实战里什么时候该想到它

用 GET/POST 怎么都拿不到东西，而题目或页面话里有话地提"请求方式 / 请求方法"。
请求返回 405 Method Not Allowed------这是直白告诉你：方法选错了，换一个试试。
拿到一个 API、上传点，或者目录扫描结果，想确认它到底接不接别的方法。真实渗透里，很多"只能读不能写"的错觉，就是靠换方法（甚至用 PUT 直接传文件、DELETE 删资源）打破的。

2. 302 跳转：别被重定向带跑了

题目现象：进靶场有个按钮「Give me Flag」，点了之后页面一闪跳走，看不到 flag。

怎么做 ：用 Yakit 拦截点击按钮发出的请求，发到 Web Fuzzer 直接发送（别让它自动跟随重定向），在响应面板里就能看到 flag。

原理：302 是"临时重定向"，响应头带 Location: 目标地址，浏览器收到后会自动跳过去。但关键是------那一次 302 响应本身也是有响应体和响应头的，flag 就藏在里面。浏览器二话不说帮你跳走了，你自然什么都看不到；而代理 / Fuzzer 不会自动跳，就把 302 这次的原始响应完整摊给你看了。

这招能干什么

拿到藏在重定向响应里的数据：flag、临时 token、内部路径、报错信息，它们常常就被顺手塞在 302 的 body 或 header 里。
看清重定向链。有些逻辑要跳三四次才到终页，中间任何一跳都可能泄露东西，盲目跟随会全错过。
在真实漏洞里，302 经常出现在"登录后跳转""退出后跳转"，跳转前的响应可能临时带着敏感数据。

实战里什么时候该想到它

点按钮 / 链接后页面"闪一下"就跳走，或者你用工具发请求看到状态码是 301/302 却没看到想要的内容。
这时把工具的"跟随重定向（Follow Redirect）"关掉，直接读那次 302 的原始响应。Yakit 把请求发到 Fuzzer 发送后，右侧看到的就是 302 那次的完整内容，不会自己跳。
反过来说，如果你在测"开放重定向（Open Redirect）"类漏洞，恰恰要关注 Location 头能不能被你控制成外部地址。

题目现象 ：进靶场，抓包发现请求里带着 admin=0（或类似的管理员标识），把 0 改成 1 发送，直接出 flag。

怎么做 ：在 Yakit 拦截到的请求里找到 Cookie 行，把 admin=0 改成 admin=1，发到 Fuzzer 发送，flag 到手。

原理：服务器用 Cookie 记住"你是谁、你什么权限"。这题后端大概就是 if ($_COOKIE['admin'] == 1) { 给 flag }------它直接信了客户端传来的 Cookie 值。Cookie 存在你浏览器里，本来就能改，你把 0 改成 1，后端没做任何校验就当真了。

这招能干什么

篡改客户端可控的权限标识，实现垂直越权：普通用户瞬间变管理员，看到本不属于你的功能 / 数据。
反过来也点明一个修复原则：权限判断绝不能信客户端传来的字段。正确做法是服务端 session 里存权限，校验的是 session，而不是 Cookie 里那串明文 admin=1。

实战里什么时候该想到它

请求 / 响应里出现 admin、role、isAdmin、user、level、priv、uid 这类字眼。
你只是个普通用户，但想看看管理员才有的功能；或者题目话里话外说"管理员才能看"。
第一反应就是抓包，把这些字段的值改一改再发。真实渗透中，这是最经典的访问控制问题（对应 OWASP A01 Broken Access Control）：太多系统把"你是不是管理员"写在 Cookie 或前端里，一改就穿。
补充一句：如果 Cookie 是签过名的（比如 JWT，或者带签名 / 防篡改字段），光改值不够，你还得能伪造或绕过那个签名，否则服务端一校验就拒了。

4. 基础认证：Base64 不是加密

题目现象 ：进靶场点「click」，浏览器弹出原生的账号密码框（不是网页表单）。抓包发现请求头里有一行 Authorization: Basic xxxx，解码后是 账号:密码。题目给的附件是一份密码字典，用户名为 admin，要爆出正确密码拿 flag。

怎么做：

抓包看到 Authorization: Basic xxxx，Base64 解码，确认格式是 用户名:密码，用户名是 admin；
把附件里的每个密码，拼成 admin:密码 的格式，再各自 Base64 编码；
在 Yakit Fuzzer 里把 Authorization 头替换成这些编码后的值，批量发送；
哪个请求返回状态码 200，哪个就是爆对的；点开那个响应就能看到 flag（以及正确的账号密码）。

原理：HTTP Basic Auth 把 用户名:密码 用 Base64 编码后塞进 Authorization: Basic ... 头里。Base64 只是编码，不是加密------谁拦截到这个头，解码就能看到明文凭据。所以这题的本质是：凭据在线路上几乎是裸奔的，而且 Basic Auth 通常没有失败锁定（或锁得很松），给了弱口令爆破可乘之机。

这招能干什么

认清"编码 ≠ 加密"。任何能拦到你请求的人，都能直接读出你的明文账号密码------这也是为什么 Basic Auth 必须配合 HTTPS，否则密码等于公开。
弱口令爆破。面对原生登录框 + 弱密码字典，批量试到 200 为止，成本低、命中率高。
拿到凭据后往往不止一个 flag：这些账号密码很可能能登录真正的后台。

实战里什么时候该想到它

遇到浏览器原生弹出 的登录框（和网页表单不一样，是浏览器自带的那种），抓包看到 Authorization: Basic ...。
或者题目点名"基础认证 / Basic Auth"。
先解码看清楚格式（确认用户名，确定字典怎么拼），再针对性爆密码。真实环境里，不少路由器后台、内部运维面板、监控系统的管理入口用的是 Basic Auth 且密码很弱，是爆破的重灾区。
工具不止 Yakit / Burp Intruder，命令行也能上，比如 hydra -L user.txt -P pass.txt 目标 http-get /。

顺带提防御：Basic Auth 一定要走 HTTPS；要有失败限流 / 锁账号；密码必须强。否则跟把密码写在门上没两样。

5. 响应包源代码：屏上看不见不等于没有

题目现象：进靶场是个贪吃蛇小游戏界面，花花绿绿啥都没有。按 F12 进「元素 / Elements」，或者右键查看网页源代码，flag 就明晃晃写在 HTML 里。

怎么做：F12 打开开发者工具，看「元素」面板（或「网络 / Network」里那条请求的响应），再不行就右键「查看网页源代码」，flag 在源码里。

原理：你屏幕上看到的是浏览器渲染后的结果，而服务器返回的是原始 HTML / JS。页面用个贪吃蛇游戏吸引你注意力，但 flag 就写在返回的 HTML 源码里（注释、隐藏元素、某个 JS 变量）。渲染出来不显示 ≠ 源码里没有。

这招能干什么

养成"永远看响应源码"的肌肉记忆，别被花哨的前端骗了。
前端、HTML 注释、JS 文件里常常泄露密钥、接口地址、flag、调试信息。哪怕页面靠 JS 动态渲染，最初的 HTML 或它请求的接口响应里也常有线索。
延伸到"前端校验"类漏洞：有些答案直接写在 JS 里（比如验证码答案、权限判断），改个返回值或读一下 JS 就过。

实战里什么时候该想到它

页面看起来"啥都没有"，或者是个动画、游戏、花哨首页；题目提示"源码""仔细看"。
想确认前端到底收到了什么------F12 看 Elements / Network，或者直接查看源代码。
真实渗透里，HTML 注释泄露数据库结构、JS 里硬编码 API key、藏起来的 debug 接口，都是又多又容易摘的果子。不止 HTML，响应里的 JS、CSS、甚至图片元数据都可能藏东西。

收个尾：五个套路一张表

现象 / 线索	该想到的套路	常用动作
提示"请求方式"，或返回 405	换请求方法	改请求第一行方法，`curl -X` 试 OPTIONS/PUT
点按钮后一闪跳转，没看到内容	看 302 原始响应	关掉跟随重定向，读 302 响应体
请求 / 响应有 admin/role/level 字段	改 Cookie 越权	把权限字段改掉再发
浏览器原生登录框 + `Authorization: Basic`	解码 + 爆弱口令	Base64 解码看格式，字典爆密码
页面花哨 / 像游戏，啥都点不出来	看响应源码	F12 看 Elements/Network，查源代码

说到底，这套"前置技能"练的不是某五个具体题，而是五个安全意识：请求是你发的你得清楚它长啥样、重定向会藏东西、客户端传来的东西不可信、编码不是加密、屏上看不见不等于没有。把这五条变成条件反射，后面遇到 SQL 注入、XSS、越权那些"正菜"时，你找入口的眼光会快很多。

CTFHub Web前置技能闯关