Golang防SQL注入方法与技巧

在Go语言开发中，防范SQL注入的核心原则是：所有用户输入的值必须通过参数化查询（如?或$1占位符）严格隔离，绝不能拼接字符串；而SQL结构部分（如ORDER BY字段、表名、列名等）则必须采用白名单机制校验后方可动态拼接，二者缺一不可——参数化保“值”的安全，白名单保“结构”的可控，任何绕过这两者的做法（如手动转义、字符串替换、依赖ORM自动防护）都形同虚设，极易被Unicode编码、驱动差异或注释符等手段绕过，最终导致数据库完全失守。

Go 里防 SQL 注入，**唯一靠谱的方式就是参数化查询**——不是“尽量用”，是“必须用”，而且得用对地方。拼字符串、转义单引号、删分号，全都没用；ORM 也不能自动兜底，尤其你写原生 SQL 的时候。

db.Query / db.Exec 必须带占位符，不能拼字符串

用户输入一旦进 SQL 字符串，就等于把数据库的控制权交出去了。哪怕只是 WHERE status = 'active'，只要这个 active 来自 URL 参数或表单，就必须走参数化。

• ✅ 正确：db.Query("SELECT * FROM users WHERE email = ? AND deleted = ?", email, false)（MySQL/SQLite）
• ✅ 正确：db.Query("SELECT * FROM users WHERE email = $1 AND deleted = $2", email, false)（PostgreSQL）
• ❌ 危险：db.Query("SELECT * FROM users WHERE email = '" + email + "'")
• ❌ 更危险：fmt.Sprintf("SELECT * FROM users WHERE email = '%s'", email) —— 看似加了引号，但 email 是 "admin' -- " 就直接注释掉后面逻辑

database/sql 不解析 SQL，只原样发给驱动。你拼出来的字符串，数据库就照单全收。

ORDER BY / LIMIT / 表名 / 列名不能用 ? 或 $1

SQL 标准规定：这些属于查询“结构”，不是“值”，参数化机制根本不支持绑定。试图 db.Query("ORDER BY ?", "name") 会直接 panic：sql: expected 0 arguments, got 1。

• 必须用白名单校验后拼接，比如排序字段只允许 "name"、"created_at"、"id"
• 方向只允许 "ASC" 或 "DESC"，且要 strings.ToUpper() 统一后比对
• 表名同理：isValidTable := map[string]bool{"users": true, "orders": true}，不在里面就拒掉
• 别信“我用 strings.Replace(email, "'", "''", -1) 就安全了”——绕过方式太多，Unicode、多字节编码、驱动差异都能打穿

Scan 时类型和顺序错位，不是注入，但一样致命

Scan 不查字段名，只按 SELECT 后的列位置和类型硬匹配。表结构一变，代码没同步，轻则数据错位，重则 panic：sql: Scan error on column index 2: unsupported Scan, storing driver.Value type into type *string。

• ✅ 用具名变量：err := row.Scan(&u.ID, &u.Name, &u.Email)
• ✅ 遇到可能为 NULL 的字段，必须用 sql.NullString、sql.NullInt64 等类型接收
• ❌ 别堆匿名变量：row.Scan(&id, &name, &email) —— 人眼难对齐，改表后极易漏
• ❌ 用普通 string 接 NULL 值，运行时报错，服务可能挂掉

最常被忽略的一点：白名单不是“加个 if 判断”就完事，它得覆盖所有动态拼接的结构部分——包括 JOIN 的表名、GROUP BY 的字段、甚至 WITH 子句里的 CTE 名。而参数化只保值，不保结构。这两块不分开管，防注入就是纸上谈兵。

以上就是《Golang防SQL注入方法与技巧》的详细内容，更多关于的资料请关注golang学习网公众号！