php代码漏洞扫描

上个月帮一个朋友看他的代洞扫 WordPress 插件，装了个所谓"安全检测"工具跑了一遍，码漏描报告显示"无高危漏洞"。代洞扫我随手翻了翻源码，码漏描第 47 行一个 extract($_POST) 直接把我整笑了——这玩意儿要是代洞扫没漏洞，那才叫见鬼。码漏描工具没报，代洞扫不代表没问题。码漏描

PHP 漏洞扫描这件事，代洞扫很多人理解得太窄了。码漏描以为跑个 RIPS、代洞扫扔进 SonarQube 看一眼，码漏描就完事了。代洞扫实际远不止。码漏描扫描工具本质上是代洞扫模式匹配加数据流分析，它能抓的是"长得像漏洞"的代码，抓不到逻辑层面的东西。比如一个订单支付接口，参数校验写得漂漂亮亮，但业务逻辑上允许用户把金额改成负数——这种漏洞，任何自动化工具都扫不出来。

静态扫描能做什么，不能做什么

静态扫描擅长的是那些经典模式：eval()、system()、assert() 这类危险函数直接吃用户输入，或者 $_GET['id'] 没过滤就拼进 SQL 语句。PHP 生态里比较常用的开源方案有 PHPStan（偏类型检查，安全规则要自己写）、Psalm（支持污点分析）、RIPS（商业版强，免费版阉割严重）。

但静态扫描有个硬伤：它不理解业务。我见过一个项目，所有输入都过了 htmlspecialchars()，扫描报告干干净净。结果呢？文件上传接口只检查了 MIME type，攻击者改个 Content-Type 就能传 PHP 文件上去。这种漏洞靠的是运行时行为，静态工具看不到。

动态扫描补的是另一块

动态扫描（DAST）是拿工具去"打"你的应用，比如 OWASP ZAP、Burp Suite 的主动扫描。它模拟真实请求，看响应里有没有异常。好处是能发现配置问题、Header 缺失、CORS 配错这些静态分析看不到的东西。坏处也明显——覆盖率和爬虫质量强相关，SPA 应用经常爬不全，漏报率不低。

我自己的习惯是：静态扫描当第一道筛子，快速定位明显的脏代码；动态扫描当第二道，跑在测试环境上验证。两个都过了，再人工审一遍核心业务逻辑。别指望一键出报告就高枕无忧。

几个容易被忽略的扫描盲区

反序列化。unserialize() 的利用链往往藏在第三方库的魔术方法里，扫描器很难跨文件追踪完整链路。PHP 的 __destruct、__wakeup 组合利用，得靠安全研究员手工构造 POP chain。

竞争条件。文件上传、余额扣减这类操作，如果没加锁，扫描器根本不会去测并发场景。我见过一个积分兑换接口，并发请求能重复兑换，扫描报告里一个字都没提。

依赖组件漏洞。Composer 拉下来的包，版本旧了有 CVE，但你的代码本身没毛病。这时候得用 composer audit 或者 local-php-security-checker 单独扫依赖，跟扫业务代码是两码事。

说点实在的

扫描工具是辅助，不是答案。配置规则的时候别偷懒，把项目里自定义的过滤函数、数据库封装层告诉工具，否则误报能淹死你。跑完报告别只看"高危"那一栏，中低危里经常藏着真正的入口点。最后，任何扫描结果都要人工确认——工具说没问题的地方，恰恰是你最该仔细看的地方。

那个 WordPress 插件的朋友后来问我怎么办。我说先把 extract 删了，然后把所有 $_POST 的用法一个个过。工具？再跑一遍可以，但别信它说的"安全"。