We can't necessarily say that bound parameters are "always more secure"
than quoting strings literally into the SQL. The goal is to make sure
that SQL injection doesn't creep in, either by an attacker or simply by
accident. Processing strings to escape special characters is a safe way
to accomplish that goal.
I agree that I would have preferred to use bound parameters more
consistently. But I was not the original programmer who designed the
Zend_Db solution, I just took over responsibility for it in January. I
had plenty of other more important issues to solve. This was a case of,
"it ain't broke, don't fix it."
The MySQL issue you cited makes reference to UTF-16. PHP 5 doesn't
support UTF-16 without use of the mbstring extension, so there's little
risk of that particular MySQL bug affecting Zend_Db.
Regards,
Bill Karwin
________________________________
From: Ryan Graciano [mailto:[EMAIL PROTECTED]
Sent: Friday, July 20, 2007 10:32 AM
To: [email protected]
Subject: [fw-general] quoteInto vs bound parameters
I've been looking through the Zend_Db documentation, and I'm
wondering why you would ever want to use quoteInto() or quote() as
opposed to binding your parameters in an array. What's the advantage to
quoteInto()/quote()? Isn't the separation of data provided by bound
parameters always going to be more secure than attempting to manipulate
the strings? As I understand it, all statements are prepared anyhow, so
why not use more bound parameters?
For example, wouldn't bound parameters always avoid bizarre
problems like unicode SQL injections
[http://bugs.mysql.com/bug.php?id=22243], whereas with quote/quoteInto
you're trusting the string parse to get it right?
I'm curious because it looks like relatively few methods (none?)
in Zend_Db_Table support bound parameters. To use binding, I need to go
to the adapter every time, which makes my Zend_Db_Table class somewhat
less convenient.
I'm new to ZF, so maybe I'm just missing something really
obvious here. I'd appreciate it if anyone could provide some insight.
Thanks,
- Ryan
