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.
>
(Note: I'm clueless about PHP, so I'm basing this on perl/python/etc):
Something that'll make code review easier is to wrap the DB driver with
your own module that performs the checks you're looking to do on the
SQL. Prohibit use of the postgresql db interface module directly.
Anybody who directly imports the postgresql driver is doing something
wrong in a way that's easily detectable. You could even, with a little
effort, use a svn hook script to scan for and reject commits including
the import statement in question, though a deliberately malicious
programmer could still get around that.
Your wrapper code can potentially do things like scan a string for
semicolons not enclosed in single or double quotes. The rule probably
has to be a little more complex than that, and has to handle escaped
quotes, but it might achieve what you want.
Personally I doubt it's worth it for the questionable benefits gained
over following a strong coding standard and having good code review.
I do think that for web scripting users it would be nice for DB drivers
to optionally throw an error if an execute call passes more than one
statement. Your problem would be that it'd need to be an option that
affects the whole app instance for it to achieve what you want without
developer action, and a global option like that would potentially break
3rd party application code. The alternative would be something like an
executeSingle(...) call or a flag to execute ... but that again just
comes back to proper code review to ensure it's used.
--
Craig Ringer