Re: Best practices for protect applications agains Sql injection.

From: "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com>
To: "Gregory Stark" <stark(at)enterprisedb(dot)com>
Cc: pepone(dot)onrez <pepone(dot)onrez(at)gmail(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: Best practices for protect applications agains Sql injection.
Date: 2008-01-24 04:41:33
Message-ID: dcc563d10801232041q7c9d7d79r1a1b1c10fe1cdbe6@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Jan 23, 2008 3:34 PM, Gregory Stark <stark(at)enterprisedb(dot)com> wrote:
> "pepone.onrez" <pepone(dot)onrez(at)gmail(dot)com> writes:
>
> > Hi all
> >
> > I interesting in the protect my applications that use postgresql as is
> > database backend from Sql Injections attacks, can any recommend me best
> > pratices or references to protected postgres from this kind of malicious
> > users.
>
> I strongly urge people to adopt a policy of using prepared queries except when
> absolutely necessary. If all user-provided data is passed to the database as
> parameters to a prepared query then you should never need to worry about SQL
> injection.
>
> It's possible to always quote your parameters before inserting them into the
> query but it's much more error-prone. It's also much harder to look at a piece
> of code and be sure it's correct. If you religiously use prepared queries then
> any variables interpolated directly into the query stand out like sore thumbs.

Two points. 1: Only grant the access needed to the user. i.e. if
it's only going to be reading from the, then don't use an account that
anything other than select privaleges. 2: I don't find use of
pg_escape_string() to be all that error prone.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Sim Zacks 2008-01-24 07:37:53 PGCon vs Postgresql Conference
Previous Message Gregory Williamson 2008-01-24 01:21:09 Re: constraints in table