1. 为什么每一道Web题都绕不开HTTP协议

如果你打开CTFHub技能树，Web方向第一块砖就是“Web前置技能-Web-http协议”这一支线。这一组题表面上数值不多，但它是整棵技能树的地基。我在带新人入门CTF时，几乎不会让他们一上来就冲SQL注入、XSS，而是先逼他们把这组HTTP协议题打穿。原因很简单：所有Web漏洞都发生在HTTP请求与响应之间，哪里校验了参数、哪里信任了Header、哪里暴露了信息，读懂这些，后面所有题目都会顺畅很多。

CTFHub把这一组题命名为“前置技能”是有道理的。它不像后面的漏洞题那样要拼利用链，也不需要你事先掌握什么漏洞原理，它考的就是一件最基础的事：你会不会用工具、改请求、读响应。别小看这件事，我见过很多刷题到中期的同学，遇到一个“改Header”的简单题反而卡住，原因就是对请求格式不够敏感。而这条线恰好能把这种敏感度训练出来。

适合谁来刷这条线？两类人。第一类是刚接触CTF的新手，把这组题当成抓包工具的第一堂实操课；第二类是已经开始刷Web但总感觉卡在“不知道从哪里下手”的选手，回头补这组题会产生一种“原来题目早就告诉你答案”的后知后觉。我自己在第一次完整刷完这六道题之后，最强烈的感受是：HTTP协议不是拿来背的，是拿来“看包”的。下面把我整个通关过程、踩过的坑、以及每道题背后对应的协议细节一起拆开讲。

1.1 这组前置题到底在训练什么

先说结论：这组题训练的是“协议感知”，说得再直白一点，就是让你养成拿到题目先抓包、先看请求行和Header的习惯，而不是先双击打开网站盲目点按钮。

大多数新手在刷Web题时有一个共同的路径依赖：浏览器打开页面，用眼找flag，找不到就去看源码。这种方式对付极少数签到题有用，可一旦遇到跳转、认证、协议版本这类偏门考点，就会彻底失效。CTFHub的HTTP协议支线故意把这些依赖全部打碎。比如“请求方式”那道题，你光看页面根本不知道发生了什么，必须抓包重放；“302跳转”那道题，如果你跟着浏览器走，反而会跳去一个无法访问的地址。这些都是出题人精心设计过的“反直觉”点。

这套训练的本质，是把“使用浏览器的使用者视角”切换成“构造请求的客户端视角”。当你开始用Burp Suite或者命令行curl去思考问题，才算真正进入Web安全的大门。所以我个人一直建议：刷这条线的时候，IDE可以不装，但抓包工具必须全程开着。

1.2 拿到Web题的第一反应：先看请求

把题目抽象成一句话，你永远要回答三个问题：服务器收到了什么？服务器返回了什么？差异在哪里？

以CTFHub这套题为例，每一道题都围绕这三句话展开。“请求方式”考的是请求行的第一个单词；“302跳转”考的是响应头里的Location；“Cookie”考的是请求头里的Cookie字段；“基础认证”考的是Authorization头里的Base64；“响应包源代码”考的是响应体里被忽略的注释和隐藏节点；“请求协议练习”则把请求行、请求头、请求体、协议版本全考了一遍。看明白了吗？题目只是马甲，核心永远是“包”。

这个习惯比背十个漏洞原理都重要。我在实际参与一些安全项目时，排查问题也是这个思路：先看流量长什么样，再猜逻辑哪里出错。网络上那些“看一眼URL就知道漏洞”的玄学并不存在，真实战场都在请求和响应里。

2. 通关前必须具备的HTTP知识底座

有人会说：HTTP协议不是大学课本里都有嘛，不就是请求响应吗？话虽如此，CTF出题的角度和课本完全不同。课本讲的是“标准是什么”，CTF考的是“哪里能动手脚”。所以这一节我不打算复述整本协议，而是挑六道题里真正会用到的基础知识，讲清每个知识点和解题的挂钩点。

2.1 请求-响应模型：一次交互的全过程

一次HTTP交互，简单到你甚至可以在脑海里模拟：客户端先发一个请求，请求由三部分构成——请求行、请求头、请求体；服务器收到后返回一个响应，响应同样由三部分构成——状态行、响应头、响应体。

