charging-cabinet/docs/compound-notes/2026-08-15-sql-injection-format-param-binding.md

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 字符串拼接

// 注入风险
query.push_str(&format!(" AND battery_id LIKE '%{}%'", bid));

模式 ✅：主函数拼占位符，辅助函数按序 bind

// 主函数：统一追加 ? 占位符
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 条件判断。这样改了主函数就改了所有查询路径，不会出现新旧模式不一致。