隐藏字符sql注入是利用空白符、注释符、url编码等非显性特征绕过waf的注入方式，本质仍是字符串拼接漏洞；防御关键在于禁用所有用户输入参与sql拼接，并强制使用参数化查询。
什么是隐藏字符SQL注入？
隐藏字符SQL注入不是指肉眼不可见的控制字符（比如\x00、\u200b），而是攻击者利用数据库对空白符、注释符、编码绕过等“非显性”特征构造的注入，例如：'%00 OR 1=1 -- 、admin'%09OR%091=1（用制表符替代空格）、email=a@b.com%23（URL 编码的#被后端解码后变成注释）。这类攻击常绕过只检测 ASCII 单引号或关键字的简单 WAF，但本质仍是字符串拼接——只要你的 SQL 是拼出来的，它就危险。
Gin 中如何检测这类输入？
不要在 Gin 中做「检测」，而要在进入 SQL 执行前就切断路径。Gin 本身不解析 SQL，它只负责收参；真正该拦截的地方是数据库驱动层或 ORM 封装层。常见错误是：在中间件里用正则匹配 args 或 body 里有没有 union、select，这既容易被绕过（比如大小写混写 UnIoN、双写 ununionion、编码 %75%6e%69%6f%6e），又会误杀合法数据（如用户名含 O'Reilly）。
- 真正有效的检测点是：所有调用
db.Query、db.Exec、db.Raw()、gorm.Session().Exec()的地方 - 如果参数来自
c.Query()、c.PostForm()、c.ShouldBindJSON()等，且最终参与了 SQL 拼接（比如"WHERE name = '" + name + "'"），那这就是风险入口 - 可加一层封装函数，强制检查 SQL 字符串是否含
+、fmt.Sprintf、strings.Replace等拼接痕迹，一旦发现直接 panic 或 log 报警
防止的关键动作只有两个
第一，禁用一切用户输入参与 SQL 字符串拼接。哪怕看起来“只是加个排序字段”，也必须白名单校验：order := c.Query("order") 不能直接拼进 ORDER BY "+order，而应：
validOrders := map[string]bool{"id": true, "created_at": true, "name": true}
if !validOrders[order] {
c.AbortWithStatusJSON(400, gin.H{"error": "invalid order field"})
return
}
db.Order(order + " DESC")
第二，所有数据库交互必须走参数化。Gin 自身不提供 SQL 安全能力，但它和 database/sql 或 GORM 配合时，要确保：
- 用
db.Query("SELECT * FROM u WHERE email = ?", email)，而不是db.Query("SELECT * FROM u WHERE email = '" + email + "'") - 用
db.Raw("SELECT * FROM users WHERE status = ?", status).Scan(&users)，而不是db.Raw("SELECT * FROM users WHERE status = '" + status + "'").Scan(&users) - GORM 中避免
Where("name = '" + name + "'")，改用Where("name = ?", name)或结构体查询Where(&User{Name: name})
为什么 Nginx 层过滤不够用？
Nginx 可以拦截 union select、' OR 1=1 这类明文模式，但它无法识别：email=a%40b.com%23（%23 解码后是 #，变成注释）、status=1%00%09OR%091=1（空字节+制表符混淆）、甚至更隐蔽的宽字节注入（如 %df%27 在 GBK 下被解析为单引号）。这些都依赖后端实际解码逻辑，Nginx 做不到语义理解。它只能当第一道粗筛，不能替代代码层的参数化。
最易被忽略的一点：Gin 的 c.GetHeader()、c.Request.URL.Query()、c.Request.Body 全都可能带恶意输入，只要它们进了 SQL 拼接链，就等于开了后门——防御不在“怎么检测”，而在“根本不让拼”。