请求行长这样：GET /index.php HTTP/1.1。第一个单词是方法，中间是请求路径，最后是协议版本。这三者分别对应CTFHub里的“请求方式”“请求协议练习”等考点。响应行的第一行则长这样：HTTP/1.1 200 OK，状态码直接决定你要不要继续往下看。

请求头是键值对，形如Host: xxx、User-Agent: xxx、Cookie: xxx。响应头同样，比如Location: xxx、Set-Cookie: xxx、WWW-Authenticate: xxx。很多答案就藏在里面，只是你以前从没注意过。

请求体则是在POST之类的方法下才会出现，接在空行之后，存放着表单参数、JSON数据或文件内容。请求头里有个字段叫Content-Length，它告诉服务器请求体到底有多长。这是个非常关键的知识点，后面我实操时会再次提到——很多人就因为改动请求方法后忘了同步Content-Length，导致请求体被服务器截断或忽略。

2.2 请求方法与状态码：考点的高频词

请求方法不需要全背，但CTF里高频的是这几个：

• GET：请求资源，参数通常拼在URL问号后面。
• POST：提交数据，参数在请求体里。最常用，也最常被考。
• HEAD：只获取响应头，不返回响应体。适合用来探测资源是否存在。
• OPTIONS：查询服务器支持哪些方法。
• PUT、DELETE：在某些题目里会暗示“你试试用别的动词”。

CTFHub第一题那个“请求方式”，考点就是让你把GET换成服务端要求的其他方法。你别觉得简单，很多新手第一反应是去改URL参数，而不是改动词。为什么？因为思维还停留在“资源定位”上，没有进入“服务端逻辑由方法分支”的思考模式。

状态码方面，记住几个最常见的就够了：

• 200：成功，响应体里有货。
• 302/301：重定向，响应头里带Location字段。
• 401：未认证，响应头里可能带WWW-Authenticate。
• 403：禁止访问，权限不够。
• 404：资源不存在，但也可能是路径没找对。
• 500：服务端逻辑出错，在CTF里有时是故意报错来泄露信息。

其中302和401在这组题里各占一道，理解它们等于直接完成20%的进度。

2.3 请求头与响应头：那些能直接拿分的字段

把关键Header拉出来，和题目一一对应：

我不建议死记硬背，而是把每个Header当作一个“可以被篡改的变量”。CTF题目的本质就是让这些变量满足某种条件后，服务器给你想要的响应。视图上，页面是死的；协议上，一切皆可变。

2.4 HTTP与HTTPS/HTTP/1.1与HTTP/2：协议细节的分水岭

CTFHub的“请求协议练习”那道题，会直接考你对协议版本和传输方式的理解。HTTP默认跑在80端口，HTTPS跑在443端口，后者多了一层TLS/SSL加密。抓包工具如果要看HTTPS明文，就必须安装证书并作为中间人解密。这个过程经常劝退新手，因为不装证书，Burp里看到的全是一堆无法解析的证书错误。

协议版本上，HTTP/1.1是当前Web题目的默认版本，请求行里写HTTP/1.1即可。HTTP/2则完全不同，它不再是纯文本行结构，在Burp里表现为:method伪头字段。CTFHub这道题默认用HTTP/1.1，所以你在Burp里直接编辑原始请求行即可。还有一个重要细节：题目地址如果是https://，你在Repeater里发送时要把目标端口写成443，否则连接直接失败。这算是协议题的天然门槛，理解了端口和加密层，后面怎么改包都是顺理成章的事。

3. CTFHub HTTP协议通关实录：每个考点逐个拆

下面是我实际刷这组题的完整记录。为了便于对照，我把每道题的“题目现象”“错误示范”“正确解法”“背后的协议点”都串在一起写。所有请求地址我用占位符表示，只保留结构，不影响理解。

3.1 请求方式：把GET改成POST的正确姿势

题目名“请求方式”，进入环境后就是一个看起来普普通通的页面，页面上通常有一句提示，告诉你需要用指定的请求方式访问。我的第一反应是抓包看原始请求：

GET /index.php HTTP/1.1 Host: xxx.xxx.xxx.xxx User-Agent: Mozilla/5.0 ... ...

