On Fri, 26 Sep 2008 14:04:35 -0500, Michael Mabin <d3vvnull@gmail .comwrote:
No, not really. Particularly when it's not any harder to be secure than
it is to be insecure, there's no reason to pick the insecure solution.
It doesn't cost you anything to be secure. It *might* cost you something
to be insecure, even if the environment is controlled. It's rarely the
case that you actually control *every* aspect of an environment, and you
can't reliably predict how a piece of code you write will be used in the
future (either by you or by someone else, perhaps someone you've never
even met at the time you write the code).
Jean-Paul
>Doesn't it depend on where and why you intend to execute the code?
>Obviously some SQL is more at risk for exploit when the input is from the
>screen on a web page than if you were running parameterized code in a
>controlled batch environment. Or if you were writing code generators (which
>is what I happen to do) which won't be run by the general public.
>
>Obviously some SQL is more at risk for exploit when the input is from the
>screen on a web page than if you were running parameterized code in a
>controlled batch environment. Or if you were writing code generators (which
>is what I happen to do) which won't be run by the general public.
>
it is to be insecure, there's no reason to pick the insecure solution.
It doesn't cost you anything to be secure. It *might* cost you something
to be insecure, even if the environment is controlled. It's rarely the
case that you actually control *every* aspect of an environment, and you
can't reliably predict how a piece of code you write will be used in the
future (either by you or by someone else, perhaps someone you've never
even met at the time you write the code).
Jean-Paul