thinkphp8路由变量未约束时，框架默认将url路径中的参数直接拼接到文件包含或目录读取的逻辑中，攻击者通过构造包含`../`的`id`参数即可突破当前目录限制，访问服务器上的任意文件。要解决这个问题，必须在路由定义中使用正则表达式对`id`进行严格约束，确保其只匹配预期的数字或特定字符格式，从而在路由解析阶段拦截非法的路径遍历尝试。
为什么未约束的路由变量会引发路径遍历
当ThinkPHP8的路由规则中定义了类似`/:id`的变量且未指定任何验证规则时，框架会将URL中对应位置的字符串原样赋值给该变量。如果后续的业务逻辑（如模型查询、文件包含）直接使用这个变量作为文件路径的一部分，而没有进行额外的安全过滤，攻击者就可以输入`../../etc/passwd`这样的值。由于缺乏类型检查和长度限制，系统会将其视为合法的文件名片段，导致相对路径向上跳转，最终读取到敏感配置文件。
use think\facade\Route;
// 危险写法：未约束 id，允许任意字符
Route::rule('read/:id', 'Index/read');
// 安全写法：使用正则约束 id 为纯数字
Route::rule('read/:id<\d+>', 'Index/read');
在上述代码中，第一种写法是漏洞产生的根源。当用户请求`/read/../../../config/database.php`时，`$id`的值就是`../../../config/database.php`。如果控制器中执行了`file_get_contents($id)`，就会直接泄露数据库配置。第二种写法通过``限制了`id`只能由数字组成，任何包含`.`或`/`的请求都会因为不匹配正则而被路由系统拒绝，返回404错误，从而从源头上阻断了路径遍历的可能。
立即学习“PHP免费学习笔记（深入）”；
修复 Core bailout 状态损坏安全问题，以及 BZ2、DOM、PDO、Opcache/JIT 内存与执行错误，改进 Unicode 字素处理、URL 解析、TLS 流状态、信号分发及会话错误处理。
如何正确配置路由约束以防御此类攻击
除了使用正则表达式，还可以结合ThinkPHP内置的验证器或中间件来增强安全性。核心原则是“最小权限”，即路由变量只接受业务必需的字符集。对于ID类参数，通常只允许整数；对于slug类参数，只允许字母、数字和连字符。通过在路由定义中显式声明这些约束，可以确保进入控制器的数据是经过清洗和验证的，无需在业务代码中重复编写校验逻辑。
// 更复杂的约束示例：只允许字母、数字和下划线
Route::rule('file/:name<[a-zA-Z0-9_]+>', 'Index/download');
// 或者使用闭包函数进行动态约束
Route::rule('api/:token', function ($token) {
if (!ctype_alnum($token)) {
throw new \think\exception\ValidateException('Invalid token');
}
return 'Valid token';
});
在实际开发中，建议统一使用正则约束来处理所有外部输入的路由变量。例如，上述代码展示了如何限制文件名只包含安全的字符集，以及如何使用闭包函数进行更复杂的逻辑判断。这种方式不仅防御了路径遍历，还能防止SQL注入和其他基于参数篡改的攻击。记住，路由层的约束是第一道防线，它应该尽可能严格地过滤掉所有非预期格式的输入。
具体输入下路径遍历的实际触发条件
当使用未约束的路由`/:id`并传入`id=../../`时，系统不会自动截断或转义这些字符。ThinkPHP的路由解析器会将`../../`识别为有效的路径段，并将其传递给控制器。如果控制器中使用`include $id . '.php'`，实际加载的文件将是上级目录下的`.php`文件。这种行为的根本原因在于PHP的文件系统操作本身支持相对路径，而框架没有强制要求开发者对动态拼接的路径进行规范化处理。因此，依赖路由约束是防止此类问题最可靠的手段，因为它在请求到达业务逻辑之前就已经排除了非法路径。
