Hacker News new | ask | show | jobs
by gkwelding 3852 days ago
"My experience with hosting PHP apps has historicity been one of fending off security issues"

Unfortunately PHP seems to have this reputation. It's not so much the language that is the problem but the people using it. PHP typically had such a low bar to entry that literally anyone could pick it up and do anything and everything with it. And quite frankly there were (and still are) a lot of beginner tutorials out there encouraging people to do very stupid insecure stuff. It now seems to be an image that stuck.

If you take a look at the OWASP Top 10, and any big data breaches recently, they are all caused by human error. SQL injection being the major culprit.

3 comments

That explanation is technically true but it's like blaming human error for factory workers being injured by a machine without safety guards. Since it happens so frequently you have to ask how the language could change to make it less common.

Most of it comes down to being developed ad-hoc with convenience for solving a simple problem right now as the main driving force.

Remember register globals? That was a minor convenience which took ages and millions of exploits to be removed – I remember lobbying for that in the late 90s.

Similarly, you mentioned SQL injection. Unlikely as this may seem now, there was a time when things like prepared statements were an exotic new feature with limited library support and a certain school of programmer thought they were probably too slow. The docs and most tutorials didn't mention things like validation or escaping prominently so most PHP developers were trained to slop everything into strings. When PDO came along, this persisted for too long as well and even after they started recommending placeholders you didn't get something like all of the mysql functions saying “Don't use this, it's unsafe”. I've heard that this has improved but it's been years since I needed to look.

Similarly, look at the lax attitudes toward error handling — errors are ignored by default, database errors or warnings have to be explicitly requested, etc. That's “easier”, saving whole seconds of learning at the expense of millions of successful exploits and hours spent debugging.

Not the language?

PHP is the only lasting language where making code that allows SQL injection is easier than code that forbids it.

PHP includes all the worst practices you'll find on any languages. Javascript has the eval problem - PHP has it too; Perl have the too fluid type system where you can't specify anything - PHP too, except that it lacks Perl's tainted mode; Asp made it easier to create code subject to XSS than code that isn't and is subject to directory traversal - guess what, PHP copied it... and the list goes on and on.

This release fixes still some more problems, but PHP will never become a good language.

> PHP is the only lasting language where making code that allows SQL injection is easier than code that forbids it.

Pretty sure this is true for any language, the key difference is education. When learning JDBC for example, you're taught to use prepared statements with params vs. string concatenation.

It's not just about education. PHP encourages bad practice. The language is implemented by people who haven't learned from the past 30 years of language design. It's made available to beginners and presented as "easy" when dealing with all the gotcha's is everything but. Etc. Sure, you can learn how it works and a competent person could probably write safe code with it (given enough time). But it's really a dangerous language, the use of which should be discouraged. Better alternatives exist.
Heck, a very popular Java book (Android programming specifically) has examples of database queries using concatenation (and hence SQLi).
fending off security issues

This is my general experience with all platforms and operating systems. You have to keep up to date.

PHP was early on the web scene, and like ASP it encouraged a lot of bad practices (like concatenating user input into SQL strings) before people knew better.

These days, in the hands of a competent developer, it's no worse than any other mainstream stack as far as security goes.