postgresql - 这段代码如何容易受到 SQL 注入(inject)？

Question

我正在阅读 PostgreSql 文档 here , 并遇到了以下代码片段:

EXECUTE 'SELECT count(*) FROM mytable WHERE inserted_by = $1 AND inserted <= $2'
   INTO c
   USING checked_user, checked_date;

文档指出“这种方法通常比将数据值作为文本插入命令字符串更可取:它避免了将值转换为文本并返回的运行时开销，而且它要少得多容易受到 SQL 注入(inject)攻击，因为不需要引用或转义。

你能告诉我这段代码是如何容易受到 SQL 注入(inject)的吗？

编辑: 在我使用过的所有其他 RDBMS 中，这将完全防止 SQL 注入(inject)。 PostgreSql 中有哪些不同的实现方式？

Answer 1

简单的回答是，它本身并不容易发生 SQL 注入(inject)，据我了解你的问题，你问的是为什么我们不直接这么说。因此，由于您正在寻找可能导致 SQL 注入(inject)的场景，请考虑 mytable 可能是一个 View ，因此它背后可能有其他功能。这些函数可能容易受到 SQL 注入(inject)攻击。

因此，您不能只看一个查询就断定它绝对不容易受到 SQL 注入(inject)的影响。您可以做的最好的事情是表明在提供的级别上，您的应用程序的这个特定级别不会在此处引发 sql 注入(inject)问题。

这是一个很可能发生 sql 注入(inject)的例子。

CREATE OR REPLACE FUNCTION ban_user() returns trigger
language plpgsql security definer as
$$
begin
    insert into banned_users (username) values (new.username);
    execute 'alter user ' || new.username || ' WITH VALID UNTIL ''YESTERDAY''';
    return new;
end;

请注意，实用程序函数不能像您指出的那样进行参数化，我们忘记了 quote_ident() 围绕 new.username，因此使该字段容易受到攻击。

CREATE OR REPLACE VIEW banned_users_today AS
SELECT username FROM banned_users where banned_date = 'today';

CREATE TRIGGER i_banned_users_today INSTEAD OF INSERT ON banned_users_today
FOR EACH ROW EXECUTE PROCEDURE ban_user();

EXECUTE 'insert into banned_users_today (username) values ($1)'
USING 'postgres with password ''boo''; drop function ban_user() cascade; --';

所以不，即使在任何可以使用的地方使用它也不能完全解决问题。正确使用 quote_literal() 和 quote_ident() 也不一定总能解决问题。

问题是问题总是在比您正在执行的查询更低的级别上。