17370845950

根本原因是参数化查询将用户输入与SQL结构分离，由驱动自动转义和类型绑定；错误写法直接拼接输入导致注入，正确做法是用?或$1占位符配合Query/Exec，且表名等结构部分须白名单校验。

用 database/sql 的参数化查询代替字符串拼接

SQL注入的根本原因是把用户输入直接拼进 SQL 字符串里。Golang 的 database/sql 包原生支持参数化查询，只要坚持用 ?（MySQL/SQLite）或 $1（PostgreSQL）占位符 + Query/Exec 的变参形式，就能让驱动自动转义和类型绑定。

错误写法（绝对禁止）：

username := r.URL.Query().Get("user")
query := "SELECT * FROM users WHERE name = '" + username + "'"
rows, _ := db.Query(query) // 危险！输入 'admin' OR 1=1 -- 会逃逸

正确写法（必须）：

username := r.URL.Query().Get("user")
rows, err := db.Query("SELECT * FROM users WHERE name = ?", username)
if err != nil {
    http.Error(w, "DB error", http.StatusInternalServerError)
    return
}

• 所有用户可控输入（r.FormValue、r.URL.Query().Get、json.Unmarshal 解析的字段等）都必须走参数化路径
• 不要试图自己写“过滤函数”去 strip 单引号或转义——这不可靠，且容易漏掉边界情况（如宽字节、编码绕过）
• 注意：占位符不能用于表名、列名、ORDER BY 子句等结构部分；这些需通过白名单校验 + 映射方式控制

避免使用 fmt.Sprintf 或 strings.Replace 构造查询语句

有人会想：“我用 fmt.Sprintf 拼接，再手动加引号和转义”，这是典型误区。Go 的字符串拼接无法阻止恶意输入破坏语法结构，且不同数据库转义规则不一致（如 PostgreSQL 的 $$ 块、MySQL 的反斜杠处理），手动模拟极易出错。

常见错误模式：

// ❌ 错误：看似加了单引号，但 username 可为 'admin' -- '
query := fmt.Sprintf("SELECT * FROM users WHERE name = '%s'", username)
// ❌ 更危险：用 Replace 尝试“过滤”
username = strings.Replace(username, "'", "''", -1) // 仅对某些 DB 有效，且可被编码绕过

• 任何含用户输入的 SQL 片段，只要出现在 Query / Exec 的第一个参数中，就必须是纯静态字符串
• 动态列名或条件逻辑，应拆成代码分支，例如：if field == "name" { query = "SELECT * FROM users ORDER BY name" }，并限制 field 只能是预设的几个值
• ORM（如 GORM）也需确认是否启用参数化；GORM v2 默认开启，但若用 Session(&gorm.Session{DryRun: true}) 或原始 SQL 模式，仍可能绕过

使用 sql.Named 处理命名参数（尤其 PostgreSQL）

PostgreSQL 驱动（lib/pq 或 pgx）不支持 ? 占位符，而用 $1, $2 等位置参数。若逻辑复杂、参数多，易错序。此时可用 sql.Named 配合命名参数风格，提升可读性和安全性。

stmt := `SELECT * FROM users WHERE status = $1 AND created_at > $2`
rows, _ := db.Query(stmt, "active", time.Now().AddDate(0, 0, -7))
// 更清晰的方式（需驱动支持命名参数，如 pgx）
stmtNamed := SELECT * FROM use
rs WHERE status = :status AND created_at > :since
rows, _ := db.NamedQuery(stmtNamed, map[string]interface{}{
"status": "active",
"since":  time.Now().AddDate(0, 0, -7),
})

• sql.Named 是标准库提供的兼容机制，但底层是否生效取决于 driver 实现；pgx 支持完整命名参数，lib/pq 仅支持位置参数
• 命名参数不会降低安全性，但能减少参数顺序错乱导致的隐性 bug（比如把时间戳传给 status 字段）
• 不要因用了命名参数就放松对输入值的校验——它只解决拼接问题，不替代业务层合法性检查（如邮箱格式、ID 是否为数字）

警惕 ORM 的原始 SQL 和钩子方法

用 GORM 或 sqlx 并不自动免疫 SQL 注入。当调用 Raw()、Exec() 原始 SQL 方法，或在 BeforeCreate 等钩子中拼接 SQL 时，风险重现。

示例（GORM 中的陷阱）：

// ❌ 危险：Raw() 内直接插值
db.Raw("SELECT * FROM users WHERE name = '" + name + "'").Find(&users)
// ✅ 安全：Raw() 也支持参数化
db.Raw("SELECT * FROM users WHERE name = ?", name).Find(&users)
// ❌ 钩子中拼接
func (u User) BeforeCreate(tx gorm.DB) error {
tx.Exec("INSERT INTO logs (msg) VALUES ('created user " + u.Name + "')") // 漏洞点
return nil
}

• GORM 的 Raw、Session、Transaction 内部执行原始 SQL 时，同样必须用参数化
• 自定义钩子、中间件、审计日志记录等场景，凡涉及 SQL 构造，一律回归“静态 SQL 字符串 + 参数列表”原则
• 上线前用模糊测试工具（如 sqlmap -u "http://x/?id=1"）扫描关键接口，验证是否真无注入面

实际中最容易被忽略的是：表名和排序字段这类“元信息”输入，既不能参数化，又常被当成普通参数放行。它们必须走严格白名单，比如 map[string]bool{"name": true, "email": true, "created_at": true}，而不是简单做正则匹配。