Re: Protection from SQL injection - Mailing list pgsql-hackers

From Aidan Van Dyk
Subject Re: Protection from SQL injection
Date
Msg-id 20080429152304.GM6337@yugib.highrise.ca
Whole thread Raw
In response to Re: Protection from SQL injection  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Protection from SQL injection  (Gregory Stark <stark@enterprisedb.com>)
List pgsql-hackers
* Tom Lane <tgl@sss.pgh.pa.us> [080429 10:59]:
> "Tom Dunstan" <pgsql@tomd.cc> writes:
> > Damn, am I the only person who likes the idea?
> 
> Just about.  The reason that this idea isn't going anywhere is that its
> cost/benefit ratio is untenably bad.  Forbidding literals will break
> absolutely every SQL-using application on the planet, and in many cases
> fixing one's app to obey the rule would be quite painful (consider
> especially complex multi-layered apps such as are common in the Java
> world).  In exchange for that, you get SQL injection protection that
> has got a lot of holes in it, plus it stops protecting you at all
> unless you are using a not-SQL-standard database.  That tradeoff is
> not happening, at least not in any nontrivial application.
> 
> Analogies such as PIE just point up the difference: for 99% of
> applications, you can enable PIE without doing any more work than
> adding a compile switch.  If people were looking at major surgery
> on most of their apps to enable it, the idea would never have gone
> anywhere.

I guess my database apps qualify as "nontrivial".  I'm pretty sure that
I *could* enable something like this in all my web-facing apps *and* my
compiled C/C++ apps and not have any troubles.

And I happen to have programs/code that fail on PIE/execshield stuff.

I guess everything is relative.

That said, though *I* like the idea (and since I develop against
PostgreSQL 1st and use params for my queries I would consider it a nice
tool to "keep me honest"), I can easily see that the cost/benefit ratio
on this could be quite low and make it not worth the code/support
necessary.

> If you're going to ask people to do significant revision of their
> apps to gain security, they're going to want it to work no matter
> what database they run their apps against.  This is why you need
> a client-side solution such as tainting.

Well, just because a tool is available doesn't mean people have to use
it.  I mean, we have PostgreSQL, and we think that's worth it, even
though to use it, "everybody" has to do significant revision of their
apps.

a.

-- 
Aidan Van Dyk                                             Create like a god,
aidan@highrise.ca                                       command like a king,
http://www.highrise.ca/                                   work like a slave.

pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Protection from SQL injection
Next
From: "Zubkovsky, Sergey"
Date:
Subject: Re: [DOCS] pg_total_relation_size() and CHECKPOINT