去年帮一个做外贸的站漏朋友看站点，他在后台发现了一条从没见过的洞扫管理员账号。查日志才发现，站漏有人通过一个第三方插件里的洞扫文件包含漏洞，往服务器上丢了WebShell。站漏整个过程不到两分钟，洞扫用的站漏全是自动化工具扫出来的。这件事让我意识到，洞扫很多PHP开发者对漏洞扫描的站漏理解还停留在"装个安全插件就完事"的阶段，实际上远没那么简单。洞扫

PHP网站之所以容易被扫出问题，站漏跟它的洞扫历史包袱脱不了关系。早期PHP大量依赖全局变量注册、站漏动态包含、洞扫弱类型比较这些特性，站漏代码写起来快，但埋雷也快。比如include($_GET['page'])这种写法，在2005年可能很常见，放到今天就是典型的本地文件包含漏洞。扫描器一碰到这种参数，会立刻尝试用/etc/passwd或php://filter去读文件，命中率极高。

市面上的扫描工具大致分两类。一类是像WPScan、Nikto这样的通用扫描器，靠特征库匹配已知漏洞；另一类是RIPS、Progpilot这种静态代码分析工具，直接读PHP源码，跟踪变量在函数间的传递路径。我自己的习惯是两者都用，但更看重静态分析。原因很直接：动态扫描只能发现已经暴露出来的入口，静态分析能顺着代码逻辑找到还没被触发的隐患。有一次用RIPS扫一个自研CMS，它在upload.php里发现上传文件名经过了md5()处理，但move_uploaded_file()的目标路径拼接时用了../没过滤，直接标红。

手工验证这一步省不掉。扫描器报出来的结果里，误报能占到三成以上。比如它看到一个eval()就报警，但实际代码里eval的参数是硬编码的常量，根本没有用户输入。这时候就得打开源码，顺着数据流看一遍。我一般会重点盯三个地方：$_GET、$_POST、$_COOKIE这三个超全局变量有没有经过过滤就进了SQL查询、文件操作或命令执行函数。还有unserialize()，这玩意儿在PHP里就是个定时炸弹，反序列化链一旦被构造出来，RCE是分分钟的事。

扫描频率也是个实际问题。很多团队只在上线前扫一次，之后再也不管。但PHP生态更新太快，Composer依赖里一个guzzlehttp/guzzle的旧版本可能下个月就被曝出SSRF漏洞。我的做法是在CI流程里挂一个composer audit，每次合并代码前自动跑一遍，再把RIPS集成到预发布环境，每天凌晨扫一次全量代码。听起来麻烦，但比出事之后熬夜排查强得多。

有个细节容易被忽略：扫描器本身的配置。默认规则集往往太宽泛，扫出来的报告几百页，没人看得完。我通常会根据项目实际情况调整，比如这个项目根本不用system()和exec()，那就把命令执行相关的规则调成高优先级，其他降级。这样报告出来只有十几条，每条都值得细看。

最后说个真实案例。一个客户坚持说自己的站点用了某知名安全插件，绝对没问题。我拿php://filter试了一下他的download.php?file=参数，直接读出了config.php的源码，数据库密码明文躺在里面。安全插件拦的是已知攻击特征，但参数过滤没做好，照样白搭。扫描器能帮你发现问题，修不修、怎么修，还是得靠人。