防止 Go Postgresql 中的 SQL 注入

IT行业相对于一般传统行业，发展更新速度更快，一旦停止了学习，很快就会被行业所淘汰。所以我们需要踏踏实实的不断学习，精进自己的技术，尤其是初学者。今天golang学习网给大家整理了《防止 Go Postgresql 中的 SQL 注入》，聊聊，我们一起来看看吧！

我在Go中的postgresql注入论坛上进行了研究，发现了一些关于SQL注入的有用信息，如下所示：

如何使用 Golang 在 SQL 中执行 IN 查找？

在 Go 中使用“database/sql”时如何防止 SQL 注入攻击？

但我仍然需要一些建议，因为我的 Go 代码使用了不同类型的代码和用例。 我需要建议的一些用例/问题是这样的

1. 使用查询循环进行多次插入，例如 使用 fmt.SprintfINSERT INTO a (a1,a2,a3) VALUES (%d,%d,%s)，我知道使用 sprinft 不好。那么这个插入循环查询有什么解决方案吗？ 例如：INSERT INTO a (a1,a2,a3) VALUES (%d,%d,%s),(%d,%d,%s),(%d,%d,%s)
2. 如果参数使用 %d 而不是 %s ，使用 fmt.Sprintf 生成查询是否安全？
3. 使用Prepare语句和Query是安全的，但是如果我使用函数Select（使用$1，$2）和函数NamedQuery（使用结构体named）会怎么样？ 例如： Select * from a where text = $1 -> 使用此 $1 安全吗？ 和 例如： Select * from a where text = :text -> 在 NamedQuery 函数中安全吗？

恳请大家的建议。谢谢！

解决方案

首先，通常更喜欢使用 db 占位符？ 1 美元等

1. 是的，使用带有整数参数的 fmt.Sprintf 来构建 SQL 是安全的，尽管如果可以的话值得避免，但你的第三个参数是 %s - 避免使用并使用？
2. 是的，使用带有整数参数的 fmt.Sprintf 是安全的，但 %s 或 %v 的风险要大得多，我会避免，不明白为什么你需要它。
3. 在此处使用占位符，那么是安全的。

一般规则：

• 默认使用占位符，很少使用 %d（例如在 IN 查询中）
• 在验证或使用之前将参数解析为整数等类型
• 如果可以的话，避免字符串连接，并且要特别警惕字符串参数
• 始终对列名和表名等内容进行硬编码，切勿根据用户输入生成它们（例如？sort=mystringcolname）
• 始终验证您获取的参数是否仅为该用户授权的参数

理论要掌握，实操不能落！以上关于《防止 Go Postgresql 中的 SQL 注入》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！