

The Plot to Kill PHP MySQL Extension - mlemos
http://www.phpclasses.org/blog/post/153-The-Plot-to-Kill-PHP-MySQL-Extension.html

======
qntm
Will this result in more people using the prepared statements provided in PDO
etc.? Then this could reduce the global number of MySQL injection attacks by a
noticeable percentage.

~~~
duiker101
There is no MySQL injection attack. There is SQL injection attack. And it's
not merely a problem of mysql but of how the code that uses mysql is written.
And this affect all platforms. You should fix the developers to fix all sql
injections.

~~~
qntm
MySQL queries constitute a signification proportion of SQL queries, and PHP's
MySQL extension is responsible for a significant proportion of MySQL queries.
It's not a problem of MySQL and it's not even a problem of how the PHP code
that uses MySQL is written - the problem is that PHP's MySQL extension
_doesn't even offer_ a way to safely prepare a statement. "Fix the
developers", in this context, would mean beating them about the head until
they remember to mysql_real_escape_string() every parameter every time, and
that's obviously not the right approach.

A better approach is to either (1) add a mysql_prepare() function to the PHP
MySQL extension, or (2) deprecate the extension in favour of one which forces
or at least encourages or at least _supports_ the use of prepared statements.

------
SaltwaterC
First of all, mysqlnd is not a proper extension itself, but a backend for the
mysql / mysqli extensions. Anyone that bothers to build PHP 5.3.x knows that
mysqlnd replaces the libmysql dependency if the --with-mysql(i)=mysqlnd flag
is passed to the configure script. Which brings me to the point that the
author understands little of the internals themselves.

Second of all, people should man up, step up from their lazy ass and move on.
If the code is so really hard to refactor, maybe that code sucks really hard
in the first place. I've seen incredible piles of garbage PHP code just to
keep PHP 4 compatibility. It's 20-fu-11. 5 years since PHP 4 is officially
dead. Maybe, just maybe, the internals team is not to blame for this stuff.
I'm not even mentioning sentences containing the word "security" that seems to
be some really scary stuff for some pumpkins still trying to figure out how
SQLi works.

~~~
mlemos
The problem is that many, many PHP sites were created by people with limited
budgets that will avoid all types of maintenance in the site code, because
that means paying the developers more money to do those maintenance tasks, if
they ever have a clue that they really need to update their site code to work
with newer versions that shared hosting providers eventually will impose.

