>Those exact same insecure string concatenated queries are still being executed via mysqli_ and the PDO libraries. In my experience, binning mysql_ didn't make a damn bit of difference when it came to sql injection attacks.
Unlike ext/mysql, ext/mysqli and PDO both support server side prepared statements. If you don't utilize this properly, your argument is moot.
Official discussion points here: https://wiki.php.net/rfc/mysql_deprecation#why
The way I see it is new features, better practices, and greater security versus convenience. If the latter won, the former would need to be implemented on an ancient codebase, possibly opening up many new issues. If the former won and there's enough demand for ext/mysql, development may be continued by the community or at least shimmed on top of a proper extension or library. These decisions were being made while PHP was trying to gain traction in the "modern" web development community, making massive overall improvements leading to PHP 7+ due to pressure of Hack & HHVM, and doing a pretty damn good job with it.
Sure it sucked to convert existing code, but looking back, I'm glad I did, even if ext/mysql were still available. Luckily some of the larger, more abstracted codebases I've had to convert meant simply writing and swapping out an adapter. Most of the codebases I see nowadays still utilizing ext/mysql were clearly destined to bitrot regardless and now have far more important problems to worry about because they weren't designed to be maintained this long or they've been poorly maintained from inception. Good riddance.
Forming SQL by concatenating strings and variables is just bad practice and hopefully we can agree on that. ext/mysql provided no other option and this was just one of many issues with the extension.
Using ext/mysqli and PDO in a such a way (and I don't care if you're talking about retrofitting old code) is not even bad practice, it's just improper usage of the API when prepared statements should be used instead.
EDIT: Individually `print` `echo` `shell_exec` may be just as dangerous... It's up to the developer if they want to use them correctly.
and you don't have to install ext/mysql, they could just remove it from default configuration
mysqli_ has prepared queries, so it offers an immediate improvement.
In the real world dropping the mysql_* API achieved next to bugger all, we still ended up with a bunch sites with exactly the same SQL injection vulns.
They did? All of them? Nobody moved to paramaterized queries?
1) this is not an argument for leaving an inferior library in the language
2) plenty of people do update their software, for old code and large projects. Why not push people toward the better library?
The mysqli library was likely a full rewrite in another extension. Extensions, at least that kind, at that time, didn't use/have namespaces.
Keep in mind this is a legacy code base with a function called mysql_real_escape string, like if you're at that point you're so far past gone you've lost all hope.
for a 25 year library, thats not at all too bad. And even PHP developers admit that the lib was "not broken"
Only if they're used. If mysqli_ required prepared statements, then it would be different. But the sins that were committed with mysql_* could still be committed with mysqli_*.
The point wasn't "this fixed the injection problem" it was that it provided a solution not available for mysql_
it does for old code. and many people prefer a website with bugs than a website that doesn't work at all. And any website that was vulnerable to mysql_* attacks should have already been hacked out of existence by now.