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
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 |