Web漏洞挖掘入门指南：漏洞分类、挖掘流程与合法靶场

1. 先把“挖洞”这件事掰开揉碎讲清楚

我一直觉得，“Web漏洞挖掘”这个词对新手特别不友好。听起来像是一件特别酷、特别黑客的事，但实际上我入行这些年，发现大多数人对它的误解极深——要么觉得这是天才才能干的事，要么以为装个扫描器点两下就能搞定。这俩方向都跑偏了。

说白了，Web漏洞挖掘就是你以一个合法授权的身份，对一个Web系统做深入的安全测试，主动去探测它是否存在可以被利用的缺陷。这个“主动”很关键，因为正常运行的系统里，漏洞是藏着的，不会自己跳出来。你的工作就是模拟攻击者的思路，但带着防守方的目标，去提前把这些坑找出来、填上。它解决的现实问题很简单粗暴：与其等着不怀好意的人发现漏洞，不如你先自己把它找出来。就好比你家装修完请人来验房，你不会等住进去了才发现漏水，而是先让专业的人过一遍，有问题趁早改。

这套技能适合谁学？适合想入门安全行业的在校生，适合已经在做开发但想提升代码安全意识的程序员，也适合半路出家想转行做安全的同学。它不需要你数学多好、学历多高，但需要你有一根筋的钻研精神，以及最重要的——清晰的合规底线。

这期作为系列的第1期，我不会上来就教你用什么花哨工具去扫，而是先把“地基”打牢：漏洞到底是什么、有哪些分类、专业的挖掘流程是怎样跑通的、以及你该在哪练手才不出问题。这些东西搞明白了，后面你学什么都快。

2. 到底什么叫“Web漏洞”？先给个能记一辈子的定义

新手最容易犯的错，就是拿着一个“高危漏洞”的标题到处喊，但你要问他这个漏洞本质是什么、攻击链是怎么走的，他支支吾吾半天说不明白。这就是定义没吃透的表现。

我一般这样给学生讲：Web漏洞，就是Web应用在需求设计阶段、代码实现环节、或者运行部署配置中，不小心留下的逻辑缺陷或安全弱点。这些缺陷平时不声不响，但一旦被特定输入触发，就能让系统做出开发者预期之外的事情——比如把别人的订单数据给你看、让你不付钱就完成交易、或者直接拿到服务器的控制权限。

注意这里我强调的是“开发者预期之外”。很多新手觉得漏洞就是代码写错了，这不全面。比如有些业务逻辑漏洞，代码完全按需求写的，但需求本身就没考虑到“用户把下单数量改成负数”这种场景，于是系统白白给你退款。这就是逻辑层面的缺陷，比单纯代码错误更隐蔽。

我们可以把漏洞的核心说白了：Web应用信任了一切不该信任的输入，或者说，它没有严格验证“你是谁”和“你给的到底是什么”。二者必居其一。

为了让你更好感知，我用一个生活类比。你把Web应用想象成一家银行柜台：窗口工作人员有自己的办事流程，客户来了填单子、递证件、办业务。如果这个柜员完全不核对身份证真伪就给取钱，或者客户递了张“取款一亿”的纸条就真给转账，这就是漏洞。攻击者干的事，就是不断试着用各种诡异的纸条和假证件，看看柜员有没有哪一步是可以被忽悠住的。

2.1 漏洞 vs 脆弱性 vs 风险：别把三个词混着用

还有一个在新手圈子里特别常见的概念混淆，就是把“漏洞”“脆弱性”“风险”当成一个东西谈。这对我后面讲分类时会有影响，所以先花几句话理清楚：

• 漏洞：系统本身存在的客观缺陷。比如你写了一个接口，没有做登录校验，这是一个实实在在的、可以被复现的缺陷。
• 脆弱性：某个环境或配置里存在的薄弱点。比如你代码没漏洞，但你把数据库密码写进了前端代码里，或者服务器把默认管理端口暴露到了公网。
• 风险：漏洞被利用后实际造成的影响程度。同一个漏洞，放在只有测试数据的系统上，和放在存着几千万用户信息的系统上，风险等级完全不一样。

用一个比喻：你的窗户锁坏了是漏洞；你家住一楼且没有防盗网是脆弱性（环境因素）；而你家存着大量现金才构成高风险。做漏洞挖掘报告的人，到最后都必须把这三层关系理清，否则光报一个漏洞名字，甲方根本没法排优先级。

