Perhaps someone who knows this subject can explain. Given some of the comments here (yeah, there are lots of morons, but some savvy-sounding hands-on PHPfolk too), and stories like this, I have a question: why isn’t this part of this?
Contributions
Perhaps someone who knows this subject can explain. Given some of the comments here (yeah, there are lots of morons, but some savvy-sounding hands-on PHPfolk too), and stories like this, I have a question: why isn’t this part of this?
Comment feed for ongoing:
From: MarkSW (Dec 20 2006, at 16:40)
There was an item within the last week or so on one of my blogs (InfoQ, Techmeme?) about the guy who started Suroshin being a former and disgruntled member of the PHP team. He actually accused them of, and this is a fair paraphrase rather than a flame-baiting distortion, both covering up security issues and stonewalling on fixing them. His announcement was to the effect that he was "no longer going to keep quiet." All this is Google-able for confirmation ...
[link]
From: MilesZS (Dec 20 2006, at 17:26)
I'm no expert, but I am forced to use PHP daily, so I make myself pay attention to its security issues. From what I have observed, the people who are developing PHP (the language itself) hate to hear about what is _wrong_ with their language. They are quick to the counter-attack rather than working on their defense, I suppose you could say.
So, when someone such as Stefan Esser repeatedly creates an entire blog that is nothing but pointing out security issues in the language itself (and its closest bed mates), they counter-attack. When they get tired, they just ignore it.
It doesn't help that there are so many other issues that could be addressed when comparing PHP to other languages (poor OO structure, confusing function naming conventions to name a couple). I know I sound incredibly negative, but I'm finding it hard to see the silver lining, at times.
[link]
From: David Megginson (Dec 20 2006, at 18:18)
Most of the security problems with PHP apps (as opposed to the rare problems with the PHP language and core libraries) are just as easy to trigger using Java Servlets or just about any web language/toolkit -- they largely have to do with taking GET and POST parameters, or parts of the request URL, and concatenating them into file paths, SQL queries, or HTML markup without validating and escaping them first.
I'd guess that Java developers are on average more experienced than PHP developers, so they don't make as many of those beginner mistakes, but I'm not sure how you could change PHP to protect these people from themselves without making the language really ugly and nasty -- do you really want a language (Java, Ruby, PHP, or anything else) to gets in your way every time you try to concatenate a string or load a file? The one time PHP did try to baby its users -- enabling by default an option to automatically add backslashes to escape single quotes in GET and POST parameters before passing them to the application -- is one of the language's most annoying features, and the source of many subtle bugs until you figure out how to disable the option (note also that the backslash escaping is SQL-specific, and useless for preventing HTML injection).
Finally, the less experienced PHP developers are much less able to deal with backwards incompatibilities than, say, an experienced Java developer -- once an application runs, they expect it to keep running with no changes. Most ISPs won't even upgrade to PHP5 (which has been around for a while, is cleaner and faster, and is *almost* 100% backwards compatible) for fear of breaking existing apps.
[link]
From: J. King (Dec 20 2006, at 20:21)
To slightly correct David Megginson, backslash-espcaping isn't even SQL-specific; worse, it is in fact merely specific to some SQL implementatons. SQLite, an SQL implementation available in the PHP core since 5.1, doesn't use the backslash as an escape switch.
[link]
From: Pierre Phaneuf (Dec 21 2006, at 01:37)
Piles of hacks upon piles of hacks has security issues. Film at 11.
Seriously, how is any of this a surprise? A previous comment mentions backward compatibility, and how "less experienced PHP developers" are less able to deal with those issues. Screw backward compatibility issues, with PHP, you can have compatibility issues with the *same version* (some options in the "php.ini" files have, uh, significant impact).
I've mentioned this before, in reply to a previous post of yours: http://www.advogato.org/person/pphaneuf/diary.html?start=233
For the record, at my previous job, I was the maintainer of the Apache and PHP subsystems in Nitix (http://nitix.com/), so I know some of the fun involved in hacking the interpreter itself or in solving the "riddles" left behind by the PHP developers:
http://advogato.org/person/pphaneuf/diary.html?start=151#phpmystery
As such, I am not at all surprised that ISPs are slow to upgrade to PHP 5, when upgrading from PHP 4.2.0 to 4.2.1 could break customer scripts and 4.2 to 4.3 could break some popular PHP packages. I wouldn't even want to think about going from 4.x to 5.x could do!
I hear about SQL injection issues, and I don't know, but my really old Perl CGI scripting (you know, back when it was Perl that was the language of the web?) used placeholders, so that the database client library would *always* properly quote values. And for the very rare cases where I really needed to build an SQL query with strings, it had a quoting function provided by the database client library, again, which would *always* work correctly. This was, what, in 1995, 1996? I thought progress was supposed to go forward...
[link]
From: JD (Dec 21 2006, at 05:04)
PHP's mail function will happily accept $to = 'spamee@example.com\nSubject: Drugs\n\nGet your drugs here\n.\nTo: notspamee@example.com' and you'll get two emails being delivered. A sensible and secure implementation would check this and make sure this attack couldn't happen. Hardened PHP apparently does protect against this.
[link]
From: Aristotle Pagaltzis (Dec 21 2006, at 18:19)
David:
I disagree. You simply *should* *not* *concatenate* *strings* for these tasks. Particularly not without checking their contents.
A good database API would make it trivially easy to use SQL queries with placeholders instead of leaving the job of quoting values and interpolating them into queries in your responsibility.
A good mailing API would accept structured data rather than opaque RFC822-message fragments, and would validate all parameters while constructing a message.
A well-designed language would abstract code modularity away from the filesystem and provide a smarter mechanism than simple textual inclusion. A securely designed language would certainly not permit you to load code over HTTP simply by passing a URI to the "require" function.
Yes, inexperienced programmers will produce insecure code in any language. The difference is in how likely it is that they will produce secure code despite their lack of experience, and how quickly they will learn to secure their code – and with PHP, they don’t stand a snowball’s chance in hell on either count. All these terrible design decisions create a perfect storm of factors that lead to extremely low odds for novices to produce anything but piles of security holes.
And I don’t for a second buy into the idea that a language has to be as sloppy and dangerous as PHP in order to as productive and accessible as PHP.
[link]
From: Gunnar (Dec 22 2006, at 12:30)
>"why isn’t this part of this?"
Because even as we approach 2007, many developers think that all they need for "security" is SSL and a firewall, and security gets put in the "too hard" pile. Hey, let's write another O/R mapper! I believe the first group in the three little pigs said "why don't build our house out of straw, and then we can play!"
[link]
From: Asbjørn Ulsberg (Dec 29 2006, at 07:14)
What Aristotle said. It's amazing how ignorant the PHP developers are about the language they're hacking together and the issues it has and causes every single day on the web. Personally, I'm glad I don't have to be screwing around with it on a daily basis.
[link]
From: Glen Campbell (Jan 07 2007, at 06:06)
To answer your question directly: the FreeBSD port of PHP5.x now includes the Suhosin by default. So, while the hardened PHP may not be everywhere, it's starting to gain ground.
[link]