游乐游手机版
首页/数据库/文章详情

移动端App接口Token未校验导致SQL注入的解决方案

时间：2026-07-11 07:01
先纠正一个常见误解：Token未校验本身并不会直接导致SQL注入——它只是一个身份凭证，不是SQL的输入源。真正的问题出在另外一条链路上：攻击者利用未校验的Token轻松绕过鉴权，然后塞进恶意参数（比如 user_id、keyword），这些参数再被拼接到SQL中执行，这才是灾难的开端。 所以修复的

先纠正一个常见误解：Token未校验本身并不会直接导致SQL注入——它只是一个身份凭证，不是SQL的输入源。真正的问题出在另外一条链路上：攻击者利用未校验的Token轻松绕过鉴权，然后塞进恶意参数（比如 user_id、keyword），这些参数再被拼接到SQL中执行，这才是灾难的开端。

如何解决移动端App接口中由于Token参数未校验导致的SQL注入？

所以修复的重点从来不是Token本身，而是整条攻击链上最脆弱的一环：SQL拼接。鉴权只能解决“谁在调用”，解决不了“传了什么参数”。下面我们展开来说。

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

举个最简单的例子：即使Token合法且未过期，只要后端代码里写着 "WHERE id = '" + userId + "'" 这种拼接，攻击者照样可以构造 userId=1' OR '1'='1 来突破数据库防护。这就好比，门禁卡没问题，但进门后直接把危险物品搬进了保险库。鉴权只是第一道门，SQL层才是真正的防线。

根治措施：禁用所有字符串拼接构造SQL的写法

这是唯一能根除漏洞的手段。无论Token校验得有多严、有效期有多短，只要SQL构建层强制使用了参数化查询，恶意输入就永远只是数据，永远不会变成可执行的代码。具体到不同技术栈：

  • Ja va：强制用 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：确认只使用 #{}（参数化），禁用 ${}（字符串拼接）。检查所有