Re: SQL injection, php and queueing multiple statement - Mailing list pgsql-general

From Ivan Sergio Borgonovo
Subject Re: SQL injection, php and queueing multiple statement
Date
Msg-id 20080413093752.6234d4dc@webthatworks.it
Whole thread Raw
In response to Re: SQL injection, php and queueing multiple statement  (Craig Ringer <craig@postnewspapers.com.au>)
Responses Re: SQL injection, php and queueing multiple statement  (Craig Ringer <craig@postnewspapers.com.au>)
List pgsql-general
On Sun, 13 Apr 2008 10:03:48 +0800
Craig Ringer <craig@postnewspapers.com.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@samason.me.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


pgsql-general by date:

Previous
From: "Paragon"
Date:
Subject: Re: VACUUM hanging on PostgreSQL 8.3.1 for larger tables
Next
From: Craig Ringer
Date:
Subject: Re: SQL injection, php and queueing multiple statement