Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.databases.postgresql > #849

Re: plpgsql function SQL injection vulnerability?

Show all headers | View raw

On Fri, 26 Oct 2018 00:47:35 -0400, George Neuner wrote:

>> CREATE OR REPLACE FUNCTION search_for_address(re TEXT)
>> RETURNS TABLE(line VARCHAR) AS $$
>> BEGIN
>> 	RETURN QUERY SELECT k.line FROM kdata k WHERE k.line ~* re ORDER 
BY
>> 	k.line ASC LIMIT 100;
>> END;
>> $$ LANGUAGE plpgsql SECURITY DEFINER;
>>
>> Is this function vulnerable to SQL injection attacks via input 're 
TEXT'
>> or does the PG parser prevent it in these plpgsql functions?
> 
> This particular use is safe: the 're' argument to the function is passed
> as a parameter to the ~* regex operator in a statc query ...
> the contents of the 're' string can't escape the operator's scope.

The function may be safe from SQL injection, but it is vulnerable to
privilege escalation attacks.

The attacker could define a ~* operator in "his" schema, set search_path
to that schema and call the function to execute arbitrary code with
elevated privileges.

That's why you should always define SECURITY DEFINER functions with
  SET search_path=pg_catalog
and schema qualify all access to objects in other schemas.

Back to comp.databases.postgresql | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

plpgsql function SQL injection vulnerability? sten.unto@gmail.com (Unto Sten) - 2018-10-25 17:11 +0000
  Re: plpgsql function SQL injection vulnerability? George Neuner <gneuner2@comcast.net> - 2018-10-26 00:47 -0400
    Re: plpgsql function SQL injection vulnerability? Laurenz Albe <laurenz@nospam.pn> - 2018-10-26 12:47 +0000
      Re: plpgsql function SQL injection vulnerability? sten.unto@gmail.com (Unto Sten) - 2018-10-26 19:06 +0000
    Re: plpgsql function SQL injection vulnerability? sten.unto@gmail.com (Unto Sten) - 2018-10-26 19:08 +0000

csiph-web