正常用浏览器访问时，方法就是GET。但题目给出的提示，几乎就是明说“只有用CTF的方式发送请求才能获得flag”。这里的“CTF”显然指的不是GET，那就按常见方法逐一试：POST、PUT、HEAD，优先级最高的是POST。

实操过程中，我建议直接打开Burp Suite的Repeater模块，把抓到的GET请求整段贴进去，然后把第一行的GET改成POST。这里有几个新手必踩的坑：第一，不要忘了同步修改Content-Length。如果POST请求带了请求体，但长度不对，服务器可能根本读不到参数；如果不带请求体，那也要保证Content-Length不出现或者为0。第二，POST请求如果携带表单参数，一定要写Content-Type: application/x-www-form-urlencoded，不然服务器解析不出来。这道题一般只需要你改方法，不改参数就能拿flag。

改完之后点击发送，flag就直接出现在响应体里。看起来是不是很简单？但我见过不少人卡在这里，因为他们用的是浏览器自带开发者工具，改了URL里的参数但方法没变，或者用了一个不支持自定义请求方法的工具。这里的经验是：不是所有工具都能改请求方法，而Burp Repeater是万能的。

3.2 302跳转：别跟着浏览器走

这道题的口味和上一题完全不同。我用浏览器直接打开题目地址，页面迟迟不出来，最后提示“无法访问此网站”。有些同学到这就会以为环境坏了，但其实坑就在名字里：“302跳转”。

先抓包看响应，你会发现第一次请求返回的状态行是：

HTTP/1.1 302 Found Location: /flag

这就是考点。服务器并没有直接给你内容，而是告诉你“资源在另一个地址”，浏览器傻乎乎地跟随了跳转，结果跳到了一个无法访问的位置。你要做的是：用Burp Repeater手动构造这个原始请求，或者直接用curl不带-L参数发送，然后人工查看响应头里的Location。

curl -I http://目标地址/index.php

-I参数会发送HEAD请求，只返回响应头，你就能直接看到Location字段的值。然后对着Location的值重新发起请求，flag到手。

这道题真正的价值，是让我意识到“浏览器的自动行为会掩盖协议真相”。日常开发中你根本不关心302背后跳去哪；但在CTF里，来回跳转可能藏着flag、也可能藏着SSRF的入口。从那以后，我抓包时会特意关闭Burp的自动跟随重定向，把每一步跳转都分开看，收益很大。

3.3 Cookie：身份凭证就藏在这里

第三题“Cookie”，打开页面后没有明显输入框，只有一行字提示，让你以某种身份登录。看起来无从下手，但题目已经把答案写在名字里了：看Cookie。

抓包后，请求头里一般是空的，或者带了会话ID。此时我需要伪造一个管理员身份的Cookie。做法很简单，用Burp拦截请求，在请求头里手动加上一行：

Cookie: admin=1

然后发送。如果flag没出来，可以试试admin=true、admin=admin等常见组合。不过CTFHub这道题基本就是admin=1，发送后响应体直接给flag。

这里顺带说一下Cookie和Session的区别。Cookie是存在客户端的一段明文键值对，服务器通过它来识别你是谁。在真实的Web应用里，服务端不会只靠一个admin=1就放行，但在CTF这种简化场景中，出题人把漏洞点放在了“信任客户端的输入”上。这道题的意义在于让你理解：请求头里看似无用的字段，其实是服务端逻辑的首个入口。以后你学到越权、会话固定、身份伪造，都会从这里延伸出去。

操作时也有个细节：在Burp里加Cookie，位置必须在请求头区，和Host、User-Agent一样逐行排列，中间用冒号分隔。不要加在请求体里，也不要写到Referer后面，否则都是无效的。测试时如果页面里包含着其他Cookie，可以按分号拼接，例如Cookie: PHPSESSID=abc; admin=1。

3.4 基础认证：Authorization头的前世今生

这一题有点意思，页面打开后，浏览器直接弹出一个内嵌的登录框，要求输入用户名和密码。这就是HTTP Basic Authentication，一种最古老的HTTP认证方式。

支持Basic认证的服务器，在未认证状态下会返回401状态码，并带一个响应头：

HTTP/1.1 401 Unauthorized WWW-Authenticate: Basic realm="Flag"

