Re: Protection from SQL injection

From: Aidan Van Dyk <aidan(at)highrise(dot)ca>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Tom Dunstan <pgsql(at)tomd(dot)cc>, Thomas Mueller <thomas(dot)tom(dot)mueller(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Protection from SQL injection
Date: 2008-04-29 15:23:04
Message-ID: 20080429152304.GM6337@yugib.highrise.ca
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> [080429 10:59]:
> "Tom Dunstan" <pgsql(at)tomd(dot)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(at)highrise(dot)ca command like a king,
http://www.highrise.ca/ work like a slave.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Zubkovsky, Sergey 2008-04-29 16:05:01 Re: [DOCS] pg_total_relation_size() and CHECKPOINT
Previous Message Andrew Dunstan 2008-04-29 15:05:54 Re: Protection from SQL injection