Zsens Admin 插件安全开发：后台鉴权盲区、CSRF 跨站攻击与 SQL 注入的联合防御——基于中间件链路的零信任实践

在 Zsens Admin 插件开发中，权限与安全往往被拆成独立模块处理，但真实攻击场景下，鉴权绕过、CSRF 伪造与 SQL 注入常被组合利用形成攻击链。本文从 ThinkPHP 8 中间件执行链路出发，梳理三者的耦合风险与联合防御方案。

一、后台鉴权的"后置盲区"：为什么通过了中间件仍可能越权

Zsens Admin 采用 AuthMiddleware 进行登录态校验，但插件开发者容易忽略一个事实：中间件只验证"有没有登录"，不验证"能不能操作具体数据"。例如某订单插件的编辑接口：

public function edit(int $id)
{
    // 仅校验登录，未校验当前用户是否拥有该订单权限
    $order = OrderModel::find($id);
    return view('edit', ['order' => $order]);
}

攻击者只需遍历 id 参数即可横向越权访问他人数据。正确做法是在 Controller 层叠加数据级鉴权，利用 ThinkPHP 的模型查询范围自动注入当前管理员 ID：

// OrderModel.php
protected function scopeAdminAccess($query)
{
    $adminId = request()->admin_id;
    // 关联查询当前管理员有权限的店铺订单
    $shopIds = ShopModel::where('admin_id', $adminId)->column('id');
    return $query->whereIn('shop_id', $shopIds);
}

// Controller 中
$order = OrderModel::adminAccess()->find($id);
if (!$order) {
    throw new HttpException(403, '无权访问该订单');
}

关键注意点：模型查询范围命名需带业务前缀（如 adminAccess 而非 access），避免与其他插件的范围方法冲突导致权限逻辑被覆盖。

二、CSRF 防御的"异步陷阱"：AJAX 提交时 Token 校验的时序竞态

ThinkPHP 8 的表单令牌机制在同步页面中运作良好，但插件开发大量使用异步接口时会出现特殊问题。场景复现：某配置插件的前端页面通过 AJAX 分步保存，第一步获取配置表单，第二步提交修改：

// 前端错误写法：复用首次加载的 __token__
let token = document.querySelector('meta[name="csrf-token"]').content;
// 多次提交使用同一 token，ThinkPHP 默认单次验证后即失效

第二次提交必然触发 令牌数据无效 异常。解决方案不是关闭令牌验证，而是建立 Token 刷新契约：

1. 后端接口响应头携带新生成 Token：X-CSRF-Token: xxx
2. 前端拦截器自动提取并更新后续请求头
3. 对纯只读接口（如数据导出）显式标注 @csrf_pass 注解，避免无意义校验

// 插件基类控制器封装
protected function jsonSuccess($data, string $msg = 'success')
{
    $response = json(['code' => 1, 'msg' => $msg, 'data' => $data]);
    // 异步场景自动刷新 Token
    if (request()->isAjax()) {
        $response->header('X-CSRF-Token', token());
    }
    return $response;
}

特别提醒：若插件提供外部 Webhook 接收端点，必须完全禁用 CSRF 校验并改用签名验签，否则第三方平台回调必然失败。

三、SQL 注入的"ORM 幻觉"：findOrEmpty 与 whereRaw 的隐蔽风险

Think ORM 的参数绑定机制能有效防御常规注入，但插件开发中的两类写法会击穿防护：

风险一：动态字段名注入

// 高危：$field 来自前端传参
$field = input('field');
$value = input('value');
OrderModel::where($field, $value)->find();

当 field 传入 id OR '1'='1 时，ORM 无法对字段名做参数绑定。必须建立字段白名单校验：

protected array $allowedFields = ['order_no', 'status', 'create_time'];

public function safeQuery(string $field, $value)
{
    if (!in_array($field, $this->allowedFields)) {
        throw new ValidateException('非法查询字段');
    }
    return OrderModel::where($field, $value)->find();
}

风险二：whereRaw 的表达式拼接

插件中常见的复杂筛选需求容易催生危险代码：

// 某报表插件的"自定义时间范围"功能
$where = "create_time BETWEEN '{$start}' AND '{$end}'";
OrderModel::whereRaw($where)->select();

whereRaw 完全信任传入字符串。应改用参数化表达式：

OrderModel::whereRaw('create_time BETWEEN ? AND ?', [$start, $end])->select();

或更优方案——利用 Think ORM 的闭包查询构建器，彻底避免字符串拼接：

OrderModel::whereBetween('create_time', [$start, $end])->select();

四、联合防御：基于中间件优先级的"零信任"链路设计

将上述三层防护整合为可复用的插件安全中间件栈，通过 config/middleware.php 控制执行顺序：

return [
    'alias' => [
        'plugin_security' => [
            \app\plugin\middleware\CsrfRefreshMiddleware::class,  // ① 刷新 Token（最先执行，最后响应）
            \app\plugin\middleware\AdminAuthMiddleware::class,     // ② 登录态校验
            \app\plugin\middleware\DataScopeMiddleware::class,     // ③ 数据权限注入
            \app\plugin\middleware\InputSanitizeMiddleware::class, // ④ 输入清洗与字段白名单
        ],
    ],
];

各中间件的职责边界：

关键设计：DataScopeMiddleware 必须依赖 AdminAuth 的输出，若 admin_id 未挂载则直接中断，避免空值导致的权限扩散。

五、开发自测清单：发布前必须验证的 6 个场景

1. 越权读取：登录管理员 A，直接访问管理员 B 的数据 ID，预期 403
2. Token 复用：同一表单连续提交两次，第二次应正常处理（非 400）
3. 字段注入：将 ?field=id OR 1=1 传入查询接口，预期校验拦截
4. Raw 注入：所有 whereRaw 调用点传入带引号参数，预期无语法报错（证明参数绑定生效）
5. 权限降级：修改 JWT 中的 role 字段后请求，预期签名校验失败
6. 并发 Token：两个标签页同时操作，各自 Token 独立刷新互不干扰

以上测试建议写入插件的 tests/SecurityTest.php，作为 CI 流水线的强制门禁。

安全不是单一功能的堆砌，而是校验链路的环环相扣。在 Zsens Admin 插件开发中，理解中间件的执行时序、ORM 的参数绑定边界、以及前后端