这里的realm表示领域，有些题目会直接把它当作线索。Basic认证的机制是：把“用户名:密码”拼成字符串，再做Base64编码，然后放在请求头的Authorization字段里。例如用户名为admin、密码为admin时：

printf 'admin:admin' | base64

得到的结果是一串Base64值。然后在Burp里发送请求时，手动加上：

Authorization: Basic YWRtaW46YWRtaW4=

发送后服务器返回200，flag就在响应体里。

这类题通常有个“暴力枚举”的误区。很多新手以为要逐个尝试用户名密码，但CTFHub此处的提示已经说明默认凭据就是常见的弱口令组合。同时我也见过有人直接把Base64的=去掉、或者把Basic拼错成Basis，这些细节都会导致认证失败。实战中还有一个坑：如果你用对了凭据，浏览器却一直弹登录框，多半是因为认证信息没被保存，重新启动抓包工具或者换无痕窗口再测即可。

3.5 响应包源代码：参考答案就在包里

“响应包源代码”这题，名字已经像开卷考试了。进入页面，页面上没有输入框，也没有明显的功能点，就一张图或一个按钮。很多人习惯按Ctrl+U查看网页源码，但看半天也没找到flag。

问题出在“响应包”这三个字上。你不仅要看浏览器渲染后的HTML，更要看服务器返回的完整响应内容。用Burp抓包，切到Repeater或者直接在Proxy History里查看原始响应，你会看到类似这样的片段：

<!-- flag{...} -->

或者有一段被注释掉的JavaScript变量、一个隐藏的div、甚至是被缩进到响应尾部空行里的flag。这类题目考验的其实是“信息收集的细致程度”。我在实际渗透测试时也经常遇到类似情况：备份文件、注释信息、调试接口，全都藏在正常响应的边角料里，没有扫描器，但你需要学会用肉眼去搜。

