Ecto 的片段允许 SQL 注入

Question

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

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

事实上，关于这个主题的最流行的 Stack Overflow 帖子建议创建一个这样的宏：

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

同时，在另一篇文章中，我发现了这个：

(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 部分（例如，像运算符一样简单的东西）替换参数（?infragment/1字符串），因此，您实际上没有选择。假设您想编写，fragment("column #{operator} ?", value)因为运算符是动态的并且取决于条件，只要运算符不是来自用户（在代码中的某个位置进行编码），它就是安全的。

我不知道你是否熟悉PHP（以下示例中的PDO），但这与（通过字符串插值注入值）完全一样，与then （正确的准备好的语句）$bdd->query("... WHERE column = '{$_POST['value']}'")相反。但是，如果我们回到我之前关于动态运算符的故事，如前所述，您无法动态绑定一些随机 SQL 片段，DBMS 将使用as运算符和as 值进行解释（对于这个想法），这在语法上是不正确的。因此，使该运算符动态化的最简单方法是编写（通过字符串插值或串联注入它，但仅注入它）。如果这个变量是由您自己的代码定义的（例如：），那没问题，但相反，如果它涉及一些来自客户端的超全局变量，如或，这会创建一个安全漏洞（SQL 注入）。$stmt = $bdd->prepare('... WHERE column = ?')$stmt->execute([$_POST['value']]);"WHERE column ? ?">'foo'WHERE column '>' 'foo'"WHERE column {$operator} ?"$operator$operator = some_condition ? '>' : '=';$_POST$_GET

长话短说

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

Aleksei Matiushkin 在提到的帖子中的答案只是通过fragment/1动态注入已知运算符来解决禁用/禁止字符串插值的问题。如果您重复使用这个技巧（并且确实不能这样做），只要您不盲目“注入”来自用户的任何随机值，就可以了。

更新：

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

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

至少对于 PostgreSQL/postgrex，控制台中生成的查询实际上看起来是：

SELECT ... FROM “客户” AS c0 WHERE (lastname 'LIKE' '%') []

请注意[]参数末尾的（空列表）（以及$1查询中的空列表），因此它看起来就像 PHP/PDO 中准备好的语句的模拟，这意味着 Ecto（或 postgrex？）直接实现了正确的转义和值注入在查询中，但如上所述，仍然LIKE变成了一个字符串（请参阅'周围的内容），而不是一个运算符，因此查询失败并出现语法错误。