Ecto 的片段允许 SQL 注入

Question

当 Ecto 查询变得更加复杂并且需要像 CASE...WHEN...ELSE...END 这样的子句时，我们倾向于依赖 Ecto 的 fragment 来解决它。

例如query = from t in <Model>, select: fragment("SUM(CASE WHEN status = ? THEN 1 ELSE 0 END)", 2)

事实上建议创建这样的宏：

defmacro case_when(condition, do: then_expr, else: else_expr) do
  quote do
    fragment(
      "CASE WHEN ? THEN ? ELSE ? END",
      unquote(condition),
      unquote(then_expr),
      unquote(else_expr)
    )
  end
end

因此您可以在 Ecto 查询中以这种方式使用它：

query = from t in <Model>,
  select: case_when t.status == 2
    do 1
    else 0
  end

同时，在另一个post中，我发现了这个：

(Ecto.Query.CompileError) to prevent SQL injection attacks, fragment(...) does not allow strings to be interpolated as the first argument via the `^` operator, got: `"exists (\n        SELECT 1\n        FROM #{other_table} o\n        WHERE o.column_name = ?)"

好吧，Ecto 的团队似乎发现人们正在使用 fragment 来解决复杂的查询，但他们没有意识到这会导致 SQL 注入，所以他们不允许字符串在那里插值作为一种保护开发人员的方式。

然后另一个人说“别担心，”。

我不是长生不老药专家，但这似乎是一种使用字符串插值来逃避 fragment 保护的解决方法。

有没有办法使用片段并确保查询已参数化？

Answer 1

SQL 注入，在这里，将导致字符串插值使用外部数据。想象一下 where: fragment("column = '#{value}'")（而不是正确的 where: fragment("column = ?", value)），如果 value 来自你的 params（Phoenix 动作的第二个参数的通常名称是从 HTTP 请求中提取的参数），是的，这可能会导致 SQL 注入。

但是，预处理语句的问题在于，您不能用某些动态 SQL 部分（例如，像操作员一样简单的东西）所以，你真的没有选择。假设您想写 fragment("column #{operator} ?", value) 因为 operator 是动态的并且取决于条件，只要 operator 没有出现来自用户（在您的代码中的某处进行了硬编码），这将是安全的。

不知道大家对PHP（下面例子中的PDO）熟悉不到 $stmt = $bdd->prepare('... WHERE column = ?') 然后 $stmt->execute([$_POST['value']]); （正确的准备语句）。但是，如果我们回到我之前关于动态运算符的故事，如前所述，您不能动态绑定一些随机的 SQL 片段，DBMS 会将 "WHERE column ? ?" 和 > 解释为运算符和 'foo' 作为值，如（对于想法）WHERE column '>' 'foo'，这在语法上是不正确的。因此，将此运算符动态化的最简单方法是编写 "WHERE column {$operator} ?"（通过字符串插值或连接注入它，但仅注入它）。如果此变量 $operator 由您自己的代码定义（例如：$operator = some_condition ? '>' : '=';），那很好，但相反，如果它涉及一些来自客户端的超全局变量，例如 $_POST 或$_GET，这会造成安全漏洞（SQL 注入）。

TL;DR

Then comes another guy who says "don't worry, ."

post 中提到的 Aleksei Matiushkin 的答案只是 fragment/1 对 disabled/forbidden 字符串插值的一种解决方法，可以动态注入已知运算符。如果你重复使用这个技巧（否则真的不能这样做），只要你不盲目地“注入”来自用户的任何随机值，你就没事。

更新：

毕竟，fragment/1（我没有检查源代码）似乎并不意味着准备好的语句（? 不是真正准备好的语句的占位符） .我尝试了一些简单而愚蠢的查询，如下所示：

from(
  Customer,
  where: fragment("lastname ? ?", "LIKE", "%")
)
|> Repo.all()

至少在 PostgreSQL/postgrex 中，控制台中生成的查询实际上是：

SELECT ... FROM "customers" AS c0 WHERE (lastname 'LIKE' '%') []

请注意参数末尾的 []（空列表）（并且查询中缺少 </code>），因此它看起来像 [=68 中准备好的语句的模拟=] 意思是 Ecto（或 postgrex？）直接在查询中实现正确的转义和注入值，但是，如上所述，<code>LIKE 仍然变成了一个字符串（参见它周围的 ' ), 不是运算符，因此查询因语法错误而失败。

Ecto 的片段允许 SQL 注入

Ecto's fragment allowing SQL injection

erlang

sql-injection

elixir

ecto

phoenix-framework