Slashdot Mirror

← Back to Stories (view on slashdot.org)

'Month of PHP Security' Finds 60 Bugs

Posted by kdawson on from the new-mops-sweep-clean dept.

darthcamaro writes "More than 60 bugs were reported in PHP over the last 30 days by the Month of PHP Security project. Most of the flaws, however, are ones that developers themselves can protect against with proper coding practices, according to Andi Gutmans, CEO of commercial PHP vendor Zend. He argues that PHP security is a matter of setting expectations. In his view, PHP — like all development languages — is only as secure as the code developers write with it. 'People should not expect PHP to be able to enforce security boundaries on a developer [who] has permissions to run custom PHP code,' Gutmans said. 'It's an inherently flawed scenario — and it's the wrong layer to protect in. People must rely on properly configured OS-level permissions for securing against untrusted developers.' Gutmans also praised the MOPS effort for elevating the profile of PHP security throughout the community, and for responsibly alerting the PHP project first with the bugs they found."

6 of 120 comments (clear)

  1. One of the biggest problems is configurability by suso · · Score: 5, Interesting

    Sorry this is long, I could probably write a whole dissertation on my thoughts on PHP though.

    I've been developing in PHP since version 2 way back in '97 and I've always felt that one of PHP's biggest downfalls is that it has a configuration file. I understand that it has more to do with its origins as an Apache module, but I can't think of many modules or programming languages that are so customizable as PHP is. Over the years this has led to different schools of programmers choosing one setting or another and chastising people who use a different setting.

    Another big problem is that the core developers don't seem to get just how large the PHP community is. I found out some months ago that they were deprecating the ereg/POSIX regex set of functions in 5.3 and will be removing them in 6. I bought up on the mailing list that I think this is too quick of a time table for it being removed and that they should have it marked deprecated for at least 1 major version before removing it. Their excuse was that they really wanted to get UTF-8 support in PHP (a commendable goal) and the ereg functions weren't compatible and are also too slow. So now they are pushing the preg functions which are based on PCRE. Ironically all this time I've been avoiding the preg functions because I figured they were the more likely candidates to go away.

    And I'm not alone. Many many people out there have been using ereg in lots of code over the past decade and its going to be a huge shock for them when it comes time to switch suddenly. When 50%+ of the dynamic web uses PHP, this is going to cause lots of problems over the next 5-10 years.

    Yes yes, I know that there is work on a PEAR module to substitute the functionality of ereg, but my point is that the core developers seem to be in their own world and aren't thinking about the overall affects of their decisions and how far reaching they are.

    1. Re:One of the biggest problems is configurability by ceeam · · Score: 2, Interesting

      Any sufficiently useful in real life set of libraries suffers from the same problems.

    2. Re:One of the biggest problems is configurability by Quirkz · · Score: 5, Interesting

      "Who would begin a greenfield web application in PHP when you have Python/Ruby/(kinda) Perl?" These are all strong languages. Ruby is fascinating, though it's only now coming into its own.

      Well, I'm one of those people. In college I was trained in Fortran and then C++, and PHP has always seemed pretty friendly and intuitive in comparison with those. At least on the surface other than minor differences in syntax I could transition from one to the other to the next without too much difficulty.

      Every time I've looked at Perl, it's been downright indecipherable. I've edited a few existing scripts, tried reading not one but two books on it, and mostly I walked away feeling just as confused as when I started.

      As for Ruby and Python, when I started needing to code web applications, I'd never heard of them. They may be coming into their own now, but why should I start over with a new language when I can already do what I want with PHP? I don't know much about either, but at least peripherally I've been confused by some impression that with Ruby there are varying implementations (on Rails versions, versus who knows what else), and Python being the frequent butt of jokes here on slashdot hasn't ever made me want to research it to find out more.

      It may be a poor excuse, but that's why I'd start my next project in PHP. You may call it prejudice and ignorance against other languages; I call it being happy with what's been working just fine for me over the past decade.

      --
      The Quirkz Handbook of Self-Improvement for People Who Are Already Pretty Okay
    3. Re:One of the biggest problems is configurability by Parker+Lewis · · Score: 2, Interesting

      This it's not true on the real world. PHP can be configurated in too differente ways that you cannot guarantee almost anything will work on a different host machine. I code in PHP the most part of the time, and there is almost nothing that can be assumed as "write once, run anywhere".

  2. Re:Doing something about it. by ianpatt · · Score: 2, Interesting

    The PHP developers didn't find these bugs, Stefan Esser did. (see http://php-security.org/)

    The fact that one of the bugs still remains from his original /2007/ Month of PHP Bugs shows that the PHP developers are clearly not doing a thorough job.

  3. Re:Proper Coding Practices by webbiedave · · Score: 2, Interesting

    proper coding practice != workaround