999885c38f
协议（唯一权威文档：docs/柜控板固件对接文档.md） - 应答必带 act（与请求一致）、msg_id 与请求一致；判"应答 vs 指令"只看有没有 suc - dev_id 只在 auth_str/login 携带；其余报文用内部字段 _dev_id 路由（下发前由 device-server 摘除） - id 只表示动作目标（柜级省略 / 一段=单板 / 两段=仓体级），不再含 IMEI - msg_id 每连接从 1 起自增；60 秒交互超时；status_post 每通道 18 字符 hex 全量上报 - 未登录连接 30 秒内未 login 即断开；未登录只放行 auth_str/login 平台侧实现 - 上行解析按新结构重写（cabinet/boards/battery），删除废弃的 status/parsed_status - 订单：唯一入口 = on；bat_in 只登记电池台账；4 条结束路径统一走 finalize_order（含充电记录落库） - 新增设备日志保留策略（90 天，分批删除）；未登记 IMEI 静默丢弃；停电标记按 status1 bit0 恢复清除 - 待确认第 13 项兜底：平台侧按 电压 × 电流 × 时间 积分计算订单电量（workers/energy.rs） - 待确认第 18 项兜底：status_post bit7 连续 2 次无电池 → 判定电池被拔走并提前结单 修复（均为部署后才暴露的问题） - 队列消费禁用 BRPOP：无限阻塞会因代理掐连接永久卡死（零错误日志）；有限超时也只是 "超时才醒"，下行指令延迟 15~45 秒 → 改为 RPOP 非阻塞轮询，延迟降到 0.1~0.2 秒 - sync_iccid 把可空列 iccid 按 Option<String> 解码 → 整条 login 失败（ICCID 未上报的新柜子永远登录不上） - 迁移读 information_schema.COLUMN_COMMENT 需 CAST(... AS CHAR)（MySQL 8 驱动报 VARBINARY，否则迁移 panic） - 部署注意事项：.env 不支持行内注释；pscp 上传需 chmod +x；运行中二进制需 .new + mv 原子替换 部署 - 生产迁到 API 9000 / TCP 9001（systemd 单元补 EnvironmentFile、nginx 同步指向） - 新增 deploy/deploy-prod.ps1（本地一键：构建→校验→备份→原子替换→重启→验收→无副作用探测） - 废弃 deploy-prod.sh / deploy-test.sh（原脚本会在 target/release 找产物、装重复 systemd 单元、 并用本地 .env 覆盖线上 .env） 质量 - 单测：api-server 39 个 / device-server 13 个（含协议示例逐值断言、跨模块 Redis key 契约） - 两服务 cargo check 零错误零告警；web tsc --noEmit 通过 - test/tcp_e2e_smoke.py 端到端联调 13/13 通过
47 lines
2.3 KiB
Markdown
47 lines
2.3 KiB
Markdown
# SQL 注入：format! 拼 SQL 的连锁风险
|
||
|
||
## 问题描述
|
||
|
||
`src/routes/charge_orders.rs` 的 `build_count_query` 和 `build_list_query` 两个辅助函数存在 SQL 注入漏洞。`battery_id` 参数通过 `format!` 直接拼入 SQL 字符串，攻击者可注入任意 SQL。
|
||
|
||
## 根因分析
|
||
|
||
**核心问题**：代码演进过程中出现了"双重 SQL 构建"模式。
|
||
|
||
1. `list_charge_orders` 主函数已经正确使用 `?` 占位符拼接了 `query` 和 `count_query`
|
||
2. 但 `build_count_query` / `build_list_query` **完全忽略**了主函数预拼接的 SQL 字符串
|
||
3. 它们自行用 `format!` 重建查询，导致所有 `format!` 拼接的参数（`cabinet_id`、`compartment_id`、`battery_id`、`status`、`LIMIT/OFFSET`）都存在注入风险
|
||
4. 两个函数还包含大量重复的分支逻辑（~100 行），不同分支的绑定顺序不一致，难以维护
|
||
|
||
**根本原因**：重构时只改了 `list_charge_orders` 主函数，没同步改造辅助函数，导致新旧模式并存。
|
||
|
||
## 解决方案
|
||
|
||
1. **删除重复逻辑**：让 `build_count_query` / `build_list_query` 直接使用主函数预拼接的 SQL 字符串
|
||
2. **统一绑定顺序**：按固定顺序（`cabinet_id → compartment_id → battery_id → status → start_time → end_time → LIMIT/OFFSET`）bind 参数，与主函数追加 `?` 占位符的顺序一致
|
||
3. **LIKE 值处理**：百分号在 bind 值中拼接（`format!("%{}%", bid)`），不进 SQL 文本
|
||
4. **消除未使用变量**：`if let Some(x)` 改为 `.is_some()`，避免未使用变量告警
|
||
|
||
## 模式/反模式
|
||
|
||
### 反模式 ❌：format! + SQL 字符串拼接
|
||
```rust
|
||
// 注入风险
|
||
query.push_str(&format!(" AND battery_id LIKE '%{}%'", bid));
|
||
```
|
||
|
||
### 模式 ✅：主函数拼占位符，辅助函数按序 bind
|
||
```rust
|
||
// 主函数：统一追加 ? 占位符
|
||
if params.battery_id.is_some() {
|
||
query.push_str(" AND battery_id LIKE ?");
|
||
}
|
||
|
||
// 辅助函数：按固定顺序 bind 值
|
||
if let Some(ref bid) = params.battery_id {
|
||
q = q.bind(format!("%{}%", bid));
|
||
}
|
||
```
|
||
|
||
### 模式 ✅：SQL 构建统一入口
|
||
所有的 SQL 构建逻辑放在一个地方（主函数），辅助函数只负责 bind 参数，不做 WHERE 条件判断。这样改了主函数就改了所有查询路径，不会出现新旧模式不一致。 |