Re: Best practices for protect applications agains Sql injection. - Mailing list pgsql-general

From Ivan Sergio Borgonovo
Subject Re: Best practices for protect applications agains Sql injection.
Date
Msg-id 20080124021436.19472750@webthatworks.it
Whole thread Raw
In response to Re: Best practices for protect applications agains Sql injection.  (Gregory Stark <stark@enterprisedb.com>)
List pgsql-general
On Wed, 23 Jan 2008 21:34:31 +0000
Gregory Stark <stark@enterprisedb.com> wrote:

> "pepone.onrez" <pepone.onrez@gmail.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.

Once you've to build up prepared queries dynamically is there any
tool, framework, practice that can help you to stay away from sql
injection?

I'd say that queries can still be built with prepackaged static parts
and that real external input should just come in in forms of
parameters... so a DB abstraction layer or an ORM should help too...
maybe at the cost of some performance.
Otherwise you build up your specialised DB AL that assemble queries
from prepackaged static parts.

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


pgsql-general by date:

Previous
From: Raymond O'Donnell
Date:
Subject: Re: constraints in table
Next
From: "Leif B. Kristensen"
Date:
Subject: Re: constraints in table