Beego ORM的Raw查询必须用?占位符防注入，字符串拼接会导致漏洞；ORDER BY等结构部分须白名单校验，链式QueryTable调用天然安全。
Beego ORM 的 Raw 查询必须用 ? 占位符，不能拼接字符串
Beego 的 Raw 方法本身不自动防注入——关键在你怎么用。如果你写 o.Raw("SELECT * FROM user WHERE name = '" + name + "'")，哪怕在 Beego 里也照崩不误。真正起作用的是占位符机制：? 会交由底层 MySQL 驱动做参数绑定，数据库引擎把值当纯数据处理，不会解析成 SQL 语法。
常见错误现象：手动拼接 WHERE 条件、ORDER BY 字段、IN 列表时直接插变量；结果是报错或被注入。
- 正确写法：
o.Raw("SELECT * FROM user WHERE status = ? AND age > ?", status, age).QueryRows(&users) -
IN场景不能直接传 slice，得展开为多个?：placeholders := strings.Repeat("?,", len(ids)-1) + "?"，再拼进 SQL，最后把ids...展开传参 -
ORDER BY字段名不能参数化（SQL 标准限制），必须白名单校验，比如：if !slices.Contains([]string{"name", "created_at", "score"}, sortField) { sortField = "id" }
链式查询（QueryTable）天然免疫 SQL 注入
像 qs.Filter("status", 1).OrderBy("-created_at").Limit(10) 这类调用完全不用操心注入——Beego ORM 内部全部走预编译参数绑定，字段名和值是分离的。它生成的 SQL 是确定结构的模板，用户输入只进 value 位置。
使用场景：列表页分页查询、后台管理筛选、状态批量更新等常规业务逻辑。
- 字段名（如
"status"）是硬编码或来自受控枚举，不是用户输入 - 值（如
1或"active"）会被驱动自动转义并绑定，无需手动处理 - 注意别混用：不要在
Filter里传 SQL 片段，比如Filter("name", "admin' OR '1'='1")是安全的，但若你误写成Filter("name = ? OR 1=1", "admin")就破坏了链式语义，退化为原始拼接
自定义 SQL 中的 ORDER BY 和 GROUP BY 是高危区
CVE-2022-24124（Casdoor 漏洞）就是典型例子：ORM 允许用户控制排序字段，但没做白名单过滤，导致 ORDER BY (SELECT ...) 类攻击成立。Beego 并不例外——只要最终生成的 SQL 是字符串拼接出来的，风险就存在。
性能与兼容性影响：白名单校验成本极低，但漏掉会导致 RCE 级风险；用反射或 map[string]bool 做字段映射比运行时 strings.Contains 更健壮。
- 推荐做法：定义允许排序的字段常量集，比如
var allowedSortFields = map[string]bool{"id": true, "name": true, "updated_at": true} - 大小写要统一处理，比如
strings.ToLower(input)后再查白名单，避免NAME绕过 - 绝对不要信任前端传来的
sort或order参数，即使它看起来“只是个字段名”
Beego 的安全机制是辅助项，不是免检金牌
Beego 内置的 XSS 过滤、CSRF Token、自动转义模板这些功能，跟 SQL 注入防护是正交的。它不会帮你拦截 Raw 里的恶意字符串，也不会对未走 ORM 的原生 database/sql 调用做任何干预。
容易被忽略的地方：团队里有人绕过 ORM 直接用 sql.Open 写查询；或者在 Beego 项目里混用 GORM/XORM；又或者把 Beego ORM 当“黑盒”，以为只要用了框架就万事大吉。
- 检查所有
Raw、Prepare、Exec调用点，确认参数是否全走? - 禁用生产环境的
orm.Debug = true，避免日志里泄露原始 SQL 和参数值 - 定期用
grep -r "Raw\|database/sql" ./扫描代码库，人工 review 高危调用
