```html

去年帮一个朋友看他的 WordPress 站点，刚打开后台就弹了个 eval($_POST['x']) 的描工报错——代码里被人插了后门。他问我有没有什么工具能提前扫出来，洞扫别等中招了再救火。描工这事让我意识到，洞扫很多人对 PHP 漏洞扫描工具的描工理解还停留在“跑一遍就完事”的阶段，实际用起来坑不少。洞扫

扫描器不是描工万能钥匙，得看喂什么料

市面上常见的洞扫 PHP 漏洞扫描器，比如 RIPS、描工Progpilot、洞扫SonarQube 的描工 PHP 插件，底层逻辑分两派：静态分析（SAST）和动态分析（DAST）。洞扫静态的描工那类直接读源码，把 $_GET、洞扫$_POST 这些超全局变量当污点源，顺着数据流追到 mysql_query、system 这类危险函数。听起来很美好？我拿一个真实项目试过 RIPS，它报出 37 个“疑似 SQL 注入”，结果一半是误报——因为代码里用了预处理，但工具没识别出 prepare() 和 execute() 的绑定关系。

动态扫描器像 Wapiti、Arachni 则更像黑盒测试，给 URL 发 payload 看回显。这类工具对 include($_GET['page']) 这种文件包含漏洞特别敏感，但遇到需要登录才能触发的逻辑漏洞就歇菜。我见过一个 CMS，后台有个 extract($_POST) 覆盖变量的漏洞，Wapiti 扫了三遍都没发现，因为爬虫压根没爬到那个需要管理员权限的页面。

自己写规则比依赖现成工具更靠谱

现成工具最大的问题是“通用”。它们不知道你的框架怎么处理路由，不知道你的 ORM 怎么防注入。我现在的习惯是：用 PHPStan 或 Psalm 做基础类型检查，再写自定义规则。比如下面这段正则，专抓那种直接拼接 SQL 的写法：

$pattern = '/query\s*\(\s*["\']\s*SELECT.*\.\s*\$/i';

配合 grep -rPn 在 CI 里跑一遍，比等扫描器跑十分钟快得多。当然这招只防低级错误，遇到 call_user_func 动态调用就瞎了。所以还得结合 RIPS 的 AST 分析，把两者结果交叉比对。

有个做安全的朋友更绝——他直接改 PHP-Parser 的 visitor，把 assert()、create_function() 这些废弃函数的调用全标记出来。因为 PHP 7 之后这些函数要么移除要么行为变了，老代码里藏着就是定时炸弹。这种定制化扫描，商业工具根本给不了。

扫描频率比工具选择更重要

很多人装完扫描器就扔在那，半年跑一次。PHP 漏洞的利用窗口往往只有几小时——比如 CVE-2024-4577 那个 CGI 参数注入，PoC 公开当天就有批量扫描器在找目标。我的做法是把扫描拆成三层：提交代码时用 PHPCS 做语法级检查，合并到主分支触发 Psalm 做数据流分析，每天凌晨用 Wapiti 对预发布环境做一次动态爬取。三层过滤下来，能拦掉九成以上的低级漏洞。

但别指望工具能发现逻辑漏洞。比如一个优惠券系统，if ($user->is_vip) { $discount = 0.8; } 这种业务逻辑，扫描器看不懂。得靠人读代码，或者写针对性的单元测试。工具是筛子，不是保险箱。

```