为何小程序也存在SQL注入

小程序（微信/支付宝等）前端看起来是“封闭环境”，但实际上它和传统的 Web 应用一样，最终都要和后端服务、数据库交互，所以SQL 注入的本质并没有消失，只是攻击面发生了变化。

下面从原理到原因系统说明。

一、SQL 注入的本质没变

SQL 注入的本质：用户输入被当作 SQL 代码执行

只要满足以下三点，就可能存在 SQL 注入：

1. 有用户输入（小程序中的表单、URL 参数、header、二维码参数等）
2. 后端直接拼接 SQL
3. 未做参数化处理或校验

小程序只是“前端壳”，真正危险的是后端接口。

二、小程序为什么也会中招？

1️⃣ 小程序 ≠ 安全沙箱

很多人误以为：

小程序在微信里运行，用户碰不到代码，所以安全

❌ 错误。

小程序：

• 所有请求都走 HTTPS 接口
• 接口可被 抓包、重放、伪造
• 参数完全可控

攻击者根本不需要进小程序，只需：

POST /api/user/list
{
  "id": "1 OR 1=1"
}

2️⃣ 后端仍是传统 Web 服务

小程序后端常见技术：

• Java / Spring
• Node.js / Express
• PHP
• Python / Django

这些语言和框架本身不防 SQL 注入，防的是“你怎么写代码”。

❌ 错误示例：

String sql = "SELECT * FROM user WHERE id = " + id;

✅ 正确示例：

PreparedStatement ps = conn.prepareStatement(
  "SELECT * FROM user WHERE id = ?"
);
ps.setInt(1, id);

3️⃣ 开发者误以为“前端校验就够了”

常见误区：

• 小程序里限制了输入格式
• 以为用户改不了

但实际上：

• 前端校验可绕过
• 接口直接调用即可

4️⃣ 参数来源比你想的多

容易被忽略的注入点：

• 搜索关键词
• 排序字段 order by
• 分页参数
• token / openid（错误信任）
• 二维码携带参数
• 分享参数

例如：

ORDER BY ${column}

即使值是字符串，也可能被注入。

5️⃣ ORM 用错也会注入

很多人以为：

用了 MyBatis / Hibernate 就安全

❌ 错误用法照样注入：

MyBatis：

ORDER BY ${sort}

正确应：

ORDER BY #{sort}

（或白名单控制）

三、小程序 SQL 注入典型案例

案例 1：登录接口

SELECT * FROM user WHERE username = 'xxx' AND password = 'xxx'

用户名输入：

admin' --

案例 2：搜索接口

SELECT * FROM goods WHERE name LIKE '%关键词%'

关键词：

%' UNION SELECT password FROM admin -- 

案例 3：ID 参数

?id=1 OR 1=1

四、为什么小程序更容易被忽视？

五、正确防护方式（重点）

✅ 永远使用 参数化查询
✅ 使用 ORM 正确写法
✅ 对排序/字段使用 白名单
✅ 后端做 输入校验
✅ 最小权限数据库账号
✅ 定期安全测试（含小程序接口）

六、一句话总结

小程序不会天然防 SQL 注入，真正决定安全的，是后端怎么写 SQL。

如果你愿意，我可以：

• 帮你审计一段小程序后端代码
• 给你一个「小程序接口安全 Checklist」
• 用真实抓包演示一次注入过程（教学用途）

你想看哪一个？