漏洞挖掘教程

一个晴朗的漏洞下午，我对着一个开源的挖掘CMS系统发呆。同事说这系统已经过三轮渗透测试了，教程不可能还有漏洞。漏洞我随手往用户名字段里塞了个' OR 1=1 --，挖掘页面直接把我登成了管理员。教程过了三秒我才反应过来，漏洞这不是挖掘运气，是教程思路的问题——所有人都盯着上传点和SQL注入，没人注意登录逻辑里那个不起眼的漏洞OR。

漏洞挖掘不是挖掘拿着工具扫一圈就完事。真正的教程入口往往藏在业务逻辑的夹缝里。比如某电商平台，漏洞密码重置流程要求验证手机验证码，挖掘但如果你在发送验证码的教程请求里同时修改手机号和用户ID，系统会先把新手机号绑定到目标账号，然后验证码发到你自己手机上。这招叫“逻辑覆盖”，工具扫不出来，得靠人脑去推演状态变化。

我习惯把挖掘过程拆成三步。第一步叫“画地图”，把目标系统的所有功能点列出来，包括那些隐藏的调试接口和旧版本遗留页面。用爬虫抓链接只是基本功，更有效的是去读前端JS文件，很多开发者会把API地址和参数注释在代码里。第二步是“找异常”，对每个功能点做输入变形——长度超限、类型混淆、重复提交、空值注入。别小看这些土办法，去年某知名社交平台被爆出的任意密码重置漏洞，起因就是开发者忘了对“生日”字段做格式校验，导致攻击者能直接篡改密码找回问题的答案。

第三步最考验耐心：交叉验证。把两个看似无关的功能组合起来。有个经典案例，某网盘的分享功能允许用户设置提取码，但提取码校验接口和文件下载接口是分离的。攻击者先请求下载接口拿到文件ID，再绕过提取码校验直接拼接下载链接——两个接口各自都没问题，凑在一起就是致命伤。这种漏洞需要你脑子里同时装着多个功能模块的状态，像下棋一样想三步之后的事。

工具能帮你省时间，但别迷信工具。Burp Suite的扫描器会报一堆SQL注入和XSS，其中八成是误报。真正的好漏洞往往藏在那些扫描器不碰的地方——比如JSON请求里多出来的一个role参数，或者某个接口返回的响应头里泄露了内部IP。我有个习惯，每次测站都先关掉自动扫描，手动把每个请求点开看一遍响应时间。响应时间差超过200毫秒的接口，多半有数据库查询，值得多试几种闭合方式。

还有一类常见盲区是“越权”。水平越权就是改个ID看别人订单，垂直越权就是普通用户调管理员接口。测越权有个取巧的办法：注册两个账号A和B，用A的会话去操作B的资源。如果系统返回了B的数据，说明权限校验只做了登录验证，没做资源归属验证。前阵子我测某医疗系统，发现修改病历接口只校验了token是否有效，压根没校验token对应的用户有没有权限操作这个病历ID——一个普通患者账号就能改任何人的诊断记录。

说到这得提一嘴，漏洞挖掘最大的敌人不是技术难度，是思维定式。每次拿到目标，先问自己：如果我是开发者，会在哪里偷懒？大概率是那些“没人会这么干”的地方——比如分页参数里的page_size能不能赋负数？文件上传只校验了Content-Type没校验文件头？密码修改接口没验证旧密码？这些地方才是漏洞的温床。工具是死的，思路是活的，把每个请求都当成一次与开发者的心理博弈，比跑一百遍扫描器有用得多。

(责任编辑：百科)