Blip on the PHP blogosphere
Moderator: General Moderators
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Blip on the PHP blogosphere
I noticed that there has recently been, as someone called it, a "blip on the PHP blogosphere" regarding PHP Security. It started with this blog (http://www.greebo.net/?p=320) and rolled around a little. Check out PlanetPHP for more. The usual suspects defended PHP, said it was nonsense, and everything was fine. I think only Harry Fuecks had a balanced view of things.
So what do you think? It is OK for security be as arcane as it is in PHP, or should there be more built-in security for the common cases? It seems like PHP is going that way anyway with various dreadful config setting planned to disappear.
And how does the current complexity of PHP security square with Zend's "Extereme Simplicity" attitude? Should the 20/80 rule apply to PHP security too?
So what do you think? It is OK for security be as arcane as it is in PHP, or should there be more built-in security for the common cases? It seems like PHP is going that way anyway with various dreadful config setting planned to disappear.
And how does the current complexity of PHP security square with Zend's "Extereme Simplicity" attitude? Should the 20/80 rule apply to PHP security too?
(#10850)
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
As to rolling around is that two blogs? Because I can only find one other blog. However, since a lot of our traffic consists of newbies, I think it's a worthwhile question to ask. I'm thinking about it.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Here are two more (I said blipAmbush Commander wrote:As to rolling around is that two blogs? Because I can only find one other blog.
http://blogs.phparch.com/mt/?p=120
http://shiflett.org/archive/185
I think it is worthwhile as well and am interested to here your thoughts.Ambush Commander wrote:However, since a lot of our traffic consists of newbies, I think it's a worthwhile question to ask. I'm thinking about it.
(#10850)
- Maugrim_The_Reaper
- DevNet Master
- Posts: 2704
- Joined: Tue Nov 02, 2004 5:43 am
- Location: Ireland
Sounds like a speech from frustration. PHP made some bad decisions (we all know that - many are being corrected in PHP6). Point is any security mailing list (I use phpsec) can be scanned, and the vulnerabilities are always a mix of developer error and maybe a PHP setting.
Blaming the entire language so broadly is a little too far. Developers are responsible for most security breaches in some way - at the very least they make unnoticed errors, at worst they lack the experience and rely too much on manual examples that don't mention the security implications of a some code example. Sure PHP can contribute with register globals, magic quotes or others being set at the wrong time, when developers don't anticipate it.
Some PHP decisions were pretty bad. But that's common knowledge, and they're up for being fixed. We also have the Hardened PHP patch for true followers...
The best way *still* to improve overall security is to educate users. Get them to take a consistent approach to security rather than pushing into an application as an afterthought (stupid security breaches happen all the time - some applications are repeating offenders, surely a sign they're not being consistent - just patching at random or at need).
Blaming the entire language so broadly is a little too far. Developers are responsible for most security breaches in some way - at the very least they make unnoticed errors, at worst they lack the experience and rely too much on manual examples that don't mention the security implications of a some code example. Sure PHP can contribute with register globals, magic quotes or others being set at the wrong time, when developers don't anticipate it.
Some PHP decisions were pretty bad. But that's common knowledge, and they're up for being fixed. We also have the Hardened PHP patch for true followers...
The best way *still* to improve overall security is to educate users. Get them to take a consistent approach to security rather than pushing into an application as an afterthought (stupid security breaches happen all the time - some applications are repeating offenders, surely a sign they're not being consistent - just patching at random or at need).
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
I agree that "Blaming the entire language so broadly is a little too far. " But I am wondering about things like $_GET, $_POST, $_REQUEST, $_COOKIET, $_SERVER passing raw values from the client though by default. If they filtered by default, but advanced users could still get to the raw values -- that might have been a better decision when they were added to the language. You can see that languages where those things are object might have and easier time dealing with these things.
(#10850)
filter them how?
by escapeing them for sql? Isn't that what magic quotes did?
It's fine the way it is, if you want your data escaped you can do it yourself, it is common knowledge by now that user-inputs must be filtered. Any book / tutorial you can find will explain this.
Even the PHP manual explains it:
http://www.php.net/manual/en/security.variables.php
http://www.php.net/manual/en/security.d ... ection.php
http://www.php.net/manual/en/security.filesystem.php
By the way, $_GET, $_POST, etc are not the raw values per se, they are arrays built from the key value pairs, the raw post data for example is in:
$HTTP_RAW_POST_DATA
write any application that has to have xml POSTd to it and this is the first thing you'll notice.
by escapeing them for sql? Isn't that what magic quotes did?
performing htmlentities() on them? What happens when new-comers start freaking because the blog they coded is taking html literally when they want to allow html?Magic Quotes is a process that automagically escapes incoming data to the PHP script. It's preferred to code with magic quotes off and to instead escape the data at runtime, as needed.
It's fine the way it is, if you want your data escaped you can do it yourself, it is common knowledge by now that user-inputs must be filtered. Any book / tutorial you can find will explain this.
Even the PHP manual explains it:
http://www.php.net/manual/en/security.variables.php
http://www.php.net/manual/en/security.d ... ection.php
http://www.php.net/manual/en/security.filesystem.php
By the way, $_GET, $_POST, etc are not the raw values per se, they are arrays built from the key value pairs, the raw post data for example is in:
$HTTP_RAW_POST_DATA
write any application that has to have xml POSTd to it and this is the first thing you'll notice.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
This will most probably be part of PHP6 (if not a future release of PHP5):jshpro2 wrote:filter them how?
http://pecl.php.net/package/filter
Which I think shows the point. How many newbies in this forum have read that section (or even know it exists) nevertheless understand it.jshpro2 wrote:Even the PHP manual explains it:
http://www.php.net/manual/en/security.variables.php
http://www.php.net/manual/en/security.d ... ection.php
http://www.php.net/manual/en/security.filesystem.php
Sorry, I mean the raw values without basic XSS checks. Other languages, Java and .NET for example, do this. I agree that ultimately it is the programmer's responsiblity. But PHP makes it easy for a newbie to write insecure code -- in fact insecure is the standard looking at the code that people post.jshpro2 wrote:By the way, $_GET, $_POST, etc are not the raw values per se, they are arrays built from the key value pairs, the raw post data for example is in:
$HTTP_RAW_POST_DATA
(#10850)
That's just a package of predetermined functions.. the developer still has to use them..arborint wrote:http://pecl.php.net/package/filter
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
I agree. I was answering the question how.Jenk wrote:That's just a package of predetermined functions.. the developer still has to use them..arborint wrote:http://pecl.php.net/package/filter
And I think the filter extension show how old-fashioned the PHP Core Group is. There is no OO interface with a pluggable filter interface and no FilterChain -- which is probably the state-of-the-art these days.
(#10850)
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
This I believe:
It's because a FilterChain is way too much abstraction for newbie programmers to wrap their heads around with. The logical progression is first echo'ing stuff as conveniently as possible, then passing the stuff through a quick function that fixes stuff, and then finally comprehensive input filtering frameworks. Show them a filter chain and they'll go "Huh?" Plus, patterns usually must be finished in the context of your *project*, and anything besides algorithms for the stuff would probably be a framework and does not belong in language.
It's because a FilterChain is way too much abstraction for newbie programmers to wrap their heads around with. The logical progression is first echo'ing stuff as conveniently as possible, then passing the stuff through a quick function that fixes stuff, and then finally comprehensive input filtering frameworks. Show them a filter chain and they'll go "Huh?" Plus, patterns usually must be finished in the context of your *project*, and anything besides algorithms for the stuff would probably be a framework and does not belong in language.
Re: Blip on the PHP blogosphere
If I didn't think Andrew had valid points, I wouldn't have highlighted his post and started this whole discussion. :-)arborint wrote:I think only Harry Fuecks had a balanced view of things.
Absolutely. On the surface, it sounds like a bad idea, but it makes sense to focus on what's most important. Also keep in mind that the 80% to be addressed in the Zend Framework is 80% more than you have without it.arborint wrote:And how does the current complexity of PHP security square with Zend's "Extereme Simplicity" attitude? Should the 20/80 rule apply to PHP security too?
I agree with you, but I think Andrew's focus is that PHP can do more to help. I think the invalid arguments against PHP's security tend to blind us from the valid ones. Yes, it's possible to create extremely secure applications with PHP. It might also be possible for PHP to make this easier.Maugrim_The_Reaper wrote:Blaming the entire language so broadly is a little too far. Developers are responsible for most security breaches in some way - at the very least they make unnoticed errors, at worst they lack the experience and rely too much on manual examples that don't mention the security implications of a some code example.
Filtered how?arborint wrote:But I am wondering about things like $_GET, $_POST, $_REQUEST, $_COOKIET, $_SERVER passing raw values from the client though by default. If they filtered by default
To be fair, this is only true for non-RESTful web services. :-)jshpro2 wrote:write any application that has to have xml POSTd to it and this is the first thing you'll notice.
Yes, and the Zend Framework has ZInputFilter, which (I hope) will also be a nice option.arborint wrote:This will most probably be part of PHP6 (if not a future release of PHP5):
http://pecl.php.net/package/filter
Like the following?arborint wrote:Sorry, I mean the raw values without basic XSS checks.
Code: Select all
<script>alert('XSS')</script>I think this is Andrew's main point, and it's a valid one. It's also a topic I've been giving a lot of thought recently, particularly regarding what the Zend Framework can do to help. Andrew added some pretty thorough comments here:arborint wrote:But PHP makes it easy for a newbie to write insecure code
http://shiflett.org/archive/185
However, notice that he's comparing frameworks to PHP. As Marco noted, PHP is a foundation from which we can build. At that level, flexibility is very important. Many of the existing PHP frameworks, and certainly the upcoming Zend Framework, address many of Andrew's concerns.
He's now in touch with the PHP Group, so hopefully his other concerns can also be addressed. He's a smart guy and worth listening to. :-)
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
I don't know if they go "Huh?" I think they'd do what they do now: copy some code they saw somewhere, ask a question here, and say "Yeah, it works!" when they figured out how to do it. Looking at the questions in PHP forums, the problems is not a lack of intellegence -- it is a lack of exposure to better practices. And that's because PHP does not have a culture of better practices. Would there really be mass confusion if programmers saw:Ambush Commander wrote:It's because a FilterChain is way too much abstraction for newbie programmers to wrap their heads around with. The logical progression is first echo'ing stuff as conveniently as possible, then passing the stuff through a quick function that fixes stuff, and then finally comprehensive input filtering frameworks. Show them a filter chain and they'll go "Huh?" Plus, patterns usually must be finished in the context of your *project*, and anything besides algorithms for the stuff would probably be a framework and does not belong in language.
Code: Select all
$myvar = $_GET->get('myvar', new IntegerFilter());(#10850)
You make some good points, arborint.
Yes, a big part of the problem is the sheer volume of bad documentation. The trouble is that PHP has a culture that extends to before web application security was thought to be important. People learn bad practices from examples and then teach those bad practices to new developers. I think we're just now starting to see this pattern change, and more and more examples demonstrate secure programming practices. However, the evolution is slow and sometimes frustrating.
Regarding your other points, where should PHP draw the line between core features and userland features? I think this is a difficult question to answer.
Yes, a big part of the problem is the sheer volume of bad documentation. The trouble is that PHP has a culture that extends to before web application security was thought to be important. People learn bad practices from examples and then teach those bad practices to new developers. I think we're just now starting to see this pattern change, and more and more examples demonstrate secure programming practices. However, the evolution is slow and sometimes frustrating.
Regarding your other points, where should PHP draw the line between core features and userland features? I think this is a difficult question to answer.
My personal opinion is that none of this "blame" should be on PHP at all.. hell, would it be PHP's fault if I hosted a script like the following on the public domain?
no, it certainly would not. 
I think we are looking at this the wrong way completely (when I say we, I mean everyone) If there is a fault with the Zend engine itself that can be exploited, then yes - that is a PHP fault, otherwise it is all down to the developer.
I actually disagree with the "built in filtering" idea.. what happens if someone learns a few bits on PHP, it works "safely" then they go onto other languages and find a whole manner of holes in their logic..
I'm also a power freak, I want the code to do what *I* want it to do (within reason.. I'm not about to go and start entering 1's and 0's
). Nothing more, nothing less. I very much dislike the dumbing down of application development when the kid gloves are put on. 
Code: Select all
<?php
eval ($_GET['v']);
?>I think we are looking at this the wrong way completely (when I say we, I mean everyone) If there is a fault with the Zend engine itself that can be exploited, then yes - that is a PHP fault, otherwise it is all down to the developer.
I actually disagree with the "built in filtering" idea.. what happens if someone learns a few bits on PHP, it works "safely" then they go onto other languages and find a whole manner of holes in their logic..
I'm also a power freak, I want the code to do what *I* want it to do (within reason.. I'm not about to go and start entering 1's and 0's
- Maugrim_The_Reaper
- DevNet Master
- Posts: 2704
- Joined: Tue Nov 02, 2004 5:43 am
- Location: Ireland
A lot of the comments to referenced blogs mention a valid point - is PHP a language or a framework?
For myself its always been a language. Therefore by extension security is the developer's responsibility, or that of whichever framework they've chosen to use.
That said there is room for some minimal security measures in PHP itself. Take the recent change to header() as an example (see http://derickrethans.nl/php_442rc2_released.php ).
As for whether a deeper set security level is required - well, not so certain. The bits added in earlier times didn't go all that well
. Then again if you take the outlook of needing to do something to protect developers from themselves maybe...
I can't make a straightforward choice either way at least. For wiser minds than mine...
For myself its always been a language. Therefore by extension security is the developer's responsibility, or that of whichever framework they've chosen to use.
That said there is room for some minimal security measures in PHP itself. Take the recent change to header() as an example (see http://derickrethans.nl/php_442rc2_released.php ).
As for whether a deeper set security level is required - well, not so certain. The bits added in earlier times didn't go all that well
I can't make a straightforward choice either way at least. For wiser minds than mine...