"paul rivers" <rivers.paul@gmail.com> writes:
>> If I can't, and I doubt there is a system that will let me enforce
>> that policy at a reasonable cost, why not providing a safety net that
>> will at least raise the bar for the attacker at a very cheap cost?
>
> How do you do this? Disallow string concatenation and/or variable interpolation
> for any string that's going to be shipped off to the database?
Actually there is a system that can do this. Perl with the -T option. It keeps
track of which strings are "tainted" by user-input and functions like eval
will cause errors if you try to pass them a tainted string. The database
drivers support this and will trigger an error if they're passed a tainted
string.
It doesn't protect you from a malicious programmer of course. It's easy to
intentionally untaint a string. But it does a pretty good job of protecting
you against accidental security holes.
In my experience if you have a flat policy of _never_ allowing interpolated
strings then the problem just doesn't come up. It's easy to spot interpolated
strings during code review. If you have a more complex policy where sometimes
they're allowed if they come from internal data structures or they've been
checked then I think it would be helpful.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's 24x7 Postgres support!
