The Plot to Kill PHP MySQL Extension | Hacker News Reader

The Plot to Kill PHP MySQL Extension

phpclasses.org

2 pointsmlemos5 comments

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.

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.

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.

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.

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.

Reply on news.ycombinator.com