ThinkPHP 5.0 控制器四类高危漏洞分析与修复建议

落日邮差

发布时间：2026-08-25| 110人浏览过

原创

前言

ThinkPHP 5.0 的控制器层问题，危险之处不只是单点漏洞，而是请求入口、路由解析和参数过滤可以被串成完整利用链。本文按四类高危场景拆开讲清成因与修复位置，并保留可直接落地的补丁代码，方便你快速评估旧项目该先封哪一层。

ThinkPHP 5.0 在不少老项目里仍在运行，但控制器相关的风险点往往不是单一漏洞，而是路由、请求方法和输入处理共同叠加后的结果。本文按四类常见高危问题逐项拆解：先看漏洞为什么会被打通，再对应到入口文件、框架核心文件和业务参数接收处的修复位置，方便你判断项目该先补哪一层、补完后还要检查什么。

控制器名未校验，为什么会直接打到 RCE

TP5.0 默认允许通过 URL 路径参与控制器解析，例如 /index.php?s=/index/thinkapp/invokefunction。问题不在于“能传控制器名”本身，而在于框架没有对控制器命名做足够严格的限制，攻击者就有机会把框架内部类路径拼进请求里，进一步触发 invokeFunction 这类危险逻辑。

这一类问题的危险点，是把“路由入口”变成了“内部调用入口”。如果线上项目还保留默认解析方式，又没有额外拦截，就可能被直接利用去执行任意函数、读取敏感文件，严重时甚至能继续落到 WebShell 写入。

修复思路

在入口文件 public/index.php 或全局中间件中增加硬拦截，优先挡掉明显异常的路径特征。
对包含 think、invokefunction、call_user_func、eval 等关键字的请求参数直接返回 404 或中断执行。
这类补丁适合老项目先止血，但不能替代后续的控制器名格式校验。

可直接加在 App::run() 前的示例代码如下：

控制器名与请求方法双重收口的暖色专栏配图 — **先堵路径，再限方法**把控制器路径拦截和 HTTP 方法白名单放在同一张图里。

if (isset($_GET['s']) && preg_match('/[\\\\]|(think|invoke|call_user|eval|system|exec)/i', $_GET['s'])) {
    header('HTTP/1.1 404 Not Found');
    exit('Invalid controller path');
}

这里的核心作用是先拦“路径里不该出现的内容”。对于无法立刻升级框架、又必须继续跑线上业务的项目，这一步通常是见效最快的防护措施。

_method 覆盖是怎么把请求过滤链变成命令执行的

_method 变量覆盖问题的关键，在于请求对象构造阶段对外部输入过于信任。当提交 _method=__construct，同时再配合可控的 filter[] 参数时，Request 对象的 __construct 方法会遍历 POST 数据做属性赋值，结果就是 $this->method 和 $this->filter 被攻击者改写。

一旦过滤链中的函数名也被带入，例如 system、phpinfo 等，后续在参数过滤阶段就可能直接触发危险函数调用。也就是说，这不是单纯的“HTTP 方法伪造”，而是借方法覆盖进入对象内部状态，再把过滤流程劫持为执行流程。

修复重点

生产环境必须关闭 app_debug，同时禁用 var_method 这类可被外部利用的方法覆盖入口。
修改 thinkphp/library/think/Request.php 中的 method() 方法，在解析 var_method 后立刻做白名单校验。
即使允许方法伪装，也只能接受标准 HTTP 动词，不能把任意字符串写回 $this->method。

可替换原 method 方法中 POST 解析部分的修复代码如下：

自动路由与数组输入校验的暖色专栏配图 — **解析边界与输入边界**用左右对照的方式说明两类常见误区：关闭路由不等于没有解析风险，接收数组也不等于数组内容安全。

if (isset($_POST[Config::get('var_method')])) {
    $method = strtoupper($_POST[Config::get('var_method')]);
    if (!in_array($method, ['GET', 'POST', 'PUT', 'DELETE', 'PATCH', 'HEAD', 'OPTIONS'])) {
        throw new HttpException(400, 'Invalid HTTP method');
    }
    $this->method = $method;
    if (isset($_POST)) {
        foreach ($_POST as $key => $val) {
            if ($key === Config::get('var_method')) unset($_POST[$key]);
        }
    }
}

这一段修复做了两件事：先限制方法值只能落在白名单里，再把对应参数从 $_POST 中移除，避免后续流程继续带着污染数据运行。对老版本项目来说，这是比单纯关配置更稳的一层补丁。

自动路由解析为什么会绕过权限控制

当配置为 url_route_on=false 且 url_param_type=1 时，框架会退回到按顺序解析的模式。问题在于，部分版本即使关闭了显式路由，内部仍残留控制器名动态拼接逻辑，于是未定义控制器可能被继续加载，或者让原本不该暴露的方法被误调用。

很多项目误以为“关掉路由就安全了”，但这里的风险恰恰说明，配置项本身不等于完整防护。真正需要确认的是：控制器名从请求中被提取出来以后，是否还做过格式级别的验证。

落地修复方式

先确认 config/app.php 中已经明确配置 'url_route_on' => false。
再到 thinkApp 类的 module() 方法里，在控制器名提取后立刻校验格式。
校验目标很明确：只允许合法类名组成，拒绝带分隔符、特殊符号或异常拼接结果的控制器名。

修复代码可插入在 $controller = Loader::parseName($controller, 1, true); 后：

$pattern = '/^[A-Za-z][A-Za-z0-9]*$/';
if (!preg_match($pattern, $controller)) {
    throw new HttpException(404, 'Controller name is invalid: ' . $controller);
}

这段规则看起来简单，但作用非常直接：只允许以字母开头、后续由字母数字组成的控制器名进入后续加载流程。对于依赖默认控制器解析的项目，这是防止异常类名穿透框架的一道硬边界。

input('id/a') 为什么会把数组输入带进 SQL 注入

第四类问题常出现在业务代码里，不一定属于框架核心缺陷，但同样危险。比如使用 input('id/a') 强制接收数组后，开发者又直接把结果送进 where('id','in',$id)。如果没有对数组元素做过滤或边界校验，攻击者就可能构造恶意内容，例如 id[0,updatexml(0,concat(0x5e,user()),0),0]，从而触发报错注入。

这里最容易被忽略的一点是：/a 修饰符只是在接收层面把参数当数组处理，并不代表数组里的每个元素已经安全。只要后面直接拼接到查询条件中，问题就会从“输入格式方便”变成“批量注入入口”。

业务代码里应当怎么收口

不要无条件使用 /a 修饰符接收用户输入，尤其是直接参与查询条件的参数。
数组型参数至少要做两层检查：先校验是不是数组、数量是否超限，再逐项校验元素类型和值范围。
限制长度不仅是为了安全，也能防止一次性传入过大数组拖垮查询。

可替代原始 input("id/a") 的推荐写法如下：

$id = input('id/a', []);
if (!is_array($id) || count($id) > 100) {
    throw new HttpException(400, 'Invalid id format');
}
foreach ($id as $v) {
    if (!is_numeric($v) || $v < 1 || $v > 9999999) {
        throw new HttpException(400, 'Invalid id value');
    }
}
$data = Db::name('users')->where('id', 'in', $id)->select();

这段处理把“是否为数组”“数组是否过长”“元素是否为合法数字”三层条件都补上了。只有通过这些检查后，再进入 where in 查询，才算把风险真正收住。