Yasuo Ohgaki <[EMAIL PROTECTED]> writes:
> It would be nice to have API like PQquerySingle that allows only a single SQL
> statement at a time.
We have one (the "extended query" protocol).
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql
Developers,
It seems you are overlooking application user/system admin perspective.
I agree developers should use prepared statement, but application user or
system admins are not able to modify codes usually.
There are many PostgreSQL/MySQL applications that generating SQL statements.
MySQL's
On Sun, 13 Apr 2008, Ivan Sergio Borgonovo wrote:
> On Sun, 13 Apr 2008 16:02:35 +0800
> Craig Ringer <[EMAIL PROTECTED]> wrote:
>
> > > 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 pa
On Sun, 13 Apr 2008 11:49:58 +0200
Martijn van Oosterhout <[EMAIL PROTECTED]> wrote:
> On Sun, Apr 13, 2008 at 10:37:52AM +0200, Ivan Sergio Borgonovo
> wrote:
> > > Because you appear to be seeking something to protect against
> > > programmers who do not follow coding guidelines, and that shoul
On Sun, Apr 13, 2008 at 10:37:52AM +0200, Ivan Sergio Borgonovo wrote:
> > Because you appear to be seeking something to protect against
> > programmers who do not follow coding guidelines, and that should
> > help even if code review processes fail to catch the problem. Were
> > that not the case
On Sun, 13 Apr 2008 16:02:35 +0800
Craig Ringer <[EMAIL PROTECTED]> wrote:
> > 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
Ivan Sergio Borgonovo wrote:
On Sun, 13 Apr 2008 10:03:48 +0800
Craig Ringer <[EMAIL PROTECTED]> 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
On Sun, 13 Apr 2008 10:03:48 +0800
Craig Ringer <[EMAIL PROTECTED]> 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,
paul rivers wrote:
Ivan Sergio Borgonovo wrote:
Yeah... but how can I effectively enforce the policy that ALL input
will be passed through prepared statements?
Code reviews are about the only way to enforce this.
(Note: I'm clueless about PHP, so I'm basing this on perl/python/etc):
Somet
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.
On Sat, 12 Apr 2008 20:25:36 +0100
Gregory Stark <[EMAIL PROTECTED]> wrote:
> "paul rivers" <[EMAIL PROTECTED]> 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
Ivan Sergio Borgonovo <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> wrote:
>> Use prepared statements.
> Yeah... but how can I effectively enforce the policy that ALL input
> will be passed through prepared statements?
Modify the PHP code (at whatever corresponds to the DBD layer)
to
Gregory Stark wrote:
"paul rivers" <[EMAIL PROTECTED]> 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 thi
"paul rivers" <[EMAIL PROTECTED]> 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 con
paul rivers wrote:
Ivan Sergio Borgonovo wrote:
Yeah... but how can I effectively enforce the policy that ALL input
will be passed through prepared statements?
Code reviews are about the only way to enforce this.
That's not entirely true - if you have a policy that says thou-shalt-not-use
Ivan Sergio Borgonovo wrote:
Yeah... but how can I effectively enforce the policy that ALL input
will be passed through prepared statements?
Code reviews are about the only way to enforce this.
If I can't, and I doubt there is a system that will let me enforce
that policy at a reasonable
On Fri, Apr 11, 2008 at 9:21 PM, Ivan Sergio Borgonovo
<[EMAIL PROTECTED]> 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; -- "
On Sat, 12 Apr 2008 12:39:38 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> Ivan Sergio Borgonovo <[EMAIL PROTECTED]> writes:
> > I may sound naive but having a way to protect the DB from this
> > kind of injections looks as a common problem, I'd thought there
> > was already a common solution.
>
>
Ivan Sergio Borgonovo <[EMAIL PROTECTED]> writes:
> I may sound naive but having a way to protect the DB from this kind
> of injections looks as a common problem, I'd thought there was
> already a common solution.
Use prepared statements.
regards, tom lane
--
Sent via pg
On Sat, 12 Apr 2008 11:11:48 -0400
"Jonathan Bond-Caron" <[EMAIL PROTECTED]> wrote:
> "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
I'm not looking for something
an 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" <[EMAIL PROTECTED]> wrote:
> > Is there a switch (php side or pg
On Fri, 11 Apr 2008 14:27:09 -0500
"Adam Rich" <[EMAIL PROTECTED]> 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
> > nas
[EMAIL PROTECTED] (Ivan Sergio Borgonovo) writes:
> 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; -- ");
>
> So that every
> pg_query(...)
> 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', a
24 matches
Mail list logo
