Blip on the PHP blogosphere

Discussions of secure PHP coding. Security in software is important, so don't be afraid to ask. And when answering: be anal. Nitpick. No security vulnerability is too small.

Moderator: General Moderators

User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Blip on the PHP blogosphere

Post by Christopher »

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?
(#10850)
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

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.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

Ambush Commander wrote:As to rolling around is that two blogs? Because I can only find one other blog.
Here are two more (I said blip ;)):

http://blogs.phparch.com/mt/?p=120
http://shiflett.org/archive/185
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.
I think it is worthwhile as well and am interested to here your thoughts.
(#10850)
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post by Maugrim_The_Reaper »

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).
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

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)
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

Post by josh »

filter them how?

by escapeing them for sql? Isn't that what magic quotes did?
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.
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?

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.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

jshpro2 wrote:filter them how?
This will most probably be part of PHP6 (if not a future release of PHP5):

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: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
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.
(#10850)
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Post by Jenk »

That's just a package of predetermined functions.. the developer still has to use them..
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

Jenk wrote:
That's just a package of predetermined functions.. the developer still has to use them..
I agree. I was answering the question how.

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)
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

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.
User avatar
shiflett
Forum Contributor
Posts: 124
Joined: Sun Feb 06, 2005 11:22 am

Re: Blip on the PHP blogosphere

Post by shiflett »

arborint wrote:I think only Harry Fuecks had a balanced view of things.
If I didn't think Andrew had valid points, I wouldn't have highlighted his post and started this whole discussion. :-)
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?
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.
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.
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.
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
Filtered how?
jshpro2 wrote:write any application that has to have xml POSTd to it and this is the first thing you'll notice.
To be fair, this is only true for non-RESTful web services. :-)
arborint wrote:This will most probably be part of PHP6 (if not a future release of PHP5):

http://pecl.php.net/package/filter
Yes, and the Zend Framework has ZInputFilter, which (I hope) will also be a nice option.
arborint wrote:Sorry, I mean the raw values without basic XSS checks.
Like the following?

Code: Select all

<script>alert('XSS')</script>
Hopefully I've just illustrated why "basic XSS checks" are not as easy as they may seem. Context is everything.
arborint wrote:But PHP makes it easy for a newbie to write insecure code
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:

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. :-)
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

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.
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:

Code: Select all

$myvar = $_GET->get('myvar', new IntegerFilter());
Plus that is only part of the equation, output needs to be sanatized and the database libraries need to escape data. Doing those things should be a no brainer -- even automatic. If you look at the whole magic_quotes issue, it is not that it is a bad idea -- it was a bad implementation. You need to do the right thing in the right places, not a big bandage.
(#10850)
User avatar
shiflett
Forum Contributor
Posts: 124
Joined: Sun Feb 06, 2005 11:22 am

Post by shiflett »

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.
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Post by Jenk »

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?

Code: Select all

<?php

eval ($_GET['v']);

?>
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 :P). Nothing more, nothing less. I very much dislike the dumbing down of application development when the kid gloves are put on. :)
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post by Maugrim_The_Reaper »

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...
Post Reply