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.<code>?>> 占位符写原生条件才真正防注入
Sequel 支持两种安全的动态条件构造方式：?（位置占位符）和 :name（命名占位符）。它们必须配合 Sequel.<code>?>> 或 Sequel.<code>named 等 DSL 函数使用，不能手写 "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>关键点：
-
Sequel.<code>?返回一个可被where识别的表达式对象，不是普通字符串 - 命名占位符必须用
Sequel.<code>named包裹，否则where(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>正确做法：
- 所有用户输入必须通过第二参数传入，且类型为
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)
为什么 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 查询或动态字段构造处松懈——那里才是漏洞温床。
