文件包含漏洞利用

一个不起眼的文件参数，可能让整个网站沦陷。包含文件包含漏洞（File Inclusion）就是漏洞利用这样一种存在——它藏在你对文件路径的拼接里，藏在开发者对用户输入的文件无条件信任里。我见过太多把`?包含page=about.php`写进URL的站点，也见过攻击者只改一个字符，漏洞利用就把`about.php`换成`../../../../etc/passwd`，文件然后服务器老老实实地把密码文件吐出来。包含这不是漏洞利用理论，这是文件每天都在发生的现实。

漏洞的包含核心逻辑简单到让人发笑：程序接收用户传入的文件名，然后直接include进来。漏洞利用如果开发者没做任何过滤，文件攻击者就能指定任意路径。包含本地文件包含（LFI）能读取服务器上的漏洞利用敏感文件，远程文件包含（RFI）更狠——直接把恶意代码从外部URL拉进来执行。很多新手以为这只是“读文件”，但结合PHP的伪协议，`php://filter`能让你读到源码，`data://`能直接注入PHP代码。一个LFI漏洞，往往就是拿下服务器的起点。

拿个具体场景说吧。某个后台管理系统的日志查看功能，路径参数是`logfile=access.log`。攻击者把`logfile=../../../../var/log/auth.log`，看到的是系统登录日志。这还不算完——如果日志里记录了User-Agent，攻击者可以在UA里写一句``，然后再次请求，让程序包含这个日志文件。日志文件瞬间变成了一句话木马。整个过程不需要上传任何文件，只用浏览器就能完成。这种利用方式老套，但有效，因为开发者总是忘了日志也是文件，而且日志里什么都能塞。

防御的思路其实也不复杂。最根本的一条：永远不要直接拼接用户输入作为文件路径。用白名单映射，比如`$pages = ['home'=>'home.php','about'=>'about.php']`，用户传`home`，你取`$pages['home']`。传别的？直接404。如果确实需要动态包含，那就严格校验路径，禁止`../`，禁止绝对路径，禁止协议包装器。再退一步，PHP里可以设置`allow_url_include=Off`，至少把远程包含这条路堵死。

但说实话，光靠代码层面的修补不够。我见过太多团队修完一个参数，另一个接口又冒出来同样的问题。根子在于开发习惯——没有把用户输入当作不可信数据来对待。安全不是加个WAF，不是扫描器跑一遍就完事。你得让每个写代码的人都明白：你写的每一行include，都是在给攻击者递刀。文件包含漏洞之所以长盛不衰，就是因为总有开发者觉得“谁会这么传参啊”。会，而且第一个试的就是这种人。

下次你看到URL里带着`file=`、`page=`、`path=`这种参数时，不妨多想一秒。这秒的思考可能比任何安全培训都管用。