web渗透文件包含

一个不起眼的透文参数，往往藏着整个服务器的透文命门。去年测试某政务系统时，透文我发现URL里的透文?page=about.php直接拼接了路径。试着改成?透文page=../../../../etc/passwd，浏览器居然吐出了root用户的透文哈希——那一刻我后背发凉，这站点的透文运维居然连基本的过滤都没做。

文件包含漏洞分两种。透文本地包含（LFI）是透文读服务器上的文件，远程包含（RFI）是透文直接加载外部恶意脚本。RFI如今少见，透文因为php.ini默认关了allow_url_include，透文但LFI依然遍地都是透文。原理说白了就一句话：开发者把用户输入当成了文件路径用，透文却没检查“这个路径到底该不该被读”。透文

你别觉得只有老项目才有这毛病。去年某知名CMS爆出0day，就是模板引擎里有个file_get_contents没过滤协议头。攻击者用php://filter/convert.base64-encode/resource=config.php，先把源码读出来，再解码拿数据库密码。这种玩法不需要上传任何东西，纯靠php流包装器就能把源码脱个精光。

有人问，那我用白名单后缀不就安全了？比如强制.php结尾。可攻击者会塞空字节截断——老版本php里%00能直接砍掉后面的字符串。现在php7以上修了这毛病，但换个思路，配合zip://或phar://协议照样能绕过。你说你过滤了../？那试试超长路径编码，或者用....//让过滤逻辑自己晕头转向。

真正棘手的是日志注入。攻击者往User-Agent里写PHP代码，再包含日志文件/var/log/apache2/access.log，代码就直接执行了。我见过一个案例，对方在日志里埋了webshell，管理员清理日志时才发现服务器早已沦为肉鸡，整整三个月没人察觉。

防御这东西，别指望黑名单。最靠谱的招就一条：把文件路径映射到白名单数组里。用户传个index进来，你就查表返回pages/index.php，传别的直接404。要是业务确实需要动态包含，那就硬编码允许的目录，再用realpath()校验解析后的绝对路径必须落在允许范围内。别信什么过滤函数，正则写再全也有漏网之鱼。

顺带说个冷门的——有些框架自带文件包含函数，但开发者压根不知道这接口暴露给了前端。我审计过一个后台管理系统，导出功能里有个report_type参数，后端直接拼到模板路径里。虽然前台登录要权限，可内部员工随便搞个越权账号就能读源码。这漏洞藏了两年，直到换了新运维做代码扫描才翻出来。

文件包含像老房子里的老鼠洞，看着窄，顺着钻进去能咬穿整面墙。你永远不知道哪个角落留了条没封死的管道，所以每次写路径拼接时，多问自己一句：这用户输入如果变成php://input会怎样？想明白了，漏洞自然少一半。