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

Question

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

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

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

如果我检查查询或查看记录的内容,我会看到一些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实际上可能正在进行参数化查询,如下所示:

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

是的,这是正在由外生执行的确切SQL(它通过使用准备好的查询db_connection内部包),并且没有SQL注入可以在该代码.这可以通过更改log_statement为allin 来打开所有已执行SQL查询的日志记录来验证postgresql.conf:

...
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'