第十天，我没急着去学那些听起来很帅的东西，而是老老实实把HTTP协议的知识重新过了一遍，再把Burp Suite从安装到真正拦下第一个包，完整走通了一遍。这大概是自学渗透测试以来最踏实的一天——因为从这天开始，手头的工具不再是摆设，协议也不再是考完就忘的课本知识。如果你也走在自学的路上，会发现绝大多数Web渗透的动作，最后都落到"看懂一个HTTP请求、改好一个HTTP请求、重放一个HTTP请求"这三件事上。这篇文章就把我第十天的学习过程、踩坑记录和实操思路完整写下来，给同样卡在这个阶段的人一个参考。
1. 为什么第十天还在啃HTTP？——学习路线踩坑复盘
1.1 我自学的路线图：第十天的位置
自学渗透测试最容易犯的毛病，就是头一个星期把Kali Linux装好、打开几个工具，然后就开始到处乱扫。我也没能免俗，前三天基本在折腾虚拟机、装系统、熟悉Linux命令。第四到第六天过了一遍网络基础，从OSI七层模型讲到TCP三次握手、IP地址、DNS解析，当时觉得自己"懂网络"了。第七天到第九天开始碰HTML、JavaScript，顺便搞明白了网站大概是怎么跑起来的。
到了第十天我停下来想了很久：前九天的东西好像都听过，但真要我说一个HTTP请求里每行都写了什么，说不清楚；Burp Suite这个工具装了，也只是打开看过几个按钮。这种状态去学SQL注入、XSS纯属自欺欺人——连请求参数长什么样都不知道，payload往哪放呢？所以我决定，第十天不学新东西，就把HTTP讲透、把Burp用熟。
这条路走下来我觉得是正确的。如果你也想自学，建议把"协议基础"放在"漏洞原理"前面，不是因为有考试，而是因为后面每一个漏洞案例都在跟协议的细节打交道。地基不打牢，后面每学一个漏洞就要回头补一次协议，更痛苦。
1.2 没有HTTP基础，学漏洞原理就像看天书
我用一个特别朴素的例子来说明这件事。SQL注入听起来很高级，但本质是什么？是攻击者修改了请求里的一个参数，导致后端拼接SQL语句时多执行了一段代码。问题来了：参数在HTTP请求里是放在URL查询字符串里，还是放在POST请求体里？格式是key=value还是JSON？如果连这些都不清楚，拿到一个抓包结果根本无从下手。
XSS也是一样的道理。反射型XSS本质是"你提交的输入被原样拼进了响应体"——那响应体是什么？就是HTTP响应里的body部分。你得先能看懂响应里哪一段是HTML、哪一段是JavaScript，才能判断XSS的注入点在哪、能不能弹窗。Cookie为什么可能导致会话劫持？因为没有弄明白Cookie和Session的关系，不知道Set-Cookie这个响应头是干嘛用的。
我强烈建议每个自学者都要有"逐行看报文"的能力。HTTP请求报文从请求行到请求头到空行到请求体，每一行都有自己的作用，也几乎每一行都有对应的攻击手法。这不是为了考试，这是渗透测试的基本功。
2. HTTP进阶：从"能上网"到"能看懂每一字节"
2.1 请求与响应的骨架：每一行都不是废话
先贴一个最典型的HTTP请求报文，我在本地靶场抓到的登录请求就是长这样的：
POST /login.php HTTP/1.1 Host: 127.0.0.1 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Encoding: gzip, deflate Content-Type: application/x-www-form-urlencoded Content-Length: 29 Cookie: PHPSESSID=abc123def456 username=admin&password=123456第一行叫请求行，由三部分组成：请求方法、请求URL、HTTP版本。这是整个请求里最值得看的行。URL里藏着路径和参数，方法决定了这个请求的语义——GET表示想取数据，POST表示想提交数据，后面我会细讲方法之间的区别。
从第二行到空行之前全是请求头。Host表示目标站点，在很多场景下是判断虚拟主机路由的关键；User-Agent标识客户端类型，有的网站会针对特定UA做不同响应，这就成了改包测试的一个点；Content-Type声明了请求体的格式，如果服务端解析逻辑不严谨，改个Content-Type可能引入解析差异。
请求头之后必须有一个空行，这是协议的固定分隔符，空行下面是请求体，放这次提交的数据。username=admin&password=123456是典型的urlencoded格式，跟GET的查询字符串长一样。如果是JSON格式，请求体就会长这样：{"username":"admin","password":"123456"}，这时候Content-Type就得是application/json。
响应的结构和请求对应，起始行变成了状态行，比如HTTP/1.1 200 OK，后面是响应头和响应体。响应体就是服务器真正返回给浏览器的内容，可能是HTML页面、JSON数据、也可能是错误信息。判断一个请求成没成功，第一眼看状态码，第二眼看响应体的大小和内容，这在后面学SQL注入盲注的时候特别重要。
2.2 方法、状态码、Cookie与会话机制：渗透思路的温床
HTTP常见方法我在第十天认真整理了一遍：
| 方法 | 语义 | 渗透测试里的关注点 |
|---|---|---|
| GET | 获取资源 | 参数拼在URL里，容易出现在日志、历史记录中 |
| POST | 提交数据 | 参数在请求体，适合传大量数据，也是注入高发区 |
| PUT | 上传文件 | 如果服务器允许，可能直接写shell |
| DELETE | 删除资源 | 测试越权时关注 |
| OPTIONS | 查询支持的方法 | 用来探测服务器允许哪些方法 |
| HEAD | 只取响应头 | 判断资源是否存在，节省开销 |
很多新手会把GET和POST理解成"一个用来查、一个用来传"，这个理解没错，但在渗透测试里更重要的是"参数位置不同带来检测难度不同"。比如一个登录接口，GET方式把账号密码写在URL里，你在Burp的历史记录里一眼就能看清；POST方式的参数看不见URL里，但在请求体里看得清清楚楚。如果后端为了兼容同时接收两种方式，就可能出现"逻辑漏洞"——开发以为只有一个入口，实际上攻击者换一种方式就绕过了某个校验。
状态码也是信任度极高的信号。我整理了一个自己的速查表：
| 状态码 | 含义 | 常见场景 |
|---|---|---|
| 200 | OK | 正常返回 |
| 301/302 | 重定向 | 登录后跳转、URL规范化 |
| 401 | 未认证 | 需要身份凭证 |
| 403 | 禁止访问 | 权限不足，但有响应体可看 |
| 404 | 不存在 | 路径探测时有价值 |
| 500 | 服务器内部错误 | 可能是注入触发了SQL报错 |
| 502/503 | 网关错误/服务不可用 | 服务配置问题 |
在实战里，403往往是很有价值的响应——说明资源存在但不允许访问，这时候围绕绕过思路做文章（比如换方法、换Host、加X-Forwarded-For头），有时候真能突破。
Cookie和Session是绕不开的话题。HTTP本身是无状态的，服务器记不住你是谁。为了解决这个问题，服务器在响应里返回Set-Cookie字段，浏览器存下来，后续每次请求带上Cookie，服务器通过这个凭证认人。PHPSESSID就是PHP默认的会话标识。理解了这个机制，才能理解"会话固定攻击"——如果服务器在用户未登录时就分配了Session ID，攻击者可以先用自己的Session ID诱导受害者登录，登录后服务器没有重新分配，攻击者就能用同一个Session ID冒用受害者的身份。这不是今天要实操的内容，但它解释了为什么改Cookie、看Set-Cookie值得成为渗透测试的习惯动作。
2.3 HTTPS、连接复用与协议细节：进阶者必须补的课
HTTP和HTTPS的区别说着简单——一个加密一个不加密，但底层是TLS握手协议在工作。客户端和服务端要通过证书交换、密钥协商建立加密通道，之后传输的内容才不会被明文抓包读取。这也是为什么用Burp Suite抓HTTPS流量之前要先装CA证书：Burp相当于在浏览器和目标服务器之间做了一次"中间人"，浏览器要信任Burp签发的证书，才会愿意把加密流量解密后发给Burp看。
再说连接复用。以前一个HTTP请求完成后TCP连接立刻断开，每个资源都要重新握手，非常慢。后来有了Keep-Alive持久连接，一个TCP连接上可以跑多个HTTP请求。到了HTTP/2，进一步用多路复用让多个请求并行传输，减少了队头阻塞。这些概念在渗透测试里直接影响一个判断：同一个TCP连接上，服务端对多个请求的处理上下文是不是独立的？某些场景下，连接复用的边界问题会导致"请求走私"——这是后话，但今天先把"一条连接能跑多个请求"这件事焊死在脑子里。
另外一个容易被忽略的细节是CRLF注入。CR和LF分别是\r和\n，协议用它们来分隔请求头和响应头。如果服务端在构造响应头时拼接了用户输入，又没有过滤回车换行，攻击者就能通过参数注入%0d%0a来伪造额外的响应头，甚至拆分成两个响应，这叫响应头拆分。理解这个攻击的前提，恰恰就是理解协议的每一行是怎么分隔出来的——所以我一直觉得，学HTTP不是为了背格式，是为了在每个分隔符和字段之间看到"可能被动手脚的地方"。
3. Burp Suite上手：从安装配置到拦下第一个包
3.1 版本与安装：Kali预装版和社区版够用
Kali Linux里默认预装了社区版的Burp Suite，打开终端输入burpsuite就能启动。如果是用Windows或者单独装，去官网下载Community Edition就行，社区版免费，日常学习和做靶场题完全够用，只是缺少一些自动化扫描功能——自己手动用Repeater和Intruder也照样能干活。
启动前确保系统有Java环境，社区版要求Java 17以上，Kali里一般自带。如果启动时报Java版本错误，装一个对应版本的OpenJDK就行，命令很简单：
sudo apt install openjdk-17-jre -y这个坑我前几次启动时真遇到过，网上资料对版本说得含糊，浪费了半小时。现在直接给你结论：社区版用Java 17稳妥，Pro版也别乱用新版本号，按官方文档来。
3.2 浏览器代理与HTTPS证书：让Burp能看见所有流量
Burp的核心机制是"代理"。启动后默认在本机127.0.0.1:8080起一个监听端口，浏览器所有流量如果走这个端口，Burp就能看到、能拦截、能修改。配置方法是在Firefox的设置里找到"网络设置"，选择"手动配置代理"，HTTP代理填127.0.0.1，端口填8080，勾选"也使用此代理用于HTTPS"。
这里有个顺序容易踩坑：如果先打开代理设置再启动Burp，浏览器访问网页会直接报错，因为代理没监听。正确顺序是：先启动Burp，再配置浏览器代理，然后访问http://burp能看到一个欢迎页，说明代理通了。
抓HTTPS流量之前必须安装CA证书。用浏览器访问http://burp，页面右上角会有一个"CA Certificate"按钮，下载证书文件，然后在Firefox设置里导入为"证书机构"，勾选信任项。装完证书后，Burp才能解密并展示HTTPS请求的内容。这一步要是漏了，你在Target和Proxy里看到的HTTPS流量全是乱码或者根本看不到。
3.3 界面与模块：先记住这几个就够
Burp的界面第一次打开会觉得模块多得吓人，但其实真正的基础操作就集中在几个模块里：
| 模块 | 作用 | 使用频率 |
|---|---|---|
| Proxy | 拦截和查看所有代理流量 | 最高 |
| Repeater | 手动修改请求并重放 | 极高 |
| Intruder | 自动化批量测试参数 | 高 |
| Decoder | 编码解码工具 | 中 |
| Target | 站点地图和历史记录汇总 | 中 |
刚上手我建议只关注Proxy里的Intercept和HTTP history。Intercept页签有"Intercept is on"的开关，打开时浏览器发送的每个请求都会停在Burp这里，你可以点击Forward放行、点击Drop丢弃，也可以直接在窗口里改请求内容再发送。这个"暂停并修改"的能力就是后面所有手工测试的基础。Action按钮可以把当前请求直接发送到Repeater或Intruder，不要小看这个快捷入口，实战里90%的动作都是从这里开始的。
HTTP history是另一个宝藏页签，浏览器访问过的所有请求都在这里。重要的是学会用过滤条件——按URL、按MIME类型、按状态码过滤，快速找到自己关心的那个请求。初学者经常在几百条历史记录里翻半天，我自己的习惯是先按域名过滤，再按状态码（先找POST和302），这样定位速度快很多。
4. 实战演练：用Burp分析并改造一个靶场登录请求
4.1 实验环境与实验目标
纸上谈兵没用，第十天的重头戏是我在本地搭了一个最基础的PHP登录页当靶场。这里强调一声，做任何测试请一定在本地环境或者自己拥有授权的靶场进行，不要拿公网真实站点练手，这是行业底线。
实验目标很简单：通过Burp把浏览器访问登录页、提交账号密码的整个过程完整截下来，然后在Repeater里手工修改请求体、修改请求头，观察响应差异。这个实验做完，你对"请求是从哪来的、每一段改了什么会有什么后果"会有特别直观的感受。
4.2 完整抓包过程：从浏览器操作到Burp拦截
打开Burp的Proxy，确认Intercept是开着的。然后在浏览器里访问本地登录页面，输入一个随意编的账号和密码，点击登录。这个时候浏览器不会马上跳到页面，因为请求被Burp"扣住"了。回到Burp的Intercept页签，会看到一个完整的POST请求，就是我前面贴过的那种格式。
我第一次做这个实验的时候愣了几秒——原来点击一个登录按钮，浏览器和服务器之间真的就是发了一行一行的纯文本。这种"把抽象变具体"的感觉，是Burp给自学者最大的礼物。
点击Forward放行，浏览器才继续收到响应、展示页面。这时候去HTTP history里找到刚才那条POST记录，右键选择"Send to Repeater"（快捷键Ctrl+R），进入Repeater模块。你会发现请求被原样保存了下来，右边是Send按钮，下面能看到这次请求的响应内容——状态行、响应头、HTML响应体全都有。
这个流程看起来平淡，但它把"浏览器点击"和"HTTP报文"这两件事牢牢绑定在了一起。以后无论是学SQL注入还是越权测试，你都会下意识地想一个问题：我点这个按钮，实际发出去的请求报文长什么样？
4.3 Repeater改包重放：两个看得见效果的实验
第一个实验，修改请求里的密码参数。把请求体里的password=123456改成password=admin，点Send，观察响应。如果后端只是简单比对账号密码，你会看到登录失败的提示；但如果故意把靶场代码弱校验写成"只要用户名是admin就算成功"，你就能观察到响应结果的差别。这个实验想传达的是：改了请求体，服务器的行为真的会变——这不是游戏，是实实在在的逻辑。
第二个实验，加一个X-Forwarded-For请求头，值填1.2.3.4，再看看响应。有的后端代码会读取这个头做IP判断或日志记录，有的不会。我第二次尝试时加了这样一个头，靶场PHP代码里有一行读取IP的逻辑，响应里确实多显示了一个IP来源。这个实验告诉我：请求头里的信息如果没有被服务端校验，就可能被人为伪造，这是很多"IP绕过"攻击的根本原因。你现在接触这些头，是在为后面的越权、WAF绕过甚至是业务逻辑漏洞打基础。
Repeater还有一个陈年好用的快捷键：Ctrl+U可以把选中的URL编码还原，Ctrl+Shift+U是反向编码。在改包过程中经常遇到转义问题，这两个快捷键能帮你省很多事。
5. 这十天踩过的坑，和第十一天要做的事
5.1 这几个坑我替你踩过了
第一个坑：设置了浏览器代理但是忘了启动Burp，然后疯狂怀疑自己是不是配错了。后来我把流程固定成"先Burp后浏览器"，再也没出过错。
第二个坑：抓不到HTTPS流量。折腾了半天发现是CA证书没装。装完证书后Firefox还会提示"您的连接并不安全"，需要去证书设置里把Burp CA证书导入了"证书机构"列，并勾选"信任由此证书机构签名的网站"。这一步不能省。
第三个坑：HTTP history记录太多，找不到目标请求。我的解决方法是进Target页签，在站点地图里按域名点进去，只看这个域名下的请求；或者在History里加过滤条件，把静态资源类型（图片、CSS、JS）排除掉，页面瞬间清爽。
第四个坑：看到乱码。原因是响应体是gzip压缩的，有些时候Burp没自动解压。在Repeater里可以把请求头里的Accept-Encoding: gzip, deflate删掉，服务器返回的就是明文格式，分析起来舒服很多。实际上我在做靶场题的时候经常这么干，非常实用。
第五个坑：Intruder一上来就跑字典，结果一个请求都没跑通。原因是Intruder默认会标记每个参数为payload位置，但你一定要先在"Positions"页签里把不需要爆破的参数上的标记清掉，只保留要测试的位置。不然每个参数都会被塞入大量字典值，又慢又乱。
5.2 下一步：从HTTP到Web漏洞的衔接
第十一天开始，我给自己安排的路线是正式进入OWASP Top 10，第一个是SQL注入。为什么敢学了？就是因为现在我能抓包、能改包、能重放，而且对请求里的每个参数就像看自己写的字一样熟悉。拿到一个靶场，我能清楚地知道哪个参数是注入点候选、请求发出去后响应的哪一段是判断"是否注入成功"的依据。
练习靶场方面，我目前用的是DVWA和Pikachu这两个经典选择，都支持本地部署。DVWA的SQL Injection模块足够入门，Pikachu的中文界面方便理解漏洞场景。以后如果打CTF题，像CTF题里常见的HTTP头注入、方法注入，也终究会回到今天学的这些基础上面——Burp里改个头、换个方法，有时候题目就通了一半。
如果你也自学到这里，我的建议很朴素：不要贪快，不要觉得"第十天还在弄HTTP"很丢人。真正常见的自学拦路虎不是知识点难，而是基础不牢导致后面的漏洞原理全靠背。今天把HTTP和Burp这一对组合练到"闭着眼能改包"的程度，后面学的每一个漏洞，你都比别人更容易上手。我这十天的最大感悟是：真本事都是从一个又一个具体的报文和请求里磨出来的。
