Question

我正在构建一个像这样的Ecto查询：

from item in query,
where:  like(item.description, ^"%#{text}%")

我担心这允许text中的SQL注入。在尝试修复之前，我想看看查询是如何实际发送到数据库的。

如果我inspect the query或查看记录的内容，我会看到一些SQL，但它无效。

例如，检查查询会向我显示：

{"SELECT i0.\"id\", i0.\"store_id\", i0.\"title\", i0.\"description\" 
  FROM \"items\" AS i0 WHERE (i0.\"description\" LIKE $1)",
 ["%foo%"]}

当我将此查询传递给Repo.all时，会记录下来：

SELECT i0."id", i0."store_id", i0."title", i0."description"
  FROM "items" AS i0 WHERE (i0."description" LIKE $1) ["%foo%"]

但如果我将其复制并粘贴到psql中，PostgreSQL会给我一个错误：

错误：42P02：没有参数$ 1

似乎Ecto实际上可能正在做parameterized query，如下所示：

PREPARE bydesc(text) AS SELECT i0."id", 
  i0."store_id", i0."title", i0."description" 
  FROM "items" AS i0 WHERE (i0."description" LIKE $1);
EXECUTE bydesc('foo');

如果是这样，我认为这会阻止SQL注入。但我只是猜测这就是Ecto的作用。

如何查看Ecto正在执行的实际SQL？

Answer 1

Ecto仅使用预准备语句。使用ecto查询语法时，无法引入SQL注入。查询语法在编译时验证是否可以进行SQL注入。

由于几个原因，确切地显示执行的查询可能很困难：

Postgrex（以及Ecto）使用postgresql二进制协议（而不是最常见但效率较低的文本协议），因此PREPARE查询实际上从未作为字符串存在。
对于大多数情况，您会看到所有内容都是一个PREPARE 64237612638712636123(...) AS ...，后来很多EXECUTE 64237612638712636123(...)并不是很有用。试图将彼此联系起来会非常糟糕。

根据我的经验，大多数此类软件使用prepare语句并记录它们而不是原始查询，因为它对理解系统行为更有帮助。

Answer 2

是的，这是Ecto正在执行的确切SQL（它在内部通过db_connection包使用准备好的查询），并且该代码中不能进行SQL注入。这可以通过在log_statement中将all更改为postgresql.conf来启用所有已执行SQL查询的记录来验证：

...
log_statement = 'all'
...

然后重新启动PostgreSQL并运行查询。对于以下查询：

Repo.get(Post, 1)
Repo.get(Post, 2)

已记录：

LOG:  execute ecto_818: SELECT p0."id", p0."title", p0."user_id", p0."inserted_at", p0."updated_at" FROM "posts" AS p0 WHERE (p0."id" = $1)
DETAIL:  parameters: $1 = '1'
LOG:  execute ecto_818: SELECT p0."id", p0."title", p0."user_id", p0."inserted_at", p0."updated_at" FROM "posts" AS p0 WHERE (p0."id" = $1)
DETAIL:  parameters: $1 = '2'

我可以让Ecto记录原始SQL吗？

2 个答案: