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.
>
>
>
