这段代码如何容易被SQL注入？

Question

我当时正在阅读PostgreSql文档这里，并看到了以下代码片段：

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

文档指出，“此方法通常比将数据值作为文本插入命令字符串更可取:它避免了将值转换为文本和回退的运行时开销，并且由于不需要引用或转义，因此它不太容易受到SQL注入攻击的攻击”。

你能告诉我这段代码是如何容易被SQL注入的吗？

编辑:在我使用过的所有其他关系数据库管理系统中，将完全防止SQL注入。在PostgreSql中有什么不同的实现？

Answer 1

快速回答是，它本身并不容易使用SQL注入，因为我理解您的问题--您在问我们为什么不这么说。因此，既然您正在寻找可能导致SQL注入的场景，那么请考虑mytable可能是一个视图，因此它后面可能有其他函数。这些函数可能容易受到SQL注入的影响。

因此，您不能查看一个查询，并得出结论，它肯定不会受到SQL注入的影响。您所能做的最好的就是指出，在提供的级别上，应用程序的这个特定级别在这里不会引起sql注入问题。

下面是一个很可能发生sql注入的例子。

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()也不一定能解决问题。

问题是，问题总是处于比正在执行的查询更低的级别。

Answer 2

绑定参数防止垃圾操作语句，使其做任何事情而不是它想要做的事情。

这保证了没有Postgres错误的SQL注入攻击的可能性。(关于可能出错的例子，请参阅H2C03链接。)

我想，“不太容易受到SQL注入攻击”的情况下，CYA语句就会出现。

Answer 3

contatenation通常与pastebin.com上的大型数据转储相关联，即使示例使用的是contatenation而不是变量，这种场景也不会在这里工作。这是因为COUNT(*)会聚合你想要窃取的所有数据。

但我可以想象，在某些情况下，任意记录的计数将是足够有价值的信息--例如竞争对手的客户数量、销售产品的数量等。实际上，还可以回忆一些非常棘手的盲目SQL注入方法--也许可以构建一个查询，仅使用计数就可以迭代地从数据库中恢复实际文本。

如果数据库足够老且配置错误，允许使用;分隔符，那么攻击者可能只需追加一个完全独立的查询即可利用该漏洞。