Sequel的where/filter不防注入,因哈希键、SQL片段等用户输入若未白名单校验或未用Sequel.?/named构造,将退化为字符串拼接;仅?占位符和命名参数配合显式传参才安全。

Sequel 的 where 和 filter 为什么不能直接拼接用户输入
Sequel 的链式查询(如 DB[:users].where(name: params[:name]))本身是安全的,但仅限于键名固定、值可控的场景。一旦你把用户控制的字段名或操作符塞进哈希键,比如 DB[:users].where("#{params[:field]} = ?": params[:value]),整个表达式就退化为字符串拼接——where 方法此时已不介入参数绑定,SQL 引擎直接执行拼好的语句。
常见错误现象包括:
- 页面返回空数据或 500 错误,但日志里出现
PG::SyntaxError或SQLite3::SQLException - 传入
field=id__gt时意外触发WHERE id > ?,绕过业务逻辑 - 传入
field=created_at; DROP TABLE users--导致语法破坏甚至删表
根本原因:Sequel 只对明确标记为“绑定值”的位置做参数化,而哈希键、SQL 片段字符串、Dataset#select 中的任意字符串,都不受保护。
用 Sequel.?>> 占位符写原生条件才真正防注入
?>> 占位符写原生条件才真正防注入Sequel 支持两种安全的动态条件构造方式:?(位置占位符)和 :name(命名占位符)。它们必须配合 Sequel. 或 ?>>Sequel. 等 DSL 函数使用,不能手写 named"WHERE name = ?" 后再自己 .gsub 替换。
正确写法示例:
field = params[:field] || "id"
value = params[:value]
<h1>✅ 白名单校验字段名后,用 Sequel.? 构造条件</h1><p>allowed_fields = %w[id name email status]
if allowed_fields.include?(field)
condition = Sequel.<code>?</code>("#{field} = ?", value)
users = DB[:users].where(condition)
end</p><h1>✅ 命名占位符 + Hash 参数(注意:必须用 Sequel.<code>named</code>)</h1><p>condition = Sequel.<code>named</code>(":field = :value", field: field, value: value)</p><h1>❌ 错误:这样写会把 :field 当字面量,不是变量替换</h1><h1>DB[:users].where(":field = :value", field: field, value: value)</h1><p></p>
关键点:
-
Sequel.返回一个可被?where识别的表达式对象,不是普通字符串 - 命名占位符必须用
Sequel.包裹,否则namedwhere(hash)会忽略它 - 不要在占位符外拼接用户输入,比如
"#{field} = ?"是安全的,但"#{field} #{op} ?"中的op必须也走白名单
绕过 ORM 的 raw 和 execute 怎么写才不翻车
Sequel 提供 DB.run 和 DB.fetch 执行原始 SQL,这常用于复杂聚合或数据库特有函数。但这类调用默认不做任何参数绑定——你传什么,它就发什么。
危险写法:
# ❌ 字符串插值,高危
DB.fetch("SELECT * FROM users WHERE name = '#{params[:name]}'")
<h1>❌ 占位符写错位置,无效</h1><p>DB.fetch("SELECT * FROM users WHERE name = ?", params[:name])</p><h1>→ 这行看似用了 ?,但 Sequel 不会自动绑定;必须显式传参数组</h1><p></p>
正确做法:
- 所有用户输入必须通过第二参数传入,且类型为
Array(位置)或Hash(命名) - 位置占位符用
?,命名占位符用:name,不能混用 - SQL 字符串必须是静态的,不可含
#{}插值
示例:
# ✅ 位置参数
DB.fetch("SELECT * FROM users WHERE status = ? AND created_at > ?", "active", Time.now - 7.days)
<h1>✅ 命名参数(需确保 SQL 中是 :status 而非 ?)</h1><p>DB.fetch("SELECT * FROM users WHERE status = :status AND created_at > :since",
status: "active", since: Time.now - 7.days)
</p>
为什么 Sequel.migration 文件里不用防注入
迁移文件(db/migrate/*.rb)中的 SQL 操作(如 create_table、add_column)运行在部署阶段,由运维或 CI 控制,输入源是代码仓库而非 HTTP 请求。这些方法内部使用的是数据库适配器的 DDL 接口,不接受运行时参数,也不拼接用户数据。
所以你不会在迁移里看到 where 或 ?,也不需要加白名单校验——它们天然免疫 SQL 注入。
但要注意一个边界情况:
- 如果在迁移中调用
DB.run("UPDATE ...")并插入环境变量(如ENV["SEED_USER"]),而该变量来自外部配置,就得当心——此时仍需按原生 SQL 规则处理参数 - 迁移文件本身不应读取
params、request或任何 Web 层输入
真正容易被忽略的点是:开发者常把“ORM 安全”误解为“所有 Sequel 相关代码都安全”,结果在 raw 查询或动态字段构造处松懈——那里才是漏洞温床。











