Re: Disallowing multiple queries per PQexec()

From: "Daniel Verite" <daniel(at)manitou-mail(dot)org>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Surafel Temesgen" <surafel3000(at)gmail(dot)com>,"pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Disallowing multiple queries per PQexec()
Date: 2017-06-12 16:14:28
Message-ID: eeb56ded-2d74-4363-84b4-8ed5f2943e85@manitou-mail.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:

> Bearing in mind that I'm not really for this at all...

It's a band-aid, but certainly there are cases
where a DBA confronted to a badly written website
would just want to be able to:
ALTER USER webuser SET allow_multiple_queries TO off;

> But if an attacker is able to inject a SET command,
> he's already found a way around it. So there's no real
> point in locking down the GUC to prevent that.

I can think of the following case, where given the SQL-injectable
select id from users where email='$email';
an attacker would submit this string in $email:
foo' AND set_config('allow_multiple_queries', 'on', false)='on
which opens the rest of the session for a second injection, this
time in the form of several colon-separated commands that
would do the actual damage.

Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Janes 2017-06-12 16:42:35 Re: Why restore_command is called for existing files in pg_xlog?
Previous Message Tom Lane 2017-06-12 16:11:48 standby server crashes hard on out-of-disk-space in HEAD