本地文件包含（LFI）漏洞，本地包含说白了就是文件攻击者能借你的网站，读取服务器上他本不该看到的漏洞文件。这玩意儿比远程文件包含（RFI）更阴险，本地包含因为不需要外联，文件纯靠服务器自己家底儿就能搞事。漏洞

最常见的本地包含触发点就是动态页面里的参数。比如某网站有个URL长这样：index.php?文件page=about.php，服务器会老老实实把page参数拼进文件路径再include进来。漏洞攻击者把page改成../../../../etc/passwd，本地包含一层层往上跳目录，文件就能把系统用户列表给扒出来。漏洞你问为啥要跳那么多层？本地包含因为不知道网站根目录在文件系统里的绝对深度，多跳几层总没错——反正路径解析时多余的文件../会被忽略。

更麻烦的漏洞是配合日志注入或/proc/self/environ这类特殊文件，能直接getshell。我去年帮朋友排查过一个老PHP项目，后台有个导出功能用了文件包含，攻击者把User-Agent头改成PHP代码塞进访问日志，再用LFI去包含日志文件——代码就这么被服务器执行了。整个过程没任何上传操作，防火墙看得一脸懵。

判断一个LFI能不能利用，关键看两点：一是参数是否被直接拼入路径，二是能否控制路径前缀。有些开发者会自作聪明加个pages/前缀，比如include("pages/".$_GET['page'])，这时候你就要用../把前缀抵消掉，或者试试PHP的php://filter流协议——php://filter/convert.base64-encode/resource=config.php能直接读出源码内容，连执行都不用。

修复思路其实不复杂。最笨但有效的方法是白名单校验：定义好允许包含的页面数组，参数不在名单里就直接拒绝。稍微聪明点儿的做法是关闭allow_url_include，再把路径用realpath()解析后检查是否在允许目录内。别嫌麻烦，str_replace过滤../这种黑名单方案早被绕烂了——攻击者用....//或者URL编码就能轻松绕过。

说句扎心的，LFI漏洞高发区往往是那些“内部用的小工具”。主站防护得跟铁桶似的，结果后台某个导出报表的脚本成了突破口。开发时图省事直接用动态包含，上线后没人再管——这种场景我见太多了。

最后提醒一句：如果代码里出现include、require且参数来自用户输入，别犹豫，立刻按高危漏洞处理。别信“只有登录用户才能访问”这种屁话——攻击者会想办法搞到低权限账号，或者那功能本身就在未登录页面上。