漏洞挖掘不是漏洞天才的灵光一闪，它更像一场有预谋的挖掘考古。你明知道地下埋着东西，基本但得一层层剥开泥土，过程用刷子小心扫开碎屑，漏洞直到碰触到那根脆弱的挖掘骨头。整个过程枯燥、基本重复，过程甚至有点神经质，漏洞但一旦那根骨头断裂的挖掘瞬间——系统崩溃，权限弹出——那种快感足以抵消所有无聊。基本

第一步永远是过程信息收集，但这步没你想的漏洞那么浪漫。不是挖掘拿着放大镜看代码，而是基本像快递员一样把目标的所有包裹都翻一遍：域名、子域名、开放的端口、后台的指纹、甚至GitHub上泄露的代码片段。有一次我盯着一个目标的子域名列表看了三小时，发现一个叫“test-oa”的二级域名，点进去是未授权访问的旧版办公系统。漏洞还没挖，入口已经自己敞开了。所以别急着上手，先像个变态一样把目标的底裤翻干净。

接下来是“找面”阶段。你不可能把每个功能点都试一遍，那是笨办法。聪明的做法是画一张攻击面地图：哪些接口接收用户输入？哪些参数直接拼进SQL查询？哪些上传点没校验文件类型？这活儿靠经验，也靠直觉。比如看到URL里有“id=123”，你脑子就该自动弹出“试试改成456，再试试加个单引号”。我见过新手对着登录框死磕验证码，却忽略了旁边“忘记密码”的接口能直接重置管理员账号——面没找对，再努力也白搭。

真正开始“打点”时，手法就野了。SQL注入、XSS、文件包含、反序列化……每个漏洞类型都像一门手艺，但核心逻辑就一句话：让程序执行它没打算执行的动作。拿最常见的SQL注入举例，你往参数里塞个单引号，看它报不报错，报错就说明数据库在跟你对话。但别高兴太早，现在大部分系统都有WAF（Web应用防火墙），你刚发个payload就被拦了。这时候就得绕，大小写混淆、编码转换、注释符切割——像跟保安玩捉迷藏，既考验技术，也考验耐心。

漏洞挖到一半，最怕的是“假阳性”。你费半天劲构造了复杂请求，结果系统返回200，但内容没变——没漏洞。那种感觉就像挖到一块化石，结果发现是塑料模型。所以验证环节必须严谨，不光看响应状态码，还要看响应体里有没有反射内容、数据库报错信息、或者延时响应。我吃过亏：曾经测一个文件下载功能，把路径参数改成“../../etc/passwd”，页面返回了文件内容，我兴奋得差点跳起来，结果仔细一看，那只是系统自带的一个示例文件。白高兴一场。

挖到真漏洞后，还得想清楚怎么“利用”。这一步考验的是组合思维。单个低危漏洞往往毫无价值，但把几个连起来就能造成致命打击。比如先通过一个目录遍历漏洞读到配置文件里的数据库密码，再用弱口令进入后台，最后通过后台的上传功能拿webshell——每一步都平淡无奇，串联起来就是完整攻击链。我认识一个老白帽，他最喜欢找那些“没什么用”的信息泄露漏洞，然后从泄露的日志里翻出管理员登录token，直接进后台。他说这叫“用垃圾堆里的钥匙开保险柜”。

最后才是写报告。别小看这一步，漏洞挖得再好，报告写得像天书也没人理你。要讲清楚三个问题：漏洞在哪、怎么触发、危害多大。最好附上复现步骤的截图，别光贴代码。有一次我报了个存储型XSS，只写了payload没写触发场景，结果开发团队回复“无法复现”就把工单关了。后来我补了一段视频——在评论区提交脚本后，管理员一打开后台就弹窗——他们当天就修了。你看，不是漏洞不存在，是你没把故事讲明白。

整个过程走下来，你会发现漏洞挖掘本质上是种对抗性阅读。你读代码、读请求、读响应，读的是程序员的疏忽、框架的缺陷、配置的失误。它不浪漫，也不神秘，就是一遍遍试探边界，然后期待某个时刻，系统对你说了句本不该说的实话。