去年秋天，统网我帮一家做在线教育的络安小公司看他们的后台。登录框摆在那儿，全漏用户名密码一填，洞挖点提交，掘过抓包一看——返回的统网JSON里居然把用户角色、内部ID全带出来了。络安更离谱的全漏是，把返回的洞挖role字段从"student"改成"admin"，再刷新页面，掘过管理菜单直接出来了。统网这就是络安典型的水平越权加前端信任漏洞，前后端都没做校验。全漏整个过程没用到任何高级工具，洞挖浏览器F12加Burp抓包，掘过十分钟搞定。

漏洞挖掘不是从扫描器开始的。很多人上来就AWVS、Xray一顿扫，报告出来几百条，真正能利用的没几个。我的习惯是先手动走一遍业务流程——注册、登录、改密码、下单、上传文件。每个请求都看一遍，重点盯三样东西：参数有没有回显到前端、返回包里有没有多余字段、服务端有没有对用户身份做二次确认。

拿登录环节说。有些系统登录失败和用户不存在的返回信息不一样，一个提示“密码错误”，另一个提示“用户不存在”。这就能枚举有效用户名。我遇到过一家，用户名枚举出来之后，配合弱口令字典，直接撞进三个普通账号。普通账号虽然权限低，但能上传头像。上传头像的接口只检查了Content-Type，没检查文件后缀。把shell.php改成shell.jpg，Content-Type改成image/jpeg，传上去之后访问路径，直接解析成PHP。从枚举到getshell，前后不到二十分钟。

再说一个案例。某个电商网站的商品详情页，URL里有个productId参数。正常请求是/api/product?productId=1001，返回商品信息。我把它改成productId=1001'，报错信息里直接把SQL语句打出来了——典型的SQL注入。更妙的是，这个接口没做频率限制。写个脚本跑sqlmap，五分钟拿到数据库名，十分钟拿到管理员表里的账号密码哈希。哈希是MD5，cmd5上一查，明文是“admin123”。后台地址藏在robots.txt里，登进去之后发现上传功能用的是FCKeditor，版本老得掉牙，直接传webshell。

这些漏洞都不新鲜，但为什么还在出现？因为开发习惯改不过来。前端校验图省事，后端觉得“反正前端已经拦了”。接口返回数据图方便，把整个用户对象丢给前端。文件上传图快，只判断MIME类型。SQL查询图直接，字符串拼接不参数化。每一个“图”字背后，都是一个可以撕开的口子。

挖漏洞的过程其实很枯燥。大部分时间是在看请求、改参数、观察响应。Burp Suite的Repeater标签开几十个，来回对比。有时候一个越权点，要试五六种参数组合——改用户ID、改角色字段、改租户标识、删掉某个鉴权头、替换成别人的token。成功的那一下，往往没什么激动，就是“哦，果然没校验”。

工具能帮你省力，但替代不了手感。扫描器报的“CSRF token缺失”可能只是业务不需要，报的“SSL弱加密”可能在内网根本无所谓。真正的漏洞藏在业务逻辑里——比如修改密码时没验证旧密码、比如订单金额前端传多少就收多少、比如邀请码可以无限次使用。这些扫描器看不出来，得靠人把业务流程拆开，一个环节一个环节地试。

最后说个反常识的观察。很多漏洞不是“挖”出来的，是“等”出来的。系统上线新功能，旧接口没下线；权限系统重构，老的后门还在；第三方组件升级，配置文件忘了改。我见过一个后台，登录之后URL里带个debug=1，页面底部直接显示当前SQL查询和服务器环境变量。问开发，说是测试时加的，忘了删。这种漏洞，扫描器扫不到，因为需要先登录。但一旦登录进去，等于把钥匙插在门上。

所以别迷信自动化。打开浏览器，开代理，点一遍系统，看每个请求的返回。改改数字，换换身份，传传文件。漏洞就在那些“想当然”的地方。

(责任编辑：时尚)