Re: SQL injection, php and queueing multiple statement

From: Ivan Sergio Borgonovo <mail(at)webthatworks(dot)it>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: SQL injection, php and queueing multiple statement
Date: 2008-04-13 07:37:52
Message-ID: 20080413093752.6234d4dc@webthatworks.it
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Sun, 13 Apr 2008 10:03:48 +0800
Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> wrote:

> Your wrapper code can potentially do things like scan a string for
> semicolons not enclosed in single or double quotes. The rule
> probably has to be a little more complex than that, and has to
> handle escaped quotes, but it might achieve what you want.

I think this logic is already somewhere in the driver or the pg
engine. Whatever you write at the application level a) risk to be a
duplication of part of the parser b) risk to be less smart than the
parser itself and let slip something.

> Personally I doubt it's worth it for the questionable benefits
> gained over following a strong coding standard and having good code
> review.

> I do think that for web scripting users it would be nice for DB
> drivers to optionally throw an error if an execute call passes more
> than one statement. Your problem would be that it'd need to be an
> option that affects the whole app instance for it to achieve what
> you want without developer action, and a global option like that
> would potentially break 3rd party application code. The alternative
> would be something like an executeSingle(...) call or a flag to
> execute ... but that again just comes back to proper code review to
> ensure it's used.

Why does it have to be "global", couldn't it be "by connection" or
"by call to pg_query"?

On Sun, 13 Apr 2008 00:13:49 +0100
Sam Mason <sam(at)samason(dot)me(dot)uk> wrote:

> On Sat, Apr 12, 2008 at 11:06:42PM +0200, Ivan Sergio Borgonovo
> wrote:
> > But what about already written code that use pg_query?
>
> If you rewrite the database interface then it doesn't matter, the
> calls to pg_query will end up being calls to prepare/execute
> underneath so you'll have their protection. If you mean that

Sorry to everybody for not testing first what you were suggesting in
chorus.

function test_me() {
$result=pg_prepare("tonno","
select ItemID from catalog_items limit 1;
create table tonno(au int);");
$result=pg_execute("tonno");
return "pippo";
}

Query failed: ERROR: cannot insert multiple commands into a prepared
statement in ...

Not something easy to deploy after the cats are out, but at least I've
learnt something.

thanks

--
Ivan Sergio Borgonovo
http://www.webthatworks.it

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Craig Ringer 2008-04-13 08:02:35 Re: SQL injection, php and queueing multiple statement
Previous Message Paragon 2008-04-13 05:21:40 Re: VACUUM hanging on PostgreSQL 8.3.1 for larger tables