推荐一个检查顺序：先看HTML注释，再看JS文件引用，然后看响应末尾的空白区，最后用Burp的Find功能直接搜flag{。一次性就能扫出所有隐藏信息。这道题不需要任何高级技巧，却让我养成了“拿到任何HTTP响应都先全局搜flag”的反射习惯。

3.6 请求协议练习：把整套规范串起来

这组题的最后一道通常叫“请求协议练习”，也是整个支线里综合度最高的一道。它不会只考一个Header，而是把请求方法、协议版本、必需Header、请求体内容全都揉在一起，让你构造一个满足条件的请求。

我当时拿到的提示大致意思是：需要使用指定方法访问、必须使用HTTP/1.1版本、请求头里要带上某种认证信息、请求体需要提交指定的参数。这种题目没法靠浏览器完成，必须用Burp Repeater手搓请求包。下面是构造请求时的标准步骤：

第一步，先把请求行写对。示例：

POST /index.php HTTP/1.1 Host: xxx.xxx.xxx.xxx

第二步，根据题目要求补齐Header。最常见的要求是加Content-Type、Content-Length、Cookie或X-Forwarded-For。如果你带了请求体，Content-Type必须和请求体的格式匹配，比如表单格式用application/x-www-form-urlencoded，JSON格式用application/json。

第三步，在空行之后写请求体。格式如下：

POST /index.php HTTP/1.1 Host: xxx.xxx.xxx.xxx Content-Type: application/x-www-form-urlencoded Content-Length: 13 key=value&id=1

第四步，确认目标地址的协议。如果是HTTPS，端口选443，并在Burp Repeater的地址栏里明确写https://xxx，否则连接会失败。要留意的是：有些同学在改协议时忘了切换端口，导致一直超时，却误以为是题目环境问题。

这道题把所有前置知识都串了起来，刷完它，你对HTTP协议的认识就不再是零散的字段了，而是一整套“客户端如何精确构造请求”的流程。之后的任何Web题，你只要能在脑中还原这个请求包，就有了分析的抓手。

3.7 通关后的知识串联

六道题全部刷完后，我建议你做一个动作：自己画一张“请求包解剖图”。不要发到网上，就画在自己的笔记里。把请求行、请求头、请求体、响应状态行、响应头、响应体分别标注出来，然后在每个部位旁边写上“哪道题考过它、我怎么改的”。这一步能让零散的知识点变成你自己的武器库。

我在带新人时发现一个规律：能独立画出这张图的人，后面刷SQL注入时，至少能快速理解参数在请求体里的位置；刷文件上传时，会第一时间看Content-Type对不对；刷SSRF时，知道Host和URL解析的差异。可以说，这六道题是整棵技能树最大的一块垫脚石。

4. 实战踩坑与问题排查实录

再顺利的通关过程，也免不了踩坑。我把自己刷这套题时掉进去的坑、以及帮别人排查时遇到的典型问题，整理成下面的排查思路，遇到问题直接照着查。

4.1 抓包配置阶段最容易翻车的三个地方

第一个是代理没配好。Burp Suite默认监听127.0.0.1:8080，浏览器必须配置HTTP代理指向它，否则抓不到流量。很多人打开Burp后浏览器照常访问，却以为工具坏了。正确做法是：在Burp的Proxy Options里确认监听地址，再把浏览器的代理设置指过去。不建议直接用系统全局代理，尽量用浏览器插件只做针对性代理，省得影响其他网络请求。

第二个是HTTPS证书没装。访问https://开头的题目地址时，如果没安装Burp的CA证书，浏览器会提示证书无效，Burp里也会看到SSL handshake failed。此时需要先导出Burp的证书，安装到系统信任列表里。这一步在不同操作系统里略有差异，但关键点是：证书要同时安装到“受信任的根证书颁发机构”，而不是用户个人证书。装错位置，依然抓不到HTTPS明文。

第三个是拦截开关的误用。Burp的Intercept功能默认开启拦截所有请求，很多新手会卡在“页面永远加载不出来”的状态，因为请求被挂起了。CTFHub这套题的正确姿势是：关闭Intercept，让流量正常通过，然后在Proxy History里找需要的请求，再右键发到Repeater去改。全程开着拦截反而会拖慢进度。

4.2 请求改完发出去却不对的排查思路

改完请求发送后，如果服务器没有按照预期返回flag，先按下面几条逐一排查。

• 看请求行是否完整。方法、路径、协议版本三个部分缺一不可，路径不要写成GET / HTTP/1.1。
• 看头字段有没有漏空格。比如Cookie: admin=1冒号后面要有一个空格，虽然很多服务器容忍缺失，但严谨一点能减少干扰。
• 看Content-Length和请求体是否匹配。这是Repeater里最常见的问题：你删掉了一段body，但长度没改，服务器就会一直等待或者报错。
• 看目标端口。题目地址是HTTPS时，端口必须443；HTTP时，端口80。Burp里改了请求后，如果忘记保持原始TCP连接信息，也容易出现连接失败。
• 看是否有额外的自动修改。Burp Repeater在开启某些模块时可能自动更新Content-Length，这通常是好事，但也可能在你编辑Header时顺手改了其他字段，发送前最好把请求从头到尾过一遍。

4.3 常见问题速查表

4.4 做题之外我养成的两个小习惯

第一个习惯：每道题通关后，把最终成功的请求完整复制下来，存成一个文本文件。文件命名里带上题号、考点的Header名、以及结果flag的片段。积累一段时间后，它会变成一个非常轻量的“CTF请求样本库”。遇到类似题目时，直接改参数复用，效率高很多。

第二个习惯：在Burp Repeater里把原始请求和响应都打开“Pretty”视图，并把Hex和Raw视图切换放在手边。这样一旦出现特殊字符或不可见字符，我能第一时间发现。HTTP协议题里偶尔会出现%00、大小写混淆、URL编码等细节，肉眼在Raw视图里看容易漏掉，而Hex视图能帮你快速定位异常字节。

最后再补一句实操心得：改请求慢一点没关系，但一定要“一次只改一个点”。我见过太多人一次把方法、Header、Body全改了，出了问题不知道是哪一步导致。规范的做法是：先用原始请求确认能连通，再逐项调整，每调一步发一次，直到flag出现。这套习惯不仅适用于这六道题，也适用于之后所有Web题，甚至是真实项目里的接口调试。我自己在大量测试任务里都靠这个笨办法避开了很多“改来改去改不回去”的困境。希望这份攻略能帮你顺利把HTTP协议这条线打出全绿，打好Web方向的第一仗。