paul rivers wrote:
Ivan Sergio Borgonovo wrote:
Yeah... but how can I effectively enforce the policy that ALL input
will be passed through prepared statements?
Code reviews are about the only way to enforce this.
That's not entirely true - if you have a policy that says thou-shalt-not-use
non-prepared statements then an automated (nightly) grep of the source tree is
going to find calls that don't follow that policy - these can be automatically
emailed to you/your project enforcer. Couple that with a process step that
enforces a grep for offending statements as part of transferring files to the
live servers and you're about done.
I'm assuming that the current policy would not allow just anyone to upload any
code to critical live systems anyway.
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? Do you parse the SQL string according to the rules of any
backend database you might be talking to, to see if you have a where
clause not using a prepared statement? i.e. - Nothing is going to work
here.
You're stuck with making sure developers know the most rudimentary
things about talking to a database.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
