Re: Best practices for protect applications agains Sql injection.

From: Ivan Sergio Borgonovo <mail(at)webthatworks(dot)it>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: Best practices for protect applications agains Sql injection.
Date: 2008-01-24 01:14:36
Message-ID: 20080124021436.19472750@webthatworks.it
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, 23 Jan 2008 21:34:31 +0000
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.

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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Leif B. Kristensen 2008-01-24 01:20:15 Re: constraints in table
Previous Message Raymond O'Donnell 2008-01-24 01:11:29 Re: constraints in table