CTFHub HTTP协议通关指南：从请求方式到弱口令爆破

1. 开打之前：CTFHub的HTTP协议题到底在考什么

如果你是刚接触CTF（Capture The Flag）Web方向的新人，大概率会被推荐先刷CTFHub技能树。而技能树的第一关，就是“Web前置技能-HTTP协议”。这组题看起来简单，但它几乎是整个Web安全的地基——你后面遇到的XSS、SSRF、文件上传、命令注入，本质上都是在和你已经掌握的HTTP请求做文章。我见过不少朋友上来就刷XSS、SQL注入，结果碰到一个改了请求方法、加了自定义Header的题目就懵了，就是因为前置技能没打牢。

CTFHub的HTTP协议模块，说人话就是：让你用“发请求-看响应”这套基本动作，把HTTP协议里最常被利用的几个点全过一遍。包括请求方式、基础认证、响应包源码、302跳转、Cookie、以及弱口令爆破。这些考点不光CTF里用得上，以后你去测真实业务系统、做漏洞挖掘，遇到的基本也是这些思路——判断服务端对请求的信任边界在哪里，然后顺着这条线去试探。

这篇攻略我会从最底层的协议概念讲起，再对照CTFHub的关卡逐个拆解，最后把我刷题时踩过的坑和常用的工具操作一并整理出来。不管你之前有没有系统学过HTTP，照着这个顺序走一遍，整个前置技能模块基本就能稳稳拿下了。

2. 核心概念准备：不懂这几个名词，做题就是瞎猜

2.1 一个HTTP请求长什么样

很多新手看到抓包工具里那一大堆Key-Value就头大，其实不用怕。HTTP请求本质上就是一段有固定格式的文本，由浏览器或工具帮你组装好，发到服务器上。一个最普通的GET请求长这样：