3. 漏洞分类全景图：别再只会说SQL注入和XSS了

新手常犯的第二个问题，是只知道几个最有名的漏洞名，然后就试图用这几个名字去套所有问题。实际上Web漏洞的分类体系非常成熟，理解分类，不是让你背名词，而是帮你建立“看到一个功能，就能本能地联想到它可能出现哪类问题”的能力。

3.1 按成因分类：代码层、逻辑层、配置层

这是我最建议新手先掌握的维度。你拿到一个目标，先判断这个漏洞是出在哪个层面：

• 代码层漏洞：开发者在编写代码时留下的问题，比如你接收了一个用户上传的文件，但没控制后缀名，导致有人传了个包含木马的脚本文件上来。这里面最典型的就是各类注入漏洞、文件上传漏洞。
• 逻辑层漏洞：业务在设计与流程编排上出的问题。数据本身没毛病，代码本身也能跑，但流程可以被绕过。最经典的是“购物车订单金额在前端改一下就成了”这种低劣但实际存在的案例，以及越权类漏洞——你登录了自己的账号，却通过修改URL里的ID，看到了别人的订单。这一类漏洞，扫描器比较难扫出来，特别依赖手工逻辑思维。
• 配置层漏洞：系统本身或者中间件、数据库没配置好。比如目录列表功能开着，导致任何人都可以浏览服务器上的文件列表；或者默认管理员密码没改。这类问题通常风险极高，但修复也最简单。

3.2 按OWASP Top 10的维度看分类

如果你上过任何安全课程，一定听说过OWASP Top 10。它是行业内公认度很高的一份Web应用十大风险清单，每几年更新一次，上面列的是当前实际场景里最常出现的漏洞类型。这个列表值得我们做什么？不是背，而是用来对照，明白业界关注的焦点在哪。

常年在榜的几类，我简单给你过一遍，每个都记一个印象最深的特点：

访问控制失效——我愿称之为“越权全家桶”。系统明明只允许普通用户看自己的信息，但你没有校验用户有没有权限，直接凭着一个登录状态就返回了所有数据。这类漏洞在现在的业务系统里多得像米一样，几乎每个大公司都中过招。

加密失效——敏感数据没做加密，或者用了已经不安全的加密算法。比如密码用明文存数据库、用户手机号在URL里直接用明文传递，这种我觉得已经谈不上“挖漏洞”了，属于“捡漏洞”。

注入——SQL注入是其中代表。你把用户输入的内容直接拼进数据库查询语句里，等于让用户写了一段代码交给数据库执行。最极端的受害案例，一次注入能拖走整个库的数据。现在出了很多参数化查询方案来防它，但存量系统的注入坑还是源源不绝。

不安全设计——这个分类比较特别，它指的不是实现层的错误，而是架构层面就没考虑安全。比如某个业务需要一个验证码功能，但从设计上就没有这个环节。这种问题很难靠修代码解决，往往要重新设计流程。

安全配置错误——包括使用默认账号密码、云存储桶权限放得太开、报错信息暴露了内部栈信息。形容它的最好句子是“打开的窗户不止一扇，而是整面墙都是落地窗”。

跨站脚本（XSS）——往页面里注入可执行的脚本，用户一访问这个页面，脚本就替他干坏事。你存的cookie、登录凭证、甚至操作行为，都可能被无声地偷走。

不安全的反序列化——这个讲起来稍微复杂一点，你可以理解为程序把外部传进来的、不可信的序列化数据直接拿来用了，结果在反序列化的过程中被攻击者植入恶意逻辑，最终导致远程代码执行。属于看着难懂、一旦成功就伤害极高的类型。

使用含已知漏洞的组件——这个分类特别“真实”：你系统本身没写错，但你用的开源库版本已经公开爆过漏洞，而你一直没升级。攻击者根本不需要研究你，直接拿现成的利用代码来打你就可以了。

日志和监控不足——系统被攻击了，你翻日志发现什么有用的都没记下来。这个漏洞咱们做挖洞时不太会直接“利用”，但它会直接决定你有没有能力发现一次已经发生的入侵。

除了这些，还有很多没进入Top 10但特别常见的类型，比如文件上传漏洞、SSRF（服务端请求伪造）、CSRF（跨站请求伪造）、WebSocket安全问题、子域接管等。分类的花样可以很多，但你要抓住根本：漏洞的价值不在于它叫什么名字，而在于它能不能被利用、利用后又能不能拿到实际的影响（数据、权限、命令执行）。

