Stefan Esser wrote:
While it is true that the PHP script is not subject to SQL injection
when the application does not build parts of the query based on
untrusted userinput it is not true that you are not at risk.
Ever heard of stored procedures? And precisely of SQL injection in
stored procedures? Prepared statements can do nothing about SQL
Injection in Stored Procedures. And if you teach people that they only
should use prepared statements they will NEVER know that it is dangerous
to put userinput into the query. And aside from that they have never
learned how to do it correctly if there is ever a situation where they
have to do it.
Maybe I am missing something. If you are talking about dynamic query
generation in stored routines, then I would think that people who read
the advice over dynamic query generation for PHP, that they would
hopefully also apply those practices to when they are writing/using
stored routines. Also DBA's in general are not all that fond of dynamic
query generation in stored routines.
Someone also mentioned that LIMIT parameters cannot be prepared:
"As of MySQL 5.0.7, placeholders can be used for the arguments of the
LIMIT clause when using prepared statements."
So at least in MySQL this works. I dont know about PostgreSQL or
Firebird. SQLite does not natively support prepared statements anyways.
Furthermore there is currently no good way in PHP to really reuse
prepared statements across requests in PHP, as such they help you very
little in terms of improving performance, unless you reuse the query
multiple times in a request. As a matter of fact they may even reduce
performance, because they may generate query plans that are inefficient
for the given placeholder values. This is because the query plan is
either optimized for the most general case or the first set of
placeholder values
Anyways .. we are moving away from PHP here.
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