http复制GET /index.php?name=admin HTTP/1.1
Host: challenge.ctfhub.com
User-Agent: Mozilla/5.0
Accept: */*
Cookie: PHPSESSID=abc123

第一行叫请求行，由三部分组成：请求方法（GET）、请求路径（含查询参数）、协议版本。从第二行开始一直到空行之前，都是请求头，每一行都是一个键值对，用冒号分隔。空行之后的内容是请求体，GET请求一般没有请求体，POST、PUT等请求则会把参数放在这里。

http复制POST /login.php HTTP/1.1
Host: challenge.ctfhub.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 27

username=admin&password=123456

看到这里你应该就能理解：你发给服务器的所有信息，要么在请求行里，要么在请求头里，要么在请求体里。 CTFHub的HTTP协议关卡，考的就是服务端会额外信任请求头里的哪些字段，或者会用哪些字段做判断。你只要学会改这三段里的内容，很多题就直接通了。

2.2 响应里藏着的东西往往比页面更重要

服务器返回给你的内容同样分三部分：状态行、响应头、响应体。状态行里的三位数字叫状态码，是服务端告诉你这次请求结果如何的“暗号”。

我自己刷这组题最大的体会是：做题时不要只盯着浏览器渲染出来的页面看，要养成看响应头和响应体的习惯。 CTFHub的302跳转题就是典型——页面跳来跳去，但flag就明晃晃地写在第一次响应的Location头旁边，你只要在开发者工具里点开那条请求就能看到。后面做SSRF、文件包含的时候，响应头里藏信息的操作也经常出现，这个习惯越早养成越好。

2.3 两种认证方式：Basic认证和Cookie

HTTP协议里的认证方式，CTFHub前置技能里主要涉及两种。

第一种是基础认证（Basic Authentication），就是你在浏览器里看到的那种弹窗，让你输入用户名和密码。它的原理很简单：浏览器把“用户名:密码”这段字符串用Base64编码，然后放到Authorization请求头里发给服务器。注意，Base64不是加密，它只是一种编码方式，任何人拿到这串字符都能解码还原出明文。所以CTFHub考这个点的时候，要么是让你解码，要么是让你爆破弱口令。

第二种是Cookie认证。你登录网站后，服务端在你浏览器里种下一个Cookie，之后每次请求都会带上它，服务端靠这个字段认出你是谁。很多CTF题目的考点就是“服务端信任了Cookie里的某个值”，比如用admin=0表示普通用户、admin=1表示管理员，你把它改成1再发一次请求，权限就上去了。CTFHub的Cookie题就是这种思路，改改值就出flag。

2.4 工具准备：开发者工具、Burp Suite、curl

工欲善其事，必先利其器。刷CTFHub这几关，有三样东西够用了。

浏览器开发者工具是最快上手的。按F12打开，切到Network面板，勾选Preserve log（保留日志，防止跳转后的记录被清掉），然后刷新页面，就能看到浏览器发出的所有请求。点开任意一条，Headers标签页可以看到请求头和响应头，Response标签页能看到响应体。修改请求可以用右键菜单里的“Edit and Resend”（编辑并重新发送），不用打开任何额外工具就能完成请求方法的修改。

Burp Suite是CTF和渗透测试的标配工具。它本质上是一个本地代理：你把浏览器的流量转发到Burp上，Burp再转发给目标服务器，这样你就能在流量经过时截断、查看、修改每一个请求。我建议你从一开始就学着用它，因为后面的Web题目（XSS、SQL注入、文件上传）几乎都靠Burp吃饭。使用思路很简单：启动Burp -> Proxy标签 -> Intercept is on -> 浏览器里操作 -> 请求被拦下 -> 改完点Forward放行。

curl是Linux终端里的HTTP请求工具，一条命令就能发一个自定义请求。它适合快速验证思路，比如curl http://目标地址，加上-X POST指定方法，加上-d带数据，加上-H带请求头，加上-b带Cookie。后面我会在实战环节具体演示怎么用它。

这三样工具不需要全精通，但至少开发者工具和curl要熟练，Burp可以边刷题边熟悉。

3. 逐个拆解：CTFHub HTTP协议关卡的完整通关思路

3.1 请求方式：别让思维卡死在GET和POST上

这道题在题目里提示了“HTTP请求方法”，但页面本身可能什么都没显示。CTFHub的这道题我印象中是这样的：页面提示请求方式只允许GET，但你直接访问时却提示方法不对，或者反过来——页面是GET请求，但服务端在等你用其他方法再试一次。

我见过很多新手在这道题上卡住的共同原因，是根本不知道除了GET和POST还有别的请求方法。实际上HTTP协议定义了九种常用方法：GET、POST、PUT、DELETE、HEAD、OPTIONS、PATCH、TRACE、CONNECT。服务器可以只接受其中某一种，而CTFHub很多题就是让你换一个方法去碰运气。

用curl做这道题的思路如下：

bash复制# 先试试正常的GET，看看提示什么
curl http://challenge.ctfhub.com/target

# 再用POST试一次
curl -X POST http://challenge.ctfhub.com/target

# 如果还不行，就用HEAD、OPTIONS、PUT依次试
curl -I http://challenge.ctfhub.com/target
curl -X OPTIONS http://challenge.ctfhub.com/target
curl -X PUT http://challenge.ctfhub.com/target

这道题的核心考点是：服务端并不关心你是不是“浏览器”，它只根据请求方法做判断。 只要你把方法改成它期望的那个，哪怕你终端里一行命令都能拿到flag。有些变种题会通过OPTIONS方法向你展示允许的请求方式，看到Allow: GET, POST这样的响应头就说明服务端在告诉你答案了。

模拟场景：如果你用浏览器访问发现页面一直正常显示但没flag，右键查看源码也没有，这时候第一反应就应该是“我是不是漏掉了某种请求方式”。直接打开开发者工具，在Console里执行fetch(‘目标地址’, {method: ‘POST’})，看返回内容有没有变化。这种方式比开Burp更快，适合快速验证。

3.2 基础认证：Base64不是加密，是明文的马甲

这道题的画面是一个弹窗，要求输入用户名和密码。如果你随便输，浏览器会左下角或页面上提示401 Unauthorized。对新手来说，最直观的困惑是：“我哪知道用户名密码是什么？”

答案就藏在HTTP请求的Authorization头里。用开发者工具或Burp抓包，找到类似下面这样的请求：

http复制GET / HTTP/1.1
Host: challenge.ctfhub.com
Authorization: Basic YWRtaW46YWRtaW4=

Basic 后面那串字符就是“用户名:密码”的Base64编码。你在终端里执行：

bash复制echo "YWRtaW46YWRtaW4=" | base64 -d

输出结果就是admin:admin——用户名是admin，密码是admin。这算是弱口令的典型示例。CTFHub这道题里，密码往往就是一个常见弱口令，比如admin、password、123456之类，你可以用Burp导入一个弱口令字典爆破几轮。

关键原理一定要吃透：服务端收到这个Header后，用Base64解码拿到明文，再和它存储的用户名密码比对。因为Base64编码是公开的、可逆的，所以只要你在抓包里看到Authorization头，就等于把密码挂在脸上。这也是为什么现在主流网站都不再用Basic认证，而是用表单登录+Session/Cookie机制——HTTP协议本身就太“诚实”了，任何放在Header里的东西都是跟着请求明文传输的。

做题技巧：如果你不想记Base64命令，可以在线解码，也可以直接用Burp的Decoder模块。但我建议你亲手敲一两次base64 -d，因为后面做别的题时，响应体里偶尔会出现Base64编码的flag片段，你得具备这种“看到乱码先想到解码”的条件反射。

踩坑提醒：解码出来如果格式是用户名:密码，中间的冒号是英文冒号，千万别看成中文冒号。我见过有朋友卡了半小时，最后发现是把admin:admin输成了admin：admin（全角冒号），服务端比对根本过不了。

3.3 响应包源码：flag未必在渲染后的页面上

这道题名听着像“入门题”，实际上考的是查看响应报文的能力。页面可能只是个空页面或一句话文字，右键查看源码后发现HTML里也没flag——或者反过来，右键查看源码直接就看到了。

CTFHub这道题的核心提示我记得是“请求包和响应包”。我当年做的时候，页面长得特别普通，右键查看源文件也没看到任何内容，后来才意识到：flag可能在响应头里，而不是响应体里。 用开发者工具刷新页面，点开第一个请求，在Headers页面往下翻，一长串响应头里可能就藏着一行Flag: ctfhub{...}。

遇到这类题，我的固定动作是：

1. F12打开开发者工具，刷新页面。
2. 逐个点开Network面板里的请求，查看Headers。
3. 如果Headers里没有，再看Response标签页里的原文。
4. 如果页面有跳转，注意查看跳转前的那个请求（勾选Preserve log是关键）。

很多新手不知道右键查看源码（View Page Source）和开发者工具Network里看到的响应体有什么区别。前者是浏览器解析后的HTML源码，后者才是服务器返回的原始内容。在部分反爬或混淆场景里，两者会不一致。CTFHub这道题就是故意让源码长得“平平无奇”，把flag放在响应头或原始响应里等你发现。

经验之谈：养成一个习惯——不管题目提示是什么，先F12看Network，再右键看源码。顺序别反了。很多时候你还没看源码，Network面板里已经把答案亮出来了。

3.4 302跳转：flag往往在第一次响应的头里

这道题的情境是：你访问页面，浏览器“嗖”地一下跳到了另一个地址，然后那个地址显示404或什么内容都没有。很多人此时就卡住了，不知道去哪找flag。

302跳转的考点是：重定向只是服务端给你一个“去别处”的指令，真正有用的信息往往已经在第一次响应里了。 过程是这样的：

1. 你请求/index.php。
2. 服务端返回302，同时响应头里带着Location: /admin.php，指示浏览器跳转。
3. 浏览器自动请求/admin.php，页面显示空白或404。

问题在于：flag可能就藏在第一次/index.php的响应头里，而浏览器遇到302后根本不渲染响应体，直接跑去请求Location了。你眼睛只盯着最终页面，自然看不到任何东西。

解决办法很简单：

bash复制# curl默认不会跟随重定向，正好用来查看第一次响应
curl -v http://challenge.ctfhub.com/target

# 如果想同时查看最终响应，加 -L 参数
curl -L -v http://challenge.ctfhub.com/target

在输出里，你会看到HTTP/1.1 302 Found，接着是一堆响应头，flag就混在这一堆字段里。用Burp的Repeater也能看到同样的效果——Repeater默认不会自动跟随跳转，所以特别适合观察每一次响应的原始内容。

这个考点在真实场景中也有对应：很多网站会把URL参数带在302跳转里，或者把敏感信息放在临时Cookie里，客户端如果盲从跳转就可能把信息丢在半路。做题时记住一句口诀：看到跳转，先拦下第一步看响应头。

3.5 Cookie：改一个值可能就出flag

Cookie题的典型特征是：页面有一个“欢迎普通用户”的提示，或者某个按钮点了没反应。题目提示让你“欺骗浏览器”。

CTFHub的Cookie题，思路是你在请求头里加上一个Cookie字段，比如admin=1。具体流程是：

1. 先用浏览器或curl正常访问，看到没有flag的页面。
2. 给请求加上Cookie: admin=1，再发一次。
3. 如果服务端代码写得简陋（比如直接读Cookie里的admin值判断身份），flag就出来了。

用curl操作：

bash复制curl -v -H "Cookie: admin=1" http://challenge.ctfhub.com/target

如果你用开发者工具的“Edit and Resend”，也是一样的原理——在请求头里加上Cookie字段，然后发送。这道题不需要任何爆破或复杂操作，核心就是理解“服务端会信任客户端传来的Cookie”。

延伸思考：Cookie在真实系统里通常是一串随机生成的Session ID，服务端只认这串ID对应的会话数据，客户端本身改动不了里面的权限信息。但CTF题目为了教学目的，经常故意把权限判断写“傻”——直接读Cookie里的字段。你做这道题学会的是一种测试思路：拿到一个请求，先看哪些字段可以被客户端控制，再想服务端会不会信任它。 这个思路后面应用在逻辑漏洞、越权测试里，价值非常大。

3.6 密码爆破：弱口令字典是CTF必备工具

这题一般放在HTTP协议模块靠后的位置，考的是弱口令爆破。页面是一个登录表单，需要用户名和密码。用户名一般是admin，密码则需要你用字典爆破。

我习惯直接上Burp的Intruder模块。基本配置如下：

1. 启动Burp，确保浏览器代理指向Burp的8080端口。
2. 在浏览器里随便输入一个用户名密码，提交登录，让Burp抓到那个POST请求。
3. 把请求发送到Intruder（快捷键Ctrl+I）。
4. 在Positions标签页里，把密码参数的值选中，点击“Add §”标记为爆破位置。
5. 在Payloads标签页里，选择“Simple list”，加载一个弱口令字典。
6. 点击Start Attack，观察响应长度——长度和其他结果明显不同的，基本就是成功登录的响应。

弱口令字典可以自己攒，也可以用GitHub上开源的常用字典。CTFHub这道题的密码绝大概率是常见弱口令，比如admin、password、123456、admin123等。如果你不想用Burp，可以用curl脚本循环尝试，但Burp的图形化界面在观察响应差异时更直观。

一个容易踩的坑：爆破时发的请求如果多，目标服务器可能会把你的IP封掉。好在CTFHub是比赛环境，通常不会触发封禁，但你在刷其他靶场时要注意控制速度。另外，有些题的登录接口会有CSRF Token，每次请求都需要先获取一次Token再带着提交，这种题用Burp爆破时会麻烦一些，需要先写一个从响应中提取Token的规则，但CTFHub的密码爆破这题一般不会做这种增强。

4. 实操过程与工具链：从抓包到改包一整套流程

4.1 用开发者工具完成一次完整的“改包重发”

我详细走一遍用Chrome开发者工具解题的标准流程，以修改请求方法为例：

第一步：打开题目页面，F12进入开发者工具，切到Network面板，勾选Preserve log。

第二步：刷新页面，面板里会出现几条请求记录。找到你访问的那个主请求（一般显示为文档类型，文件名通常是index.php或类似）。

第三步：右键点击这条请求，选择“Edit and Resend”（编辑并重新发送）。Chrome会弹出一个编辑器，里面是这条请求的完整报文。

第四步：在请求行里把GET改成POST，或者按题目需要加上请求头，比如加一行X-Forwarded-For: 127.0.0.1（有些题会让服务器以为请求来自本地），然后点Send。

第五步：观察返回结果。新发出的请求会显示在Network列表的后半部分，点开它查看响应。如果返回的响应体里有flag，直接复制提交。

这个流程我强烈建议你多练几遍，因为后续CTFHub的Web题、以及真实环境里的接口测试，本质都是这个动作——抓到一个请求，改一改再发出去，对比差异。你不需要在脑子里记住题目页面长什么样，只需要学会抓住“请求”这个核心对象。

4.2 curl终端的快速解题链路

有时候开Burp整套流程太重，只想知道一个请求返回什么，curl是最快的。我列一个常用参数速查表：

比如CTFHub基础认证那题，一条命令就能过：

bash复制curl -u admin:admin http://challenge.ctfhub.com/target

再比如Cookie题：

bash复制curl -H "Cookie: admin=1" http://challenge.ctfhub.com/target

为什么推荐curl：因为它没有图形界面，也正因为没有图形界面，你的思路会更直接——你想让请求变成什么样，你就按参数拼接一条命令。同时curl在Linux服务器上也都自带，做内网测试时比图形工具顺手得多。

踩坑提示：curl的-d参数默认会使用application/x-www-form-urlencoded格式，如果目标是JSON接口，你需要加上-H "Content-Type: application/json"，同时数据写法是-d '{"key":"value"}'。虽然CTFHub的HTTP协议前置题基本用不到JSON提交，但你迟早会碰到，顺手记住没坏处。

4.3 Burp Suite的入门配置思路

Burp Suite是个功能很重的工具，但刷CTFHub只需要用到三个核心模块：

• Proxy：拦截浏览器流量，方便断点观察和修改。
• Repeater：手工改包后反复发送，是CTF解题的主力模块。
• Intruder：自动化爆破，密码爆破题主要靠它。

新手最容易卡住的是代理设置。步骤是：

1. Burp启动后，Proxy -> Options，确认监听地址是127.0.0.1:8080。
2. 给浏览器配置代理指向127.0.0.1:8080（Chrome可以装SwitchyOmega插件，或者直接用Firefox的代理设置）。
3. 浏览器里访问http://burp，下载Burp的CA证书并安装信任，否则HTTPS流量会被浏览器拦截。
4. 在Proxy -> Intercept里把Intercept is on关掉，让流量正常透传。需要抓包时再打开。

我个人的使用习惯是：平时Intercept保持关闭，不拦截所有流量，只在需要改动请求时打开Intercept，或者直接右键目标请求发送到Repeater。这样既不会干扰正常上网，又能随时抓到需要的包。

经验之谈：Burp的搜索功能很有用。题目返回内容很多时，可以在Burp的Response区域按Ctrl+F，搜flag、ctfhub等关键词，直接定位关键信息。

5. 常见问题与排查技巧实录

5.1 一张速查表解决大部分卡点

刷CTFHub HTTP协议这几题时，我跟着学员复盘过很多次，把最常见的卡点整理成了一张表。你遇到问题时先对照一下：

5.2 刷题时一定要避开的几个坑

第一，千万别盯着浏览器页面不放。CTF的题目核心是“服务端返回了什么”，不是“浏览器渲染了什么”。你在页面里看半天没结果，很可能flag就在某个响应头的犄角旮旯里。一定要养成F12开Network的习惯。

第二，看清楚方法大小写。HTTP方法是区分大小写的，GET和get是有区别的，虽然大部分服务器做了兼容处理，但把get发出去还是显得不专业。同理，Header的字段名大小写不敏感，但值通常敏感，别随手改错。

第三，留意空行。如果你用手工构造HTTP报文（用nc或者Burp的Repeater），请求头和请求体之间必须有一个空行。少了这个空行，服务端会认为整个报文都是请求头，请求体会被忽略，导致你POST的数据永远传不过去。这是新人最容易犯的隐蔽错误。

第四，Cookie不要弄丢。做题时，服务端如果设置了Cookie，你要在后续请求中带上它。尤其是涉及两步或三步流程的题，不带Cookie常常会重置你的状态。curl里可以用-c保存Cookie、用-b加载Cookie，或者手动把Cookie字符串复制到-H参数里。

第五，关注题目页面里的提示文字。CTFHub有些题会在页面上明确写“只能使用本地访问”或“管理员才能看到”这类的提示，对应的是需要添加X-Forwarded-For: 127.0.0.1或X-Real-IP: 127.0.0.1这类头。这类题虽然不属于HTTP协议模块的必修内容，但在Web题里很常见，你早点知道不亏。

5.3 我个人的刷题顺序和心态建议

CTFHub技能树的HTTP协议模块，我给出的通关顺序是：请求方式 -> 响应包源码 -> 基础认证 -> Cookie -> 302跳转 -> 密码爆破。这个顺序基本是从最简单到最复杂的递进，也符合“先理解请求结构，再学会改包，最后做自动化爆破”的学习节奏。

刷题时不必追求“一把过”。我当年做基础认证那题的时候，第一次连Burp都不会开，看了一下午文档才明白——原来那些看起来很高端的CTF工具，底层就干了一件事：把请求原原本本摆在你面前，让你改。想通了这一点，后面所有题都变得轻松了。

最后再分享一个实用技巧：做题时准备一个文本文件，把题目地址、你尝试过的请求方法、加过的请求头、以及每次的响应变化都记下来。这不是浪费时间，很多CTF题目的思路就是在一次次对比中浮现的——你加了某个头，响应多了一段内容；你换了某个方法，响应状态码变了。这些细节记下来，既是自己的复盘素材，也是以后写WriteUp的原始资料。我现在刷题仍然保持这个习惯，强烈推荐你试试。