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

"My premise is that someone will do mistakes in the php code and I'd like to
mitigate the effect of these mistakes."

- Prepared statements is the only "bulletproof" technique

- You can use a database abstraction layer (there are more than many
libraries for PHP) Fast to implement, all queries goes through some form of
filter

- Recommended solution - use database abstraction & AUDIT your code / grabs
all SQL statements / create a summary and make sure then each statement is
safe

$db->Execute("select id from table1 where integer =" (int)$i);
$db->Execute("select * from table1 where string =" $db->quote($i));

Database abstractions alone often give you a false sense of security
especially if you use third part / open source solutions

-----Original Message-----
From: pgsql-general-owner@postgresql.org
[mailto:pgsql-general-owner@postgresql.org] On Behalf Of Ivan Sergio
Borgonovo
Sent: April 11, 2008 5:32 PM
To: pgsql-general@postgresql.org
Subject: Re: [GENERAL] SQL injection, php and queueing multiple statement

On Fri, 11 Apr 2008 14:27:09 -0500
"Adam Rich" <adam.r@sbcglobal.net> wrote:

> > Is there a switch (php side or pg side) to avoid things like:
> >
> > pg_query("select id from table1 where a=$i");
> >
> > into becoming
> >
> > pg_query("select id from table1 where a=1 and 1=1; do something
> > nasty; -- ");
>
> Ideally, you'd use this:
>
> pg_query_params('select id from table1 where a=$1', array($i));
>
> http://us2.php.net/manual/en/function.pg-query-params.php
>
> Alternately, you can do this:
>
> $i = pg_escape_string($i);
> pg_query(" select id from table1 where a='$i' ");

I'd try to be clearer.
The purpose of my question was not how to avoid sql injection... but
how to make it harder to exploit it.
My premise is that someone will do mistakes in the php code and I'd
like to mitigate the effect of these mistakes.

I know that even if you just permit one statement for each pg_query
you can still use blind sql injection to download whole tables etc...
but permitting more than one statement make things MUCH easier.

Up to my knowledge blind sql injection requires a lot of statement
and a lot of errors that will end up in my logs so I'll have a chance
to fix the error etc...

Prepared statements does not fit with part of the framework I'm
working with. And still I'm looking for a security net even in the
case someone is not respecting the policies.

thx

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


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general