3.3 危害等级到底怎么定

新手挖到个漏洞就兴奋半天，但对危害等级完全没有感觉。这里分享一个我常用的思路，等级不是看漏洞类型，而是看它最终能造成什么后果。

• 严重：可以直接拿到服务器权限，比如RCE（远程代码执行），或者能拖走全部数据库数据。
• 高危：能够进行大批量数据窃取、越权操作影响范围大，或者能完全接管任何一个普通用户账号。
• 中危：能窃取特定条件下的少量数据、影响个别用户会话，或者需要用户做交互才能触发，比如点个链接。
• 低危：影响有限，比如仅仅在页面弹个警告框、HTML注入，实际利用价值有限。

我见过太多人拿一个“存储型XSS”就大喊严重漏洞，其实它只能在后台页面上弹个框，管理员根本不会点击那个特定区域。这种情况说实话定个低危已经很客气了。反过来也有人把“登录接口存在用户名枚举”不当回事，但对于高价值目标来说，这往往是进一步爆破攻击的第一步，给个中危不算冤枉。

4. 标准化挖掘流程：照着这条路走，效率翻倍不乱阵脚

很多新手挖洞最大的问题是“脚踩西瓜皮”，想到哪测到哪。今天在登录框测了几把SQL注入，明天又跑到搜索框测XSS，结果一圈下来什么也没发现，还累得够呛。我建议所有新人从第一天起就遵守一套标准的迭代式挖掘流程。这套流程我自己用了很多年，也带过不少人上手，非常稳。

4.1 踩点侦察：先搞清楚你要打的是什么

这不是让你像黑客一样去“踩点”非法目标。而是在获得授权的基础上，尽可能全面地了解目标的构成。包括：

• 系统的功能模块有哪些，是电商系统、后台管理系统、还是企业官网？
• 用了什么开发语言和框架，比如PHP的ThinkPHP、Java的Spring系列、还是Node.js？
• 部署在什么类型的服务器上，Web中间件是Nginx、Apache还是IIS？
• 前端页面是用什么技术实现的？有没有用某些已知漏洞的版本？
• 域名下挂了哪些子域名或独立服务？有没有管理后台入口遗留在公网？

这一阶段的主要产出是：画出一张目标系统的功能架构图，以及一份你准备重点测试的清单。做一个系统，你就不能一上来就全测，你得先圈定范围——比如注册、登录、找回密码、个人资料、订单功能这几个核心模块，优先盯住它们。

基本功在这一步就开始打：信息收集。用得上的工具从浏览器F12开发者工具开始，到后面的各类子域名收集和指纹识别工具。它们是让你从“盲人摸象”到“心中有图”的必经之路。

4.2 接口与路径梳理：打开你的地图集

有了大范围信息，接下来你要把系统的接口和路径一条条理出来。这一步的本质是：穷举系统的攻击面。系统能接受输入的地方，都是潜在的入口；入口越多，攻击面越大。

实际操作时，我会让新手做以下几件事：

• 把前端所有JS文件里写的API接口路径全部找出来，很多开发图省事，把未鉴权的接口也直接写在JS里，这是很常见的信息泄露；
• 用抓包代理工具浏览一遍系统的核心业务流程，把每一个请求记录下来——URL、参数、请求方法、请求头、响应内容；
• 用目录扫描工具探测嘴边没有写进页面但真实存在的后台路径或隐藏接口；
• 仔细看鉴权机制，哪些接口可以无Cookie直接访问，哪些设置了跨域访问限制，哪些参数是直接透传到后端的。

梳理完这一步，你应该有一个自己的接口清单了。我习惯用一套表格模板来管理这些资产：接口路径、请求方法、是否需要登录、需要哪些参数、返回了什么敏感信息。后面所有测试都在这张表上做注释，不要边测边翻聊天记录和截图。

4.3 针对性测试：一个漏洞类型一个漏洞类型地过

这是整个流程里技术含量最高、也最耗时的一环。新手在这一步经常犯的错误是没有节奏，看到哪个参数就顺手测一把。我建议咬咬牙养成习惯：每个模块、每个接口，都按一个固定的漏洞测试清单来覆盖。比如拿到一个“搜索查询功能”，你就应该顺着下面这类思路过一遍：

