Terry Chay has written up a detailed response to common complaints about PHP security. He addresses many of the common complaints thrown at PHP such as PHP’s use of the global namespace, PHP’s decision to turn off register_globals in 4.2, and the problems with features such as stripslashes and magic quotes (which I’ve blogged about previously).
One of the interesting points he makes is that there is a shifting balance between ease of use and flexibility on the one hand, and security on the other. Much of PHP’s success can be attributed to its ease of use in early versions. Terry argues that, relative to other languages, PHP is very much focused on flexibility, and that the only solution to the possible security implications this can generate is better education. He puts in a plug for the PHP Security Consortium who publish material to educate other PHP users about best programming practices in order to ensure security (led by Chris Shiflett, the group has published a guide available in HTML or other formats).
The idea that a lack of security can be justified by ease of use is one that I’m not entirely easy about, as part of me feels that in an ideal world, the language should make sure that the easiest way to do things is also the right way. But, of course, the issues are complex and he is, after all, speaking in generalisations, on the defensive over similar generalisations and absolutes levelled at PHP on Slashdot.
Related posts:
- Webmail Security Breaches Continue Hackers and criminals are exploiting the accounts of the 30,000...
- Security Tip: Update Your Flash Player Adobe applications come under more fire with alerts of serious...
- Microsoft Security Essentials: a Review Microsoft Security Essentials may be free but is it any...
- Build a Buzzword Bingo Card in PHP Bored in meetings? Worry no longer. Raena demonstrates how to...
- Free PHP Webinar: How to Increase Performance with Caching Zend are running a free webinar today, with a live...
Security should be a concern to every devloper. There are two new books coming out his fall on PHP Security. One from Chris Shiflett (http://www.bookpool.com/sm/059600656X) and one from Chris Snyder(http://apress.com/book/bookDisplay.html?bID=437)
It’s a subject that was relegated to a few paragraphs in most books I’ve seen.
On a slight tangent, one thing I’d like to see is an article about how to use PEAR packages to avoid PHP security issues.
I use Pear DB, QuickForm, and others from time to time. They go through a quality process but what I REALLY want to know if if I use them, do I still need to escape html characters as Schiflet says to. If I use DB AutoPrepare & AutoExecute, do I still need to filter my user input?
Pear is a great effort and I appreciate all the people who put work into it.
August 11th, 2005 at 9:19 am
Like Einstein said and I agree: everything should be made as simple as possible, but not more.
Therefore like you said, it should be simple to do, but if too much simple that it “leaves out” thing, it is bad.
However, as for PHP or any other language. There is problem that come with how you deal with your data. If you need to encode an html output, if you need to disallow javascript in your comments system, etc. That is your job, not the programming language one. A programming language can say “I escape all output”, but then you need an unescaped output. There is no right choice, except maybe do the choice that is most logical or the most used.
Accessing a box that got all the POST variable is logic and still simple. Register Globals is disturbing as it could affect value in your script or create a load of variables. Then that is a good decision to leave it out.
August 11th, 2005 at 2:30 pm
I wonder what kind of language is not as flexible as php, it does not seem to me it has many particulare features that any other scripting language does not have.
August 11th, 2005 at 2:35 pm
I was much more interested in the scalability discussion than the one concerning security at slashdot. I question the scalability of php projects more than security as the former is not so easily fixed. Scalability is more related to design where as security is more related to code. I can fix bad code much more easily than a bad design if it’s even worth the effort of fixing in the first place. Of course, in this era of extreme and agile programming, design is a secondary concern and maybe that should change?
As always the security and scalability is the responsibility of the programmer in the end. Blaming the language used is like a carpenter blaming his or her hammer for his poor workmanship.
August 12th, 2005 at 5:45 pm