GORM的Where等方法默认安全，因其强制参数化查询，SQL结构与用户数据严格分离；而Raw直接执行字符串，若拼接用户输入（如db.Raw("WHERE name = '"+name+"'")）则完全暴露SQL注入风险，必须用占位符或白名单校验动态部分。

为什么 GORM 的 Where 默认安全，但 Raw 一用就出事？

GORM 里的 Where、First、Find 这类方法，默认采用的就是参数化查询。说白了，SQL 的结构是一回事，用户传入的数据是另一回事，两者天然隔开。数据库会先把 SELECT * FROM users WHERE email = 这样的语句模板编译好，然后再把 email 的具体值作为普通参数塞进去。也正因为如此，不管传入的是 ' OR 1=1 --，还是 ; DROP TABLE users;，最终都只会被当成字符串处理，而不会被数据库识别成真正的 SQL 指令。

Raw 恰好是另一种处理方式：它会把字符串原封不动交给数据库执行。比如写成 db.Raw("SELECT * FROM users WHERE email = '" + email + "'")，程序会先在 Go 里把字符串拼好，然后再交给数据库。问题也就出在这里——一旦输入里带着单引号、分号，甚至注释符，这些内容都会被当作 SQL 语句的一部分参与解析。

• 安全写法：db.Raw("SELECT * FROM users WHERE email = AND status = ", email, status)
• 危险写法：db.Raw("SELECT * FROM users WHERE email = '" + email + "'")
• 注意： 占位符只在 Raw 中起作用，不能混用 $1（PostgreSQL）或 :name（SQLite），GORM 会按驱动自动适配，别手动改

哪些地方最容易偷偷拼接 SQL？

不是只有 Raw 才危险。任何把用户输入直接塞进字符串的地方，都可能成为注入入口：

• 动态表名或字段名：GORM 不支持参数化表名，db.Table("users_" + tenantID).Where(...) 是高危操作
• ORDER BY / GROUP BY 动态字段：db.Order("created_at " + sortDir) —— sortDir 若来自 query 参数且未校验，可注入 ASC; DROP TABLE logs; --
• JSON 查询（MySQL 5.7+）：db.Where("data->'$.name' = ", name) 安全；但 db.Where("data->'" + path + "' = ", value) 就不安全
• 第三方库封装的“便捷查询”函数，如果内部用了 fmt.Sprintf 拼 SQL，也要查源码确认

光靠 ORM 就能高枕无忧？

不能。GORM 安全是默认行为，但可以被绕过：

• 显式关闭预处理：db.Session(&gorm.Session{PrepareStmt: false}) 会让所有查询退回到字符串拼接模式
• 使用 Scan 配合 Rows 时，如果自己调 rows.Scan 之前没做参数化，仍可能暴露
• 数据库账号权限过大：即使注入成功，若连接用户只有 SELECT 权限，最多读数据；但若拥有 DROP、CREATE，后果严重
• 日志泄露：开启 GORM 日志后，Raw 的完整 SQL 可能打到 stdout，含敏感参数，需过滤或关掉生产日志

实际开发中必须加的三道检查

防御不是靠某一个函数，而是贯穿整个数据流：

• 所有来自 c.Query、c.PostForm、c.Param 的值，在进 SQL 前必须过白名单校验：比如 ID 只允许数字，邮箱用 mail.ParseAddress 或正则 ^[a-z0-9._%+-]+@[a-z0-9.-]+.[a-z]{2,}$
• 动态 SQL 片段（如排序字段）必须硬编码映射：map[string]string{"created_at": "created_at", "title": "title"}，拒绝任何不在列表里的输入
• 数据库连接配置里明确限制权限：GRANT SELECT, INSERT, UPDATE ON mydb.* TO 'app_user'@'%';，不给 DROP、ALTER、CREATE

最常被忽略的是动态字段和权限控制——它们不出现在 ORM 文档里，却恰恰是线上事故的高频源头。

《夸克》非常好用的免费AI浏览器

下载APP查看