On Mon, Jul 11, 2016 at 11:44:58AM -0400, D. Hugh Redelmeier via talk wrote:
I don't use PHP so my opinion isn't reliable.
Historically it has been too hard to write secure code in PHP. Or perhaps it was the culture. I know that things have gotten better over the years. Culture is pretty resistant to change.
Actually I think the right way to word it is: It is too easy to make it insecure in php. It is perfectly possible to write secure php code. It just happens to be stupidly easy to write insecure php. The fact everywhere in php that takes a file accepts anything that is a valid url and does "the right thing" with it, makes it possible to do things like: get an argument from the user include(argument) Sure if you for some reason want to have say 3 different things you can do with a selection, and then include the implementation of each of those 3 things so you can do something generic that uses one of those 3 methods, then that might seem like a good idea. Of course since you can't trust the user, and they could send you anything, not just what your page gives as options, they can now send you a url, instead of a filename that is local, and make you include that instead. So if you happen to think that's a good design for making something modular, and you don't realize php really means it when it says it is consistent and allows all types of file specifications everywhere, then you can easily write something very insecure without realizing it. Some of what has made php have a bad reputation does come down to some security issues in how it handles libraries and plugins, but a lot of the problems are really just that people don't know what they are doing and it makes it very easy to make something that "works" even if it is also very insecure in non obvious ways. You can do some of those stupidities in other languages, but usually you actually have to try a bit harder to get bitten. Trusting user input and using it directly is pretty much always a bad idea in any language. -- Len Sorensen