• SQL注入：在搜索框输入单引号、典型的布尔条件，看系统会不会报错或者返回结果异常；
• XSS：输入一段脚本标签，看输出到页面上时是否被过滤或转义；
• 模板注入：输入模板语法表达式，看有没有在页面上被执行；
• 越权：把URL里的订单ID改成别人的，看响应是否会返回别的用户的数据；把某个请求的HTTP方法从GET改成POST，看后端会不会拒绝。

每测一个点就要记录：目标URL、测试payload、响应特征、命中与否。我管这个叫“打点纸”，纸上记录多了，你自然就能看出哪些模块问题多、哪些模块边边角角容易出问题。

4.4 验证与利用：不能只报“可能存在”，要有说服力

挖到漏洞不等于能提交漏洞报告。我刷到过太多新人反馈，说“我发现了SQL注入”，结果一问，就是输入了个单引号页面报了个500错误。这种情况只能说“疑似异常”，远不能证明是SQL注入。

一个漏洞要做实，必须完成以下验证闭环：

• 稳定性复现：同一个输入，重复两次都能导致同样结果，排除偶然性。
• 影响面确认：确认这个漏洞影响的是当前用户的数据、全站的数据、还是服务器本身。
• 深度利用：在合规范围内，把漏洞的利用链走通。比如你发现文件上传漏洞，那你需要测试的是你上传的脚本到底能不能被解析执行，而不只是“后缀名改了但服务器没有解析它”。

我最看重的是“利用链”三个字。很多新手测到“能上传文件”就收工了，但真正有价值的，是“能上传一个能被浏览器访问并解析为脚本的文件，从而在服务器上反弹会话”。当然，这一期的目标是让你先跑通流程，深层利用后面再逐步展开，但方向上你要知道：验证的终点不是“报错”，而是“影响”。

4.5 报告编写：会挖不算本事，写清楚才算

进了这个圈子你就知道，真正决定你价值上限的，其实是报告能力。你再会挖，说不清楚，甲方还是看不懂、修复不了。

一份合格的漏洞报告，核心要素就这些：

• 漏洞标题——要精准，比如“直接URL访问导致未授权访问”而不是模糊的“逻辑问题”；
• 漏洞地址与参数位置——要让开发按图索骥，一秒定位；
• 漏洞类型与危害描述——尽量按专业参考来源来定义，别自己造类型名；
• 复现步骤——清晰到“任何人照着点鼠标都能看到同样问题”的程度；
• 漏洞截图或录屏，必须要有，这是底气；
• 修复建议，给出可执行的方向，比如“对所有API接口增加鉴权校验与权限控制”。

一份好报告，是你能在安全圈立住口碑的硬通货。它甚至比漏洞本身更值钱，因为漏洞会修，报告却会一版版沉淀你自己的方法论。

4.6 回归测试：确认修复没有无效努力

提交报告之后，甲方开发修完漏洞，你作为测试方还要做一件收尾工作——复测。复测不是简单地拿原payload打一次看看还灵不灵，而是要验证修复是否彻底。举个例子，一个SQL注入漏洞，开发修法如果是“过滤了单引号”，那你这次回归测试就要重点确认：是不是确实过滤了单引号？是不是连大小写绕过、Unicode绕过也堵上了？是不是其他参数位也同步做了同样处理？

我见过太多“修了但没修全”的情况，过滤了一个点，换个编码方式还是能打进去。所以回归测试要当成一次小规模的新测试来做，这也是专业挖洞者和业余爱好者的分水岭。

5. 合法靶场清单：新手唯一应该“动手”的地方

说了这么多，肯定有同学已经开始手痒了：“我想开始练手，但上哪找一个合法系统来测？”这是每个新人都会面临的问题，而且这个问题处理不好，轻则学歪了，重则害了自己。我必须非常明确地告诉你：永远不要拿自己没有授权的公网系统练手，不管它是“看起来像测试系统”还是“API完全裸奔”。

真正能练手且完全合法的地方，是专门的“靶场”（Vulnerable Lab）——也就是这些系统本身就是被设计成有漏洞、故意给人做安全测试的。它们的存在目的就是当你的陪练，你可以放心大胆地打，打坏了还能重置。

下面这份清单是我这些年实战验证过、各方面比较靠谱的靶场，按适用阶段给你排一下。

5.1 入门首推：DVWA（Damm Vulnerable Web Application）

如果你只认一个靶场，我强烈建议是DVWA。它是一个PHP写的Web应用，里面装了SQL注入、XSS、文件上传、CSRF、命令注入这些经典漏洞模块，每个模块还分了低、中、高三个难度等级。低难度基本上就是“漏洞大门敞开”状态，专门给新手找感觉用的；高难度则模拟了有防护的真实场景。

适合它的场景：你第一天接触Web安全，想明白“注入到底长得什么样”“XSS弹窗是个什么体验”，花一个小时，DVWA能让你把所有经典漏洞都亲手体验一遍。安装也很有学习价值，你可以在本地用集成环境搭起来，或者用Docker一条命令跑起来。

5.2 贴近实战的进阶靶场：Pikachu

Pikachu靶场是一款国人开发的教学靶场，界面比较友好，而且它的漏洞模块设计更贴近国内开发环境的习惯，比如SQL注入里带了宽字节注入这种经典情况，XSS里区分了DOM型、反射型、存储型。对想理解国内常见漏洞和绕过套路的人来说，它是极好的过渡站点。

我在带新人时，一般是在DVWA过完基础后，立刻让他们去Pikachu里重新打一遍。因为DVWA的题目直来直去，而Pikachu更强调“你在实战中遇到的是变种”。它的题目做完，你才算是真正迈过了“知道漏洞叫什么”到“能找到漏洞在哪”的坎。

5.3 入门到进阶的中间层：WebGoat

WebGoat是OWASP社区维护的一套攻防教学靶场，基于Java写的。和DVWA、Pikachu不太一样，WebGoat把每个漏洞做成了教学关卡，每一关都有目标说明和操作提示，像在打游戏闯关一样。它的题目覆盖面非常广，除了常规Web漏洞，还包含了HTTP基础、编码绕过、访问控制等大量基础训练。

我特别推荐它的一点是：WebGoat里面有不少题目需要你思考“逻辑漏洞”，而不是单纯靠工具扫描，能有效帮你训练手工测试思维。它的配套项目还有一套故意设计为有漏洞的真实Java应用，想练习代码审计的同学也可以连起来学。

5.4 前后端分离与API测试靶场：靶场A或者一些开源API靶场

现在的Web系统越来越多用前后端分离架构，前端一个服务、后端一个接口服务。传统靶场大多是整站渲染，对API漏洞覆盖不足。这一块建议找一些开源的API靶场项目来练，它们专门模拟了JWT（令牌机制）校验缺陷、越权API、信息泄露、参数校验缺失等现代Web特有的漏洞。

这个环节最容易培养你的“接口安全直觉”。因为现代业务系统里，真正值钱的漏洞大都在API层，而不是页面层。你说XSS很牛，但今天一台API服务根本没页面给你XSS，你怎么办？练API靶场就是解决这个问题的。

5.5 综合练手平台：开源的漏洞演练平台

还有一类是内容更加庞大、更接近真实业务系统的大型开源演练平台，这类系统模拟了一个完整业务线——用户系统、商城、社区互动、后台CMS等，漏洞埋得又深又隐晦，需要你综合运用信息收集、逻辑推理、漏洞利用各种能力才能真正拿下来。它比较适合对Web漏洞已经有一个完整认知、想模拟“挖一个真实目标”全过程的人。

我给大家的建议路径是：先用DVWA学会走路，再用Pikachu学会跑，去WebGoat和各类API靶场里学各种变种与技巧，最后到大型演练平台上把整条挖掘流程完整实操一遍，连报告都写好。走完这条路，你再去看公开漏洞报告、参加授权范围内的众测项目，就会从容很多。

下面是我整理的一份简洁对照表，方便你有需要时快速查阅：

注意：所有上述靶场，我建议一律在本地虚拟机或者Docker容器环境中搭建，不要图省事直接部署到一台公网服务器上。安全研究和“把自己变靶子”只有一线之隔，这是不可逾越的底线要求。

5.6 搭建靶场时的一个关键习惯

顺带说一句既实用又保险的实操经验：给靶场单独配一台虚拟机或容器环境，不要跟自己的日常开发环境混在一起。很多时候靶场里跑着各种未修复的漏洞，你为了测试方便可能还会关闭服务器防火墙，这些操作在自己的隔离环境里没问题，但要是混在平时办公或学习的机器上，一个不小心就能把“练功房”变成“灾难现场”。虚拟机里的靶场环境快照是个好东西，测坏了随时回退，这是省钱省时间的好工具。

6. 新手入坑最容易踩的6个坑与独家心得

最后这部分，不走教科书路线，全是我自己踩过、也看我带的新人反复踩过的坑。每条都值得抄进你的笔记本。

第一，只学工具不懂原理。我见最频繁的情况是：拿着扫描器对着靶场扫出几十条“漏洞记录”，然后兴高采烈告诉我“挖到了”。我说你手动复现一下，他一脸茫然。扫描器顶多算一个自动化的“探测器”，真正的漏洞挖掘核心，永远是你对Web工作原理的理解。工具扫出来的结果，不验证就报告，不仅不专业，还可能把误报甚至无害配置当严重漏洞提交，这很丢面子。

第二，不重视HTTP请求的基本功。Web漏洞挖掘的一切信息交互，说到底都在HTTP协议上跑。你要分清GET和POST区别，知道Cookie和Session怎么工作，能看懂请求头/响应头里每个字段的含义，能阅读原始HTTP报文。不掌握这些，你用Burp Suite这类工具也只是点按键看结果，根本理解不了为什么某个注入会成功、为什么某个Cookie篡改会生效。

第三，越权漏洞往往被新手忽略。很多新人练了很久XSS、SQL注入，一遇到越权就懵了。但我要很认真地告诉你：越权漏洞在真实业务的出现频率超出你想象——水平越权是“改个ID就能看别人订单”，垂直越权是“普通用户调一下接口就能执行管理员操作”。建议在靶场练习时，刻意花大量时间练越权。因为它是逻辑漏洞的代表，也是扫描器最不擅长、全靠人脑判断的类型。

第四，提交漏洞报告必须带完整复现步骤。我收到过不少新人的报告，写着“系统存在文件上传漏洞，可能可导致服务器被入侵”，然后就没有了。这种报告让研发怎么改？他得自己猜。我的习惯是：哪怕是最简单的信息泄露，也一定写清楚访问路径、请求方式、返回了什么敏感字段，最好把截图按步骤来贴好。能把一次复现过程写到别人不看截图也能精确复现，你的报告就及格了。

第五，注意漏洞利用的边界。这个问题特别关键。哪怕是在合法靶场里，也请你只做漏洞验证和利用链证明，不要做过度的攻击性行为，比如把靶场机器直接打成宕机、植入持续性后门、拖走整个测试库数据上传到网上。很多人觉得靶场反正就是拿来打的，随意一些没问题。但这个习惯一旦带到真实授权测试或者实战环境里，就是事故。作为安全从业者，控制操作边界甚至是比挖掘技术更优先的职业素养。

第六，忽视人工分析。如今AI工具和自动化脚本越来越强，但我一直提醒新人：人工分析一个人永远不应该被替代。你判断一个漏洞能不能利用，最终靠的是对上下文的理解、对业务逻辑的洞察力，而不是跑个脚本就算完。自动化用来提效，人工用来决定。把二者结合好，你的挖掘效率和准确度才会真正上来。

最后再说点个人的实在话

写到这里，第1期的内容算是完整了。往回看，你其实已经掌握了这个领域的骨架：你知道了漏洞到底是什么而不是看个热闹，了解了主流的分类和危害评估逻辑，也拿到了一套从踩点到复测的标准化流程，并且有了明确的合法练习去处。这些内容看起来不像工具教程那样能“立刻见效”，但恰恰是它们决定了你未来能走多远。

我个人见过太多学安全的人，头一个月冲劲十足，装了二三十个工具，扫了七八个靶场，然后因为什么都看不懂、打不透，慢慢就退出了。他们缺的不是资源，是节奏。挖洞是一个“慢就是快”的技能。你踏实把一个注入原理彻底弄明白，比扫出一百个扫描器报告有价值得多。

练手的时候，用完一个靶场，不要急着换新的。盯着同一个漏洞类型的不同场景反复打，直到你闭着眼睛都能说出它的特征和绕法，再换下一个。这样过完五个类型，你的实战感觉基本就有了。

下一期我会直接从最经典的漏洞类型入手，带你把它的原理、绕过技巧与防护修复一整套过一遍，结合靶场给你做一次手把手的完整实操演示。到时候你照着做一遍，会发现自己已经开始有一点“手感”了。安全这条路，入门不难，难的是持续和踏实。慢慢来，不着急。