6 ms·

yeah the mysql_* function removal happened for no reason whatsoever. A library that did not need maintainance is something to keep , not throw away.

nkozyra 8y ago
Even though it had no paramaterized/prepared queries and made injection issues abundant?
- buboard 8y ago
  not a fault of the library itself. also, mysqli_* has the same issue, was not removed
  - nkozyra 8y ago
    It doesn't matter whose fault it is; if it provides no mechanism for prepared queries, it should be replaced. mysqli_ has prepared queries, so it offers an immediate improvement.
    - creeble 8y ago
      Why couldn't the mysql_ library just have added prepared queries? I've never understood this (not a PHP programmer, just someone who has had to patch a dozen sites that were suddenly broken once).
      - lugg 8y ago
        MySQL libraries are extensions. 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.
        buboard 8y ago
        > 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"
    - teh_klev 8y ago
      You missed my point. All developers did was replace their mysql_* calls with mysqli_* calls but skipped out on the parameterising step. Sure they're using a parameterised capable API, but they're not actually parameterising their queries. 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.
      - nkozyra 8y ago
        > All developers did was replace their mysql_* They did? All of them? Nobody moved to paramaterized queries?
        teh_klev 8y ago
        When you work for a mass market shared hoster you get to see all sorts of ugliness, dirty hacks, incompetence and just plain lazyness.
        ars 8y ago
        New code sure? But existing code? Especially large projects? No.
        nkozyra 8y ago
        I am 100% a LOT of projects fall under this umbrella, but: 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?
    - reaperducer 8y ago
      mysqli_ has prepared queries, so it offers an immediate improvement. 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_*.
      - nkozyra 8y ago
        Absolutely, the idea was to provide prepared queries while allowing people to migrate their code. The point wasn't "this fixed the injection problem" it was that it provided a solution not available for mysql_
    - buboard 8y ago
      > It doesn't matter whose fault it is 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.
  - ddebernardy 8y ago
    Unless something has changed since the early 2000s, `mysqli_` doesn't have a gazillion PHP/MySQL tutorials that are riddled with insecure code. That alone was a good reason to deprecate `mysql_`.
leetbulb 8y ago
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.

nkozyra 8y ago

Even though it had no paramaterized/prepared queries and made injection issues abundant?

buboard 8y ago
not a fault of the library itself. also, mysqli_* has the same issue, was not removed
- nkozyra 8y ago
  It doesn't matter whose fault it is; if it provides no mechanism for prepared queries, it should be replaced. mysqli_ has prepared queries, so it offers an immediate improvement.
  - creeble 8y ago
    Why couldn't the mysql_ library just have added prepared queries? I've never understood this (not a PHP programmer, just someone who has had to patch a dozen sites that were suddenly broken once).
    - lugg 8y ago
      MySQL libraries are extensions. 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.
      - buboard 8y ago
        > 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"
  - teh_klev 8y ago
    You missed my point. All developers did was replace their mysql_* calls with mysqli_* calls but skipped out on the parameterising step. Sure they're using a parameterised capable API, but they're not actually parameterising their queries. 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.
    - nkozyra 8y ago
      > All developers did was replace their mysql_* They did? All of them? Nobody moved to paramaterized queries?
      - teh_klev 8y ago
        When you work for a mass market shared hoster you get to see all sorts of ugliness, dirty hacks, incompetence and just plain lazyness.
      - ars 8y ago
        New code sure? But existing code? Especially large projects? No.
        nkozyra 8y ago
        I am 100% a LOT of projects fall under this umbrella, but: 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?
  - reaperducer 8y ago
    mysqli_ has prepared queries, so it offers an immediate improvement. 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_*.
    - nkozyra 8y ago
      Absolutely, the idea was to provide prepared queries while allowing people to migrate their code. The point wasn't "this fixed the injection problem" it was that it provided a solution not available for mysql_
  - buboard 8y ago
    > It doesn't matter whose fault it is 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.
- ddebernardy 8y ago
  Unless something has changed since the early 2000s, `mysqli_` doesn't have a gazillion PHP/MySQL tutorials that are riddled with insecure code. That alone was a good reason to deprecate `mysql_`.

leetbulb 8y ago

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.