4 ms·

It makes me wonder if there’s a mysql_fake_escape_string or mysql_doesnt_actually_escape_string function. And why those functions would even exist in a language

by zzt123 5y ago

It makes me wonder if there’s a mysql_fake_escape_string or mysql_doesnt_actually_escape_string function. And why those functions would even exist in a language.

hnick 5y ago
It exists because "mysql_escape_string() does not take a connection argument and does not respect the current charset setting."
- zzt123 5y ago
  I thought the security of escaping is dependent on not having mismatched charsets? In which case, not respecting charset settings seems potentially not actually escaping? Seems like a strange function to have, although I could be foggy on my charsets.
  - hnick 5y ago
    PHP (and old languages in general) are full of ASCII-only English-centric assumptions. I think both functions are now considered deprecated since we have even more variations like mysqli_real_escape_string (or just use PDO with bound params).
  - SilverRed 5y ago
    It shows the culture in PHP. They would rather keep a function around that doesn't work properly just so existing code still works instead of making everyone test that the new function works.
    - ericbarrett 5y ago
      As another commenter points out, this is actually a quirk of the underlying MySQL C library, which has (or had) both functions.
    - gregjor 5y ago
      It shows a trade-off between arbitrarily breaking code in production or not. Lots of PHP sites are hosted on services that don’t give the programmer control over the PHP version. If the hosting provider upgrades and breaks a bunch of sites that’s a problem every bit as serious (to the site’s owner) as unescaped HTML opening up XSS attacks.
      - SilverRed 5y ago
        This is not sustainable or a desirable thing to keep. By accepting this state of things, no security fix with breaking changes can ever be implemented.
        gregjor 5y ago
        With all respect your comment is both arrogant and unrealistic. Exactly how do we not accept this state of things? No one claims it's desirable, it just is: bad code is out there, and it's not easy to fix. What would you tell a small business that relies on clunky 10-year-old code to run their business? To rewrite it in a more modern language at huge expense and risk (given that a majority of rewrite projects fail)? Can you guarantee the new thing won't be just as obsolete and vulnerable and buggy in ten years? These kinds of problems -- poorly-written and vulnerable code, amateur programmers, lack of professionalism, maintaining back-compatibility with an installed base -- are not specific to PHP. They afflict the entire software industry, and always have. Who could have seen into the future back in 2000 (when I first got exposed to PHP) that a new site would get probed by an army of bots within five minutes of going live? Or that it would be even harder today than back then to find and hire experienced programmers? PHP has had many security fixes implemented since the early releases, but how can anyone force users of an open-source language to upgrade for their own good? Or pay someone to ferret out and fix vulnerabilities they have never got hit by? Even brand new code has this problem. Look at all of the cryptocurrency code written in the last few years. We read about hacks and thefts and vulnerabilities every day, and that was written by supposedly smart people with access to modern languages and with knowledge of the contemporary security issues. And it still gets hacked. If we knew how to write perfect code that would still be perfect into the future I'm sure we would do that but until then we'll have to live with what we have. So far it has been sustainable, just less than optimal, if by optimal we mean what we can imagine rather than what we, as programmers, actually deliver.
    - paulddraper 5y ago
      https://www.reddit.com/r/ProgrammerHumor/comments/8667lt/stackoverflow_has_become_sentient/ https://www.reddit.com/r/ProgrammerHumor/comments/8667lt/sta...
    - heurisko 5y ago
      That's not completely true. Over its evolution, PHP has removed some functions completely to provide better and more secure functionality, such as mysql_* in PHP 7.
    - tored 5y ago
      No, every PHP release deprecates functions or fixes functions that is either considered bad or not working as intended. Quick search & I found these (note that some of the rfc's include multiple deprecations), but there is more if you bother to actually look. Stop spreading misinformation. https://wiki.php.net/rfc/deprecations_php_8_1 https://wiki.php.net/rfc/deprecations_php_8_1 https://wiki.php.net/rfc/deprecations_php_7_4 https://wiki.php.net/rfc/deprecations_php_7_4 https://wiki.php.net/rfc/deprecations_php_7_3 https://wiki.php.net/rfc/deprecations_php_7_3 https://wiki.php.net/rfc/deprecations_php_7_2 https://wiki.php.net/rfc/deprecations_php_7_2 https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7 https://wiki.php.net/rfc/remove_deprecated_functionality_in_... https://wiki.php.net/rfc/deprecate_curly_braces_array_access https://wiki.php.net/rfc/deprecate_curly_braces_array_access https://wiki.php.net/rfc/ternary_associativity https://wiki.php.net/rfc/ternary_associativity https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_a... https://wiki.php.net/rfc/deprecate-png-jpeg-2wbmp https://wiki.php.net/rfc/deprecate-png-jpeg-2wbmp https://wiki.php.net/rfc/mcrypt-viking-funeral https://wiki.php.net/rfc/mcrypt-viking-funeral https://wiki.php.net/rfc/removal-of-deprecated-features https://wiki.php.net/rfc/removal-of-deprecated-features https://wiki.php.net/rfc/deprecate_mb_ereg_replace_eval_option https://wiki.php.net/rfc/deprecate_mb_ereg_replace_eval_opti...

by zzt123 5y ago

It makes me wonder if there’s a mysql_fake_escape_string or mysql_doesnt_actually_escape_string function. And why those functions would even exist in a language.

hnick 5y ago

It exists because "mysql_escape_string() does not take a connection argument and does not respect the current charset setting."

zzt123 5y ago
I thought the security of escaping is dependent on not having mismatched charsets? In which case, not respecting charset settings seems potentially not actually escaping? Seems like a strange function to have, although I could be foggy on my charsets.
- hnick 5y ago
  PHP (and old languages in general) are full of ASCII-only English-centric assumptions. I think both functions are now considered deprecated since we have even more variations like mysqli_real_escape_string (or just use PDO with bound params).
- SilverRed 5y ago
  It shows the culture in PHP. They would rather keep a function around that doesn't work properly just so existing code still works instead of making everyone test that the new function works.
  - ericbarrett 5y ago
    As another commenter points out, this is actually a quirk of the underlying MySQL C library, which has (or had) both functions.
  - gregjor 5y ago
    It shows a trade-off between arbitrarily breaking code in production or not. Lots of PHP sites are hosted on services that don’t give the programmer control over the PHP version. If the hosting provider upgrades and breaks a bunch of sites that’s a problem every bit as serious (to the site’s owner) as unescaped HTML opening up XSS attacks.
    - SilverRed 5y ago
      This is not sustainable or a desirable thing to keep. By accepting this state of things, no security fix with breaking changes can ever be implemented.
      - gregjor 5y ago
        With all respect your comment is both arrogant and unrealistic. Exactly how do we not accept this state of things? No one claims it's desirable, it just is: bad code is out there, and it's not easy to fix. What would you tell a small business that relies on clunky 10-year-old code to run their business? To rewrite it in a more modern language at huge expense and risk (given that a majority of rewrite projects fail)? Can you guarantee the new thing won't be just as obsolete and vulnerable and buggy in ten years? These kinds of problems -- poorly-written and vulnerable code, amateur programmers, lack of professionalism, maintaining back-compatibility with an installed base -- are not specific to PHP. They afflict the entire software industry, and always have. Who could have seen into the future back in 2000 (when I first got exposed to PHP) that a new site would get probed by an army of bots within five minutes of going live? Or that it would be even harder today than back then to find and hire experienced programmers? PHP has had many security fixes implemented since the early releases, but how can anyone force users of an open-source language to upgrade for their own good? Or pay someone to ferret out and fix vulnerabilities they have never got hit by? Even brand new code has this problem. Look at all of the cryptocurrency code written in the last few years. We read about hacks and thefts and vulnerabilities every day, and that was written by supposedly smart people with access to modern languages and with knowledge of the contemporary security issues. And it still gets hacked. If we knew how to write perfect code that would still be perfect into the future I'm sure we would do that but until then we'll have to live with what we have. So far it has been sustainable, just less than optimal, if by optimal we mean what we can imagine rather than what we, as programmers, actually deliver.
  - paulddraper 5y ago
    https://www.reddit.com/r/ProgrammerHumor/comments/8667lt/stackoverflow_has_become_sentient/ https://www.reddit.com/r/ProgrammerHumor/comments/8667lt/sta...
  - heurisko 5y ago
    That's not completely true. Over its evolution, PHP has removed some functions completely to provide better and more secure functionality, such as mysql_* in PHP 7.
  - tored 5y ago
    No, every PHP release deprecates functions or fixes functions that is either considered bad or not working as intended. Quick search & I found these (note that some of the rfc's include multiple deprecations), but there is more if you bother to actually look. Stop spreading misinformation. https://wiki.php.net/rfc/deprecations_php_8_1 https://wiki.php.net/rfc/deprecations_php_8_1 https://wiki.php.net/rfc/deprecations_php_7_4 https://wiki.php.net/rfc/deprecations_php_7_4 https://wiki.php.net/rfc/deprecations_php_7_3 https://wiki.php.net/rfc/deprecations_php_7_3 https://wiki.php.net/rfc/deprecations_php_7_2 https://wiki.php.net/rfc/deprecations_php_7_2 https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7 https://wiki.php.net/rfc/remove_deprecated_functionality_in_... https://wiki.php.net/rfc/deprecate_curly_braces_array_access https://wiki.php.net/rfc/deprecate_curly_braces_array_access https://wiki.php.net/rfc/ternary_associativity https://wiki.php.net/rfc/ternary_associativity https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_a... https://wiki.php.net/rfc/deprecate-png-jpeg-2wbmp https://wiki.php.net/rfc/deprecate-png-jpeg-2wbmp https://wiki.php.net/rfc/mcrypt-viking-funeral https://wiki.php.net/rfc/mcrypt-viking-funeral https://wiki.php.net/rfc/removal-of-deprecated-features https://wiki.php.net/rfc/removal-of-deprecated-features https://wiki.php.net/rfc/deprecate_mb_ereg_replace_eval_option https://wiki.php.net/rfc/deprecate_mb_ereg_replace_eval_opti...