5 ms·

This mysql extension was deprecated six years ago. It lacked support for many important features such as transactions, stored procedures, parameterization that

This mysql extension was deprecated six years ago. It lacked support for many important features such as transactions, stored procedures, parameterization that were either often insecurely shoehorned or simply not capable. http://php.net/manual/en/mysqlinfo.api.choosing.php http://php.net/manual/en/mysqlinfo.api.choosing.php

teh_klev 8y ago
Read my comment above where I explain why it was a pointless move: >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.
- leetbulb 8y ago
  I don't care how safe you think your input validation is, concatenating strings and variables together should NEVER be done for SQL. Writing your own input validation for SQL is similar to "homebrew crypto." Even if it's mostly safe, it'll eventually bite you in the ass. You won't think of every possible attack vector. Same goes for shell, XSS, etc... In CTFs, you'd be surprised at some of the shit that you end up doing to exploit these types of vulnerabilities. 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 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.
  - Izkata 8y ago
    You seem to have totally missed the point: mysql_* were removed in order to prevent string-concat SQL from being used, but people just end up doing the same thing with the new methods, so there was no benefit to removing them.
    - leetbulb 8y ago
      ext/mysql was not removed "to prevent string-concat SQL from being used." ext/mysqli and PDO allow raw SQL to be executed as well. It's just a necessary feature in some cases, but it should be reserved for static SQL. 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.
      - buboard 8y ago
        > 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
sbarre 8y ago
I think the point is that those functions could have just been aliased to other methods from other libraries, in order to maintain compatibility for older applications while removing the deprecated underlying library.

teh_klev 8y ago

Read my comment above where I explain why it was a pointless move: >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.

leetbulb 8y ago
I don't care how safe you think your input validation is, concatenating strings and variables together should NEVER be done for SQL. Writing your own input validation for SQL is similar to "homebrew crypto." Even if it's mostly safe, it'll eventually bite you in the ass. You won't think of every possible attack vector. Same goes for shell, XSS, etc... In CTFs, you'd be surprised at some of the shit that you end up doing to exploit these types of vulnerabilities. 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 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.
- Izkata 8y ago
  You seem to have totally missed the point: mysql_* were removed in order to prevent string-concat SQL from being used, but people just end up doing the same thing with the new methods, so there was no benefit to removing them.
  - leetbulb 8y ago
    ext/mysql was not removed "to prevent string-concat SQL from being used." ext/mysqli and PDO allow raw SQL to be executed as well. It's just a necessary feature in some cases, but it should be reserved for static SQL. 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.
    - buboard 8y ago
      > 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

sbarre 8y ago

I think the point is that those functions could have just been aliased to other methods from other libraries, in order to maintain compatibility for older applications while removing the deprecated underlying library.