Re: Protection from SQL injection

"Thomas Mueller" <thomas.tom.mueller@[EMAIL PROTECTED]
> writes:

> Also, programming languages such as Java don't sup****t tainting. And
it's
> again in the hand of the developer to use it, not use it, or use it in
the
> wrong way. There should be a way for an admin to enforce using it, and
using
> it correctly.

I bet you could do something clever with Java.

Something like making the Execute() stmt take a special kind of string
object
which enforces that it can only be constructed as static final and takes a
String as a constructor argument . That would let you use literals in the
queries but bar you from including any user input at runtime. You could
even
include some methods for assembling such StaticStrings in useful ways
which
would let you build queries dynamically out of immutable pieces.

I think you're tilting at windmills if you want to bar *all* literals.
That's
just too big of a usability hit and as you pointed out with the common use
case of dynamically choosing ORDER BY it doesn't even catch other common
cases. You need to step back and find a way to prevent user input from
ending
up in the query regardless of whether it's in a literal or not.

-- 
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com
  Ask me about EnterpriseDB's PostGIS sup****t!

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@[EMAIL PROTECTED]
)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers