"paul rivers" <[EMAIL PROTECTED]> 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! -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
