代码审计和漏洞扫描

去年帮一个朋友看他们公司的代码洞扫系统，上线前跑了三轮漏洞扫描，审计报告全是和漏绿的。结果我随手翻了两页代码，代码洞扫在一个订单查询接口里发现SQL拼接，审计参数直接来自前端。和漏扫不出来，代码洞扫因为扫描器只测了GET请求，审计那个接口用的和漏是POST。

这事说明一个问题：漏洞扫描和代码审计根本不是代码洞扫一回事，但大多数人把它们混着用。审计

扫描器在做什么

漏洞扫描本质上是和漏黑盒测试。它从外部发请求，代码洞扫看响应，审计根据特征库匹配已知漏洞。和漏像Xray、AWVS、Nessus这些工具，强项是覆盖面广、速度快，几千个URL几分钟跑完。但它只能看到"输入→输出"这一层。

问题在于，很多漏洞藏在业务逻辑里。比如一个转账接口，扫描器看到的是参数正常、返回200，它不知道把金额改成负数就能给自己加钱。再比如越权漏洞，扫描器没有两个不同权限的账号，压根测不了。

还有个更现实的：扫描器对认证态的支持很有限。现在稍微正经点的系统都有登录、Token刷新、验证码，扫描器配起来费劲，配不好就只能在登录页面上打转。

代码审计是白盒。你拿到源码，从入口点开始追数据流。用户输入从哪个Controller进来，经过哪些Service，最终有没有做过滤就到了危险函数里。

我习惯先找危险函数。Java里就是Runtime.exec、Statement.execute、ObjectInputStream.readObject这些。PHP里就是eval、system、include。找到之后往回追，看参数可不可控。可控就是漏洞，不可控就是误报。

这个过程很枯燥，但能发现扫描器永远找不到的东西。比如一个SSRF，代码里做了白名单校验，但白名单是用startsWith做的，攻击者注册一个http://inner.com.evil.com就绕过了。扫描器不会知道你的白名单逻辑有缺陷。

再比如反序列化漏洞。扫描器发一个序列化数据过去，服务端报500，它标记为"低危"就跳过了。但审计的人看到readObject没有做类型检查，结合某个依赖库的gadget chain，这就是一个RCE。

我的做法是：扫描器先跑一遍，把明显的SQL注入、XSS、目录遍历捞出来，这些修起来快，先堵住。然后代码审计重点看三块——认证授权、支付逻辑、文件操作。这三块出问题，危害最大，扫描器也最测不出来。

有个细节：扫描器的报告别直接丢给开发。他们看到"疑似SQL注入"往往不知道怎么复现。审计的人应该把PoC写清楚，哪个接口、什么参数、返回什么，开发一看就明白。

反过来，代码审计也别想着覆盖全部代码。一个中型项目几十万行，全看一遍不现实。优先看最近半年新增的代码、对外暴露的接口、处理敏感数据的模块。老代码如果一直没出过事，风险相对低。

扫描器和审计工具都会产生大量误报。我见过一个团队，扫描器报了200个漏洞，开发修了两个月，最后发现180个是误报。真正的问题被淹没在噪音里。

所以不管用哪种方式，最后都需要人来判断。工具负责缩小范围，人负责确认和定级。一个需要登录才能触发的XSS和一个不需要登录的SQL注入，修复优先级完全不同。这个判断，目前工具做不了。

说到底，扫描器是筛子，审计是镊子。筛子快但漏得多，镊子慢但准。两个都用，别指望其中一个能替代另一个。