文件包含漏洞出现的文件原因是

一个变量，直接拼进了文件路径，包含然后被include了——就这么简单。漏洞你写代码时图省事，出现把用户输入当成文件名的文件一部分，服务器就乖乖地把那个文件读出来，包含执行里面的漏洞代码。这不是出现什么高深黑客技巧，是文件开发者偷懒留下的门。

我见过最典型的包含案例，是漏洞某个老站点的后台语言切换功能。URL里有个参数叫lang，出现后端代码是文件include("lang/".$_GET['lang'].".php")。攻击者把lang改成../../../../etc/passwd，包含路径穿越成功，漏洞密码文件直接暴露。更狠的，改成data://text/plain;base64,PD9waHAgcGhwaW5mbygpOz8+，服务器就把这段base64解码后当成PHP执行了。一个远程代码执行，就这么到手了。

根子在哪？在开发者对输入的不信任不够深。文件路径拼接时，没人想过用户会塞进来多少个../，也没人想过协议头可以被替换。PHP的include和require天生支持远程URL，allow_url_include如果开着，等于主动给攻击者递刀。你问为什么会有这种开关？早期PHP设计者觉得远程文件包含是特性，不是漏洞——直到被人用烂了才默认关闭。

还有一种情况更隐蔽：变量不是直接来自用户，而是从数据库里读出来的。比如用户上传头像后存了文件名，后台展示时用include($avatar_path)。攻击者先注册个账号，把头像路径改成一串PHP代码，等管理员访问后台预览，代码就执行了。这种二次包含，排查起来比直接传参难得多，因为开发者的注意力全在入口参数上，忘了数据库里的数据同样可能是脏的。

再看看那些框架自带的模板引擎。按理说模板路径是写死的，可有些开发者为了让用户能自定义主题，把模板名也做成了可传参。Smarty的fetch($_GET['tpl'])，Twig的loadTemplate($_GET['page'])，看着方便，实则把整个文件系统都暴露了。攻击者甚至不用读代码，直接扫参数名就能猜到哪个是可利用的。

修复其实不难：路径白名单、禁止特殊字符、关闭远程包含、用绝对路径而不是相对路径。但现实是，很多项目上线时根本没做过安全测试，代码里满是这种随手写的include。等到被扫描器扫出漏洞，往往已经被人拖过库了。

说到底，文件包含漏洞的本质是信任边界被越过了。你信了不该信的数据，然后把它们当成了系统内部的东西。安全圈有句话：所有输入都是有害的，直到证明无害。可写代码的人总觉得自己写的接口没人会恶意调用——这种侥幸心理，才是漏洞真正的温床。

本文地址：http://www.79wt.cn/news/1286b0399868.html