在Elixir的Ecto库中，使用fragment函数直接拼接SQL字符串是导致SQL注入漏洞的主要风险点。很多开发者误以为Ecto的查询构建器完全免疫注入，但当你将用户输入或动态数据通过字符串插值传入fragment时，例如fragment("WHERE name = '#{user_input}'")，恶意输入如' OR '1'='1就会被直接执行。正确的防护方法是严格使用参数化查询，通过占位符和绑定值来传递动态数据，确保数据始终被当作字面值处理，而非可执行代码。

理解Ecto中fragment的作用与风险

Ecto的fragment函数允许你在查询中嵌入原生SQL片段，这对于复杂查询或数据库特定功能非常有用。然而，它的设计初衷是处理静态SQL字符串，当你需要动态内容时，直接拼接就打开了安全漏洞。例如，一个常见的错误做法是：

query = from u in User, where: fragment("email = ? AND status = '#{status}'", email)

这里虽然email使用了参数化占位符?，但status却通过字符串插值拼接，攻击者可以控制status变量来注入额外SQL命令。关键在于区分：fragment中的?占位符是安全的，但#{}插值绝对危险。

防止注入的核心：参数化查询与绑定值

Ecto提供了两种安全使用动态数据的方式。第一种是使用占位符?和bindings，例如：

fragment("WHERE created_at > ? AND status = ?", start_date, "active")

Ecto会将start_date和"active"作为参数传递给数据库驱动，进行转义处理。第二种是使用Ecto查询表达式结合fragment，比如：

from p in Post, where: fragment("title ILIKE ?", ^search_term)

这里^操作符将search_term作为绑定值传入，而不是拼接。记住规则：所有用户输入、变量或外部数据都必须通过占位符或pin操作符(^)传递，永远不要出现在SQL字符串内部。

安全动态SQL构建的最佳实践

对于更复杂的动态查询，比如可选的过滤条件，推荐使用Ecto的查询构建器组合，而非手动拼接SQL。例如，构建一个多条件搜索：

def filter_posts(params) do
  query = from p in Post
  query = if params[:author], do: where(query, [p], p.author_id == ^params[:author]), else: query
  query = if params[:category], do: where(query, [p], fragment("category_path LIKE ?", ^"#{params[:category]}%")), else: query
  query
end

这种方法保持fragment内仅使用占位符。如果必须动态生成SQL片段（如表名或列名），应使用白名单验证：

allowed_columns = ~w(title created_at status)
column = if params[:sort] in allowed_columns, do: params[:sort], else: "id"
fragment("ORDER BY ?", ^column)

注意：即使使用占位符，表名或列名也可能不被所有数据库支持，此时白名单是唯一安全选择。

常见错误场景与排查清单

开发者常在不经意间引入漏洞。错误一：在fragment内拼接多个条件——

fragment("status = '#{status}' AND priority = #{priority}")

这里status和priority都暴露了，数字类型priority同样危险，因为注入不需要引号。错误二：误用字符串函数——

fragment("LOWER(name) = '#{String.downcase(name)}'")

看似处理了数据，但拼接本质不变。正确做法是：

fragment("LOWER(name) = ?", ^String.downcase(name))

错误三：忽略JSON或数组字段查询——某些数据库扩展需要特殊语法，但原则不变，使用数据库驱动提供的参数化方法。

利用Ecto的底层机制增强安全

Ecto的查询编译过程会将占位符转换为数据库参数化查询。例如，当执行

Repo.all(from u in User, where: fragment("email = ?", ^email))

时，Ecto生成类似SELECT * FROM users WHERE email = $1的查询，email值通过单独通道传输。你可以通过日志验证：安全查询会显示参数列表如["user@example.com"]，而拼接的查询则直接显示完整字符串。建议在代码审查中检查所有fragment调用，确保没有#{}出现，并利用静态分析工具如Credo进行扫描。

高级场景：复杂表达式与数据库特定功能

当使用数据库特有函数如PostgreSQL的JSON操作时，仍需保持警惕。不安全方式：

fragment("metadata->>'tags' LIKE '%#{tag}%'")

安全方式：

fragment("metadata->>'tags' LIKE ?", ^"%#{tag}%")

注意，这里模式匹配值%#{tag}%作为整体参数传入。对于动态操作符，可结合case语句：

operator = if params[:exact], do: "=", else: "ILIKE"
value = if params[:exact], do: ^params[:term], else: ^"%#{params[:term]}%"
fragment("title #{operator} ?", value)

操作符本身通过白名单控制（仅限=或ILIKE），值仍参数化。

总结：将安全作为默认习惯

防止SQL注入在Ecto中不是技术难题，而是意识问题。始终假设所有输入都是恶意的，即使来自内部系统。总结关键规则：第一，禁止在fragment字符串内使用#{}插值；第二，所有动态数据使用?占位符和^绑定；第三，动态SQL关键字（如ORDER BY列）用白名单限制；第四，优先使用Ecto查询表达式，fragment作为最后手段。通过将参数化查询设为团队规范，并定期审计代码，你可以充分利用Ecto的安全性，而不牺牲灵活性。