上周三凌晨两点，网络某电商平台的安全后台日志里跳出一条异常记录：一个普通用户账号在30秒内连续请求了482次优惠券接口。运维人员起初以为是漏洞脚本刷券，直到发现该账号的检测返回数据里混进了其他用户的手机号和收货地址。漏洞不在优惠券逻辑本身，报告而是网络接口鉴权时把用户ID直接拼进了SQL查询语句——一个典型的注入点，却藏在促销活动的安全临时代码里，上线前没人细看。漏洞

这就是检测漏洞检测的日常。你永远不知道问题会从哪个角落冒出来，报告往往不是网络核心业务，而是安全某个为了赶活动临时加的补丁。我见过最离谱的漏洞一个案例，某政务系统的检测人脸识别接口，开发人员为了调试方便，报告留了个万能验证码“000000”，上线三个月没删。检测时随手一试就进去了，能查到所有注册用户的身份证照片。

说回检测本身。很多人以为拿个扫描器跑一遍就完事了，其实那只是第一步。自动化工具能发现常见漏洞，比如未过滤的输入、过时的组件版本、配置错误的CORS头。但真正要命的漏洞，通常需要人去看代码逻辑。举个例子，某金融App的转账接口，参数里有个`amount`字段，前端做了正数校验，后端也做了。但攻击者可以把`amount`改成数组，比如`[100, -200]`，后端解析时取了第一个值做校验，实际扣款却用了第二个值。这种逻辑漏洞，扫描器根本扫不出来。

检测流程一般分三块：信息收集、漏洞验证、影响评估。信息收集阶段，我会先看目标暴露了哪些端口、用了什么框架、有没有泄露的API文档。有时候一个`/swagger-ui.html`就能省掉半天功夫。漏洞验证要小心，别把测试环境搞崩了。曾经有个同事在验证一个命令注入漏洞时，直接执行了`rm -rf /tmp/test`，结果那台服务器上正好有个定时任务在跑，把整个测试库给清了。影响评估最容易被忽略，但恰恰最重要。一个XSS漏洞在普通页面可能只是弹个窗，但在管理员后台，就能直接窃取会话令牌，进而控制整个系统。

具体到技术细节，SQL注入现在少了，但NoSQL注入多了起来。MongoDB里如果用`$where`拼接用户输入，攻击者可以构造`'; return true; var foo='`这样的payload。命令注入也还在，尤其是那些调用系统命令做文件处理的接口。我上个月测的一个视频转码服务，上传文件名没过滤，直接拼进了`ffmpeg`命令里。传个文件名叫`test.mp4; cat /etc/passwd`，服务器就把密码文件返回来了。

修复建议不能只说“过滤输入”这种废话。得具体到代码行。比如那个SQL注入，要改成参数化查询，而不是简单转义。那个万能验证码，得删掉调试逻辑，加个环境变量判断。还有那个数组绕过，得在反序列化时强制类型检查。修复完还得复测，很多人改完不测，结果漏洞还在，只是换了个触发方式。

最后说个观察。大部分漏洞不是技术多高深，而是开发人员图省事。临时加个`eval`，调试留个后门，参数不校验直接拼SQL。检测报告写多了会发现，同样的问题在不同项目里反复出现。所以我现在写报告，除了列漏洞，还会加一段“同类问题排查建议”，告诉开发去搜代码里所有`eval`、所有字符串拼接的SQL、所有硬编码的密钥。这比单个修复有用得多。