3 ms·

It will never be secure unless you do it at the system / language level.

tyingq 9y ago
Many of the PHP issues I see cited aren't unique to PHP, but more unique to it's heavily neophyte centric user base. For example...there's nothing about current day PHP that makes it more susceptible to SQL injection than any other dynamically typed language with easy string interpolation. And the official PHP docs do guide you down the right path for SQL.
- anonymousDan 9y ago
  Hmm, I distinctly remember seeing a talk from the Chaos Computer Club Congress about how the PHP language is fundamentally broken in terms of security in comparison to other scripting languages. Edit: Apologies it was actually Perl (title "The Perl Jam"). In any event well worth watching if you have the time!
  - kbenson 9y ago
    I remember that. That is not a good talk. That the software had those errors sucks, but it's not a fundamental problem with Perl, but in how people had designed their internal APIs. In some cases he was citing problems in a module that was in core, but had long been noted to have problems and was not considered acceptable to use in anything except a quick and dirty script (and has since gone through a long deprecation cycle and finally been removed (CGI). What the talk really exposed was a few similar bugs found in various projects (which is good!), and exposed a fundamental misunderstanding of a language by the researcher due to unfamiliarity. This was all covered in depth here at the time.[1] 1: https://news.ycombinator.com/item?id=8813479 https://news.ycombinator.com/item?id=8813479
    - anonymousDan 9y ago
      Interesting. What about his follow up talk the next year where he rebutted some of those rebuttals as it were: https://media.ccc.de/v/32c3-7130-the_perl_jam_2 https://media.ccc.de/v/32c3-7130-the_perl_jam_2
CiPHPerCoder 9y ago
And we've been working on that. * https://wiki.php.net/rfc/libsodium https://wiki.php.net/rfc/libsodium (PHP 7.2) * https://wiki.php.net/rfc/mcrypt-viking-funeral https://wiki.php.net/rfc/mcrypt-viking-funeral (PHP 7.1) * https://wiki.php.net/rfc/random-function-exceptions https://wiki.php.net/rfc/random-function-exceptions (PHP 7.0, largely the result of a mailing list discussion critiquing the original implementation of the new CSPRNG functions) There is plenty more we want to work on in the coming months.
- mtgx 9y ago
  How about Noise? http://noiseprotocol.org/ http://noiseprotocol.org/
  - CiPHPerCoder 9y ago
    That's more of a "open source library" goal of mine: https://github.com/paragonie-scott/public-projects/issues/6 https://github.com/paragonie-scott/public-projects/issues/6
- kpcyrd 9y ago
  An overdue step would be an interface to execve that isn't based on a single string, but uses actual lists. I recall the python docs have a big red warning box that you can enable shell-style-single-string mode instead of a list, but it's highly dicouraged due to security problems. php has about 5 ways to execute programs, but all of them enforce this insecure interface.

Many of the PHP issues I see cited aren't unique to PHP, but more unique to it's heavily neophyte centric user base. For example...there's nothing about current day PHP that makes it more susceptible to SQL injection than any other dynamically typed language with easy string interpolation. And the official PHP docs do guide you down the right path for SQL.

anonymousDan 9y ago
Hmm, I distinctly remember seeing a talk from the Chaos Computer Club Congress about how the PHP language is fundamentally broken in terms of security in comparison to other scripting languages. Edit: Apologies it was actually Perl (title "The Perl Jam"). In any event well worth watching if you have the time!
- kbenson 9y ago
  I remember that. That is not a good talk. That the software had those errors sucks, but it's not a fundamental problem with Perl, but in how people had designed their internal APIs. In some cases he was citing problems in a module that was in core, but had long been noted to have problems and was not considered acceptable to use in anything except a quick and dirty script (and has since gone through a long deprecation cycle and finally been removed (CGI). What the talk really exposed was a few similar bugs found in various projects (which is good!), and exposed a fundamental misunderstanding of a language by the researcher due to unfamiliarity. This was all covered in depth here at the time.[1] 1: https://news.ycombinator.com/item?id=8813479 https://news.ycombinator.com/item?id=8813479
  - anonymousDan 9y ago
    Interesting. What about his follow up talk the next year where he rebutted some of those rebuttals as it were: https://media.ccc.de/v/32c3-7130-the_perl_jam_2 https://media.ccc.de/v/32c3-7130-the_perl_jam_2

CiPHPerCoder 9y ago

And we've been working on that. * https://wiki.php.net/rfc/libsodium https://wiki.php.net/rfc/libsodium (PHP 7.2) * https://wiki.php.net/rfc/mcrypt-viking-funeral https://wiki.php.net/rfc/mcrypt-viking-funeral (PHP 7.1) * https://wiki.php.net/rfc/random-function-exceptions https://wiki.php.net/rfc/random-function-exceptions (PHP 7.0, largely the result of a mailing list discussion critiquing the original implementation of the new CSPRNG functions) There is plenty more we want to work on in the coming months.

mtgx 9y ago
How about Noise? http://noiseprotocol.org/ http://noiseprotocol.org/
- CiPHPerCoder 9y ago
  That's more of a "open source library" goal of mine: https://github.com/paragonie-scott/public-projects/issues/6 https://github.com/paragonie-scott/public-projects/issues/6
kpcyrd 9y ago
An overdue step would be an interface to execve that isn't based on a single string, but uses actual lists. I recall the python docs have a big red warning box that you can enable shell-style-single-string mode instead of a list, but it's highly dicouraged due to security problems. php has about 5 ways to execute programs, but all of them enforce this insecure interface.