Skip site navigation (1) Skip section navigation (2)

Re: Protection from SQL injection

From: "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Thomas Kellerer" <spam_eater(at)gmx(dot)net>, pgsql-sql(at)postgresql(dot)org
Subject: Re: Protection from SQL injection
Date: 2008-04-27 03:50:10
Message-ID: dcc563d10804262050u3da9f7f8n66bc30596ba63772@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-sql
On Sat, Apr 26, 2008 at 9:42 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com> writes:
>  > Wouldn't it be much simpler to have a version of the libpq client lib
>  > that only understands prepared queries?
>
>  You could do that, but there's still no way for it to know exactly how
>  the submitted query was constructed.  This would block off the types of
>  injections that want to add whole SQL commands, but not ones that just
>  subvert the current query (eg adding OR TRUE to see data you shouldn't).
>
>  This is really a client problem and only client-side solutions will
>  provide meaningful traction for it.  In perl, for instance, the "taint"
>  mechanism is a good way to notice whether any insecure strings are
>  getting into database queries.

Agreed.  My point was that to do what the OP wants, wouldn't it make
more sense to just lobotomize libpq so it doesn't understand anything
but prepared queries.  Doesn't obviate the need for a client side
language based solution.  Just seems to make WAY more sense than
trying to make the change at the server level in pgsql.

In response to

Responses

pgsql-sql by date

Next:From: Tom LaneDate: 2008-04-27 03:58:40
Subject: Re: Protection from SQL injection
Previous:From: Tom LaneDate: 2008-04-27 03:42:14
Subject: Re: Protection from SQL injection

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group