如何解决移动端App接口中因Token参数未校验引发的SQL注入

Token未校验本身不直接导致SQL注入，真正漏洞在于绕过鉴权后将恶意参数拼接到SQL中；根治方法是禁用字符串拼接，强制使用参数化查询，并辅以网关层初筛与严格验证。

Token 参数未校验本身不会直接导致 SQL 注入——它只是身份凭证，不是 SQL 构建的输入源。真正的问题是：攻击者利用未校验的 Token 绕过鉴权后，把恶意参数（如 user_id、keyword）送进后端，而这些参数又被拼接到 SQL 中执行。

所以修复重点不在 Token 本身，而在「未校验 Token → 放行非法请求 → 后端拼接参数 → 执行恶意 SQL」这条链路上。必须切断最脆弱的一环：SQL 拼接。

为什么只校验 Token 无法防 SQL 注入

哪怕 Token 是合法且未过期的，只要后端代码存在 "WHERE id = '" + userId + "'" 这类拼接，攻击者仍可构造 userId=1' OR '1'='1 突破数据库逻辑。鉴权只解决“谁在调用”，不解决“传了什么”。

必须禁用所有字符串拼接构造 SQL 的写法

这是唯一能根除漏洞的手段。无论 Token 是否校验、是否有效，只要 SQL 构建层用了参数化查询，恶意输入就永远只是数据，不会变成代码。

• Java：强制用 PreparedStatement，占位符统一为 ?，调用 setString() / setLong()；绝不用 String.format() 或 + 拼接
• Python（MySQL/PostgreSQL）：用 cursor.execute("SELECT * FROM t WHERE id = %s", [user_id])；SQLite 用 ? 占位符；严禁 f"WHERE name = '{name}'"
• Node.js（pg）：用 client.query("SELECT * FROM u WHERE id = $1", [id])；mysql2 同理用 query(sql, [params])，而非模板字符串
• MyBatis：确认只用 #{}（参数化），禁用 ${}（字符串拼接）；检查所有 <script> 标签和动态 SQL 是否引入变量

网关层对 Token 的校验要绑定业务参数初筛

网关不能替后端防注入，但可以配合 Token 鉴权做轻量级兜底，防止明显畸形请求触达后端：

• Token 校验必须包含时效性：timestamp 参数需存在且与当前时间差 ≤ 300000ms（5 分钟），超时即拒
• 必须校验 nonce 去重：长度 ≥ 8，且 Redis 缓存最近 5 分钟内已见 nonce，重复即拒
• 对已通过 Token 验证的请求，额外对高危字段做初筛：user_id 用正则 ^[0-9]+$、out_trade_no 用 ^[a-zA-Z0-9_-]{8,64}$、keyword 限制长度 ≤ 200
• 拒绝含 %00、连续 %%、未闭合 %2 的 URL 编码，这些不是正常客户端行为

修复后必须验证是否真生效

别信“加了 Token 校验就安全了”。上线前务必用真实 payload 测试：

• 发送 GET /api/order?order_id=123%27%20UNION%20SELECT%20password%20FROM%20users--，观察是否返回 400 或 500，而不是订单数据
• 用 sqlmap -u "https://api.example.com/order?order_id=123" --batch 扫描，确认无注入点
• 检查日志：若某次请求 Token 有效但参数含 ' OR '1'='1，应记录原始参数并告警——说明密钥可能泄露或客户端被劫持

真正危险的不是没校验 Token，而是校验了 Token 就以为万事大吉，继续在 DAO 层写 String sql = "SELECT * FROM user WHERE id = " + id;。这种代码，再强的网关也拦不住。