laravel本身无原生文件包含漏洞，但开发者误用用户输入拼接路径（如view()、storage::get()、file_get_contents()）且未校验，会导致路径遍历与任意文件读取风险；须严格白名单校验、basename过滤及realpath目录比对，并禁用危险php函数。
Laravel 本身不提供动态文件包含机制，所以没有原生的“文件包含漏洞”（如 PHP 的 include/require 注入），但开发者误用可控制路径的函数时，会人为引入高危风险——这本质上是路径遍历 + 不安全文件操作的组合问题。
为什么 Laravel 应用会出现类似文件包含的行为
框架层已禁用用户直接控制 include、require、view() 参数等常见入口，但以下场景仍可能绕过防护：
- 手动拼接路径后调用
file_get_contents()、Storage::get()或File::get()，且参数来自$request->input('file')等未过滤输入 - 使用
@include($template)或view($name)，而$template/$name来自用户请求（如 URL 查询参数） - 通过
config_path()、resource_path()等辅助函数拼接路径，未校验最终路径是否落在预期目录内
如何安全地处理用户指定的文件名或模板名
核心原则：绝不让任何用户输入直接参与路径构造或视图加载。必须做白名单校验或路径规范化后比对。
- 若需根据用户选择加载不同视图，用硬编码映射表：
$views = ['dashboard' => 'admin.dashboard', 'profile' => 'admin.profile']; $view = $views[$request->input('page')] ?? 'admin.default'; return view($view); - 若需读取用户指定配置文件（如多租户 YAML），先提取文件名基础部分：
$filename = basename($request->input('config')); if (!in_array($filename, ['tenant-a', 'tenant-b'])) { abort(403); } - 使用
realpath()+ 目录前缀比对防止路径穿越：$path = realpath(storage_path('app/' . $request->input('path'))); if (strpos($path, storage_path('app/')) !== 0) { abort(403); }
哪些函数和写法必须立刻排查
这些是真实项目中高频出问题的点，尤其在管理后台或富配置场景：
-
view($request->input('view'))—— 模板名不可控，直接导致任意视图渲染，可能触发 Blade 中的@php或@include注入 -
Storage::get($request->input('file'))—— 若未限制$file只能是logs/xxx.log格式，攻击者可传../../.env -
file_get_contents(config_path() . '/' . $request->input('cfg'))——config_path()返回绝对路径，拼接后极易越界 -
require base_path() . '/vendor/' . $request->input('loader')—— 这类写法已属严重反模式，应彻底删除
生产环境额外加固项
即使代码层做了校验，也要配合运行时防护：
- PHP 配置中禁用危险函数（在
php.ini中设置）：disable_functions = include, require, include_once, require_once, file_get_contents, readfile, fopen（注意：禁用后需确认业务无依赖） - Nginx/Apache 配置禁止访问敏感目录：
location ~ \.(env|log|json|yml)$ { deny all; } - 确保
.env文件不在 Web 根目录可访问范围内（Laravel 默认已通过public/入口隔离，但自定义部署时易出错）
真正危险的从来不是 Laravel 框架本身，而是开发者把 $request->input() 当作可信路径片段来用——哪怕只有一处没加 basename() 或白名单判断，就可能让整个应用暴露在任意文件读取甚至 RCE 风险下。
