【SQL注入】关于GORM的SQL注入问题
我们知道，一旦涉及字符串拼接，就很可能产生 SQL 注入问题。然而，有同学会疑惑：GORM 框架不是会帮忙预检测吗？为了弄清楚这一点，我们通过两个例子来详细探讨。
2. 例子
示例 1：字符串拼接的方式
如果在查询条件后拼接上一个 OR 1=1，会发生什么？
id := "031904102" + " OR 1=1"
where := "stu_number=" + id
err := DB.Model(&User{}).Where(where).Find(&user).Error
if err != nil {
fmt.Println(err)
}
这里通过字符串拼接形成查询条件。在执行后，查询的 SQL 实际变成了：
SELECT * FROM `user` WHERE stu_number=031904102 OR 1=1;
结果是，SQL 注入发生了。虽然原本只想查询 stu_number=031904102 的用户数据，但由于 OR 1=1，最终查询出所有记录。显然，这是不安全的写法。
示例 2：使用占位符防止 SQL 注入
id := "031904102" + " OR 1=1"
user2 := []User{}
err = DB.Model(&User{}).Where("stu_number=?", id).Find(&user2).Error
if err != nil {
fmt.Println(err)
}
在这个例子中，使用了占位符 ?，并通过参数传递用户输入，查询生成的 SQL 如下：
SELECT * FROM `user` WHERE stu_number=?;
这里占位符限制了输入，使得注入失效。即便用户输入了 OR 1=1，最终的查询依然安全，不会查出额外的数据。
注入多条 SQL 语句的情况
假设用户尝试注入两条 SQL 语句，比如：
SELECT * FROM `user` WHERE stu_number=031904102; DROP TABLE notice;
虽然这在原始 SQL 中可以执行，但在 GORM 框架下无法执行。GORM 不允许同时执行多条 SQL 语句，因此 DROP TABLE 的注入不会成功。GORM 在遇到 ; 分号时会终止执行，避免了批量操作的风险。
3. 总结
为了避免 SQL 注入，建议：
- 避免使用字符串拼接 来进行 SQL 查询。将用户输入的数据作为参数传递，而不是直接拼接到 SQL 中。
- 使用参数化查询或预编译语句，这是最安全的方式，且大多数框架都支持。
- 使用成熟的框架 并参考官方文档的最佳实践，站在巨人的肩膀上，减少不必要的风险。
通过这些措施，你可以有效防止 SQL 注入，保证数据库的安全性。