From my point of view, saying use placeholder for security is
akin to saying use Java for secuity. If you don't know
WHY you need to use placeholders, then you should not
be writing code that deals with sensitive data, for using
placeholder and
writing secure code are orthogonal. Placeholder do not make
your
code secure. Writing secure code makes your code secure
wether or not you use placeholder. I'd even wager to say
that most that does prepare(q{SELECT this FROM that WHERE data_col = '$value'}) will have many other esaly exploitable
problems in the code, and the SQL injection would be the
least of your worries.
The use of placeholders is
normaly a feature that you will find in well-written code, but
not always; I for one have seen code that uses $dbh->quote()
to good effect (I know that the docs say that quote() is not
required to be able to handle all input, but with some
drivers quote and
placeholder call the same functions). And, at times placeholders can give you a false sense of security, for example, in older version of DBD::mysql treating a string as
a number in perl caused it not to be quoted when passed to
a placeholder. Or how about that problem with the null
byte in Postgres (I wonder if it could be exploited?)
Or maybe
you are dynamically generating SQL to use placeholders
based on an abritray set of entries returned, but if you
don't limit the set used to generate the where clause,
instant segfault. eg.
perl -MDBI -e '$h =
DBI->connect("dbi:Pg:dbname=template1","","");
$h->prepare("?"x10000);'
perl -MDBI -e '$h = DBI->connect("dbi:oracle","","");
$h->prepare("?"x10000000);'
Both of the above problems would be fixed with good coding
but not just using placeholders. (Site note, using $dbh->quote() would have worked just fine.)
Do not get me wrong; I am not saying not to use place
holder... USE THEM!! I am saying that if you are going
to write secure code you have to know why your code is
secure and not just fall back on a litany of simple rules
like 'use placeholders'