On Sat, 12 Apr 2008 20:25:36 +0100
Gregory Stark <stark@enterprisedb.com> wrote:
> "paul rivers" <rivers.paul@gmail.com> writes:
>
> >> If I can't, and I doubt there is a system that will let me
> >> enforce that policy at a reasonable cost, why not providing a
> >> safety net that will at least raise the bar for the attacker at
> >> a very cheap cost?
> >
> > How do you do this? Disallow string concatenation and/or variable
> > interpolation for any string that's going to be shipped off to
> > the database?
>
> Actually there is a system that can do this. Perl with the -T
> option. It keeps track of which strings are "tainted" by user-input
> and functions like eval will cause errors if you try to pass them a
> tainted string. The database drivers support this and will trigger
> an error if they're passed a tainted string.
The db driver?
Could you make any real php example?
eg. I'm looking to provide a safety net to:
$querystring='select id, name from table1 where id in
(".$somearray.") and name like $1';
$result=pg_prepare($dbconn, "a_query",$querystring);
On Sat, 12 Apr 2008 16:18:34 -0400
Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Modify the PHP code (at whatever corresponds to the DBD layer)
> to always use PQexecParams, never PQexec, even when you don't
> have any parameters.
How it is going to work for the above case?
I read:
"The primary advantage of PQexecParams over PQexec is that parameter
values may be separated from the command string, thus avoiding the
need for tedious and error-prone quoting and escaping. Unlike PQexec,
PQexecParams allows at most one SQL command in the given string.
(There can be semicolons in it, but not more than one nonempty
command.) This is a limitation of the underlying protocol, but has
some usefulness as an extra defense against SQL-injection attacks."
Are you suggesting that wrapping all the pg_query into pg_prepare +
pg_execute will solve the problem? And that I kept misunderstanding
what you were saying in the previous N posts? ;)
that means that if an attacker push more than one statement trough
$somearray in the above example it won't work?
But what about already written code that use pg_query?
Is it that terrible or nonsensical to hope to have a switch that will
enable/disable multiple statements for each call to pg_query?
On Sat, 12 Apr 2008 20:52:11 +0200
"Dawid Kuroczko" <qnex42@gmail.com> wrote:
[some good advices]
Yep... I'm already doing my best at it.
Working with libraries doesn't make it always feasible and it is far
more complicated than just forbidding extra statement in each call to
pg_query.
thx
--
Ivan Sergio Borgonovo
http://www.webthatworks.it