演示PL/pgSQL中的SQL注入

问题描述:

我在plpgsql中具有此功能:

I have this function in plpgsql:

CREATE OR REPLACE function login_v(em varchar, passwd varchar)
  RETURNS users AS $$
DECLARE
   cu users;
BEGIN
   SELECT * into cu
   FROM users where email = em 
   AND encrypted_password = crypt(passwd, encrypted_password);

   return cu;
END
$$ LANGUAGE plpgsql;

当我提供这样的输入:select login_v('test@test.com'' OR 1=1;--','la la la');时,我认为我的方法应该向用户返回电子邮件test@test.com.我在做什么错了?

When I provide an input like this: select login_v('test@test.com'' OR 1=1;--','la la la');, I think my method should return the user with email test@test.com. What Am I doing wrong?

这里需要执行SQL注入来演示练习的概念,但是我是SQL注入和plpgsql boob. :|

Performing SQL injection is necessary here to demonstrate the concept for an exercise, but I am an SQL injection and plpgsql boob. :|

PL/pgSQL中的SQL查询的计划与准备好的语句类似.只要像您一样只传递 ,SQL注入通常是 不可能 .详细信息:

SQL queries in PL/pgSQL are planned like prepared statements. As long as you only pass values like you do, SQL injection is generally impossible. Details:

将动态SQL与EXECUTE一起使用,并且不进行适当的参数处理即可实际演示SQL注入.

Use dynamic SQL with EXECUTE and without proper parameter handling to actually demonstrate SQL injection.

就像(这是 不是 的做法!):

Like (this is how not to do it!):

CREATE OR REPLACE FUNCTION login_v(em varchar, passwd varchar)
  RETURNS SETOF users AS
$func$
BEGIN
   RETURN QUERY EXECUTE
        'SELECT *
         FROM   users
         WHERE  email = $1
         AND    encrypted_password = crypt(''' || passwd || ''', encrypted_password)'
   USING em;
END
$func$  LANGUAGE plpgsql;

第一个变量emUSING子句正确传递为 value ,因此不能被滥用用于SQL注入.

The first variable em is properly passed with the USING clause as value and thus cannot be abused for SQL injection.

但是第二个变量passwd的连接不正确,没有正确转义.因此,用户输入可以转换为SQL代码. SQL注入.

But the second variable passwd is improperly concatenated without properly escaping. Thus, user input can be converted to SQL code. SQL injection.

从不使用此功能!除非在演示如何做不做.

Never use this! Except when demonstrating how not to do it.

在客户端中不正确地连接SQL字符串时,可能会发生类似的恶作剧.

Similar mischief is possible when concatenating SQL strings in the client improperly.