Over the years I’ve been developing in PHP I’ve seen the number and impact of security exploits and issues on the web increase and even flourish. It’s everyone’s favourite game (I’m hardly innocent) to assign blame and PHP has proven an attractive target due it’s high profile presence on the web, its large body of inexperienced or just ill-educated programmers, and of course its infamous ease of misuse.

It’s always been interesting seeing how PHP and the broader community responds to these challenges (or not as the case may sometimes be) to quell the criticism and offer solutions. Some have backfired in spectacular style (magic quotes!) while others have introduced genuine improvement (no newlines in header()!). Unfortunately the nature of PHP as a programming language is that it’s easy to foul up. And this has inevitably left the responsibility of security completely up to the individual programmer. The results have been less than comforting, leaving an internet populated by God know how many insecure PHP scripts and application written by well meaning but woefully under educated programmers and casual users.

At the end of the day, programmers require education, experience and guidance before they finally hit the jackpot and learn about revolutionary concepts like input filtering, output escaping, mysql_real_escape_string(), Chris Shiflett’s website ;) . But the level of education doesn’t end with the revolution – beyond the horizon there awaits an entire world of odd animals like Code Injection, Path Disclosure, and my favourite – Unicode. Who’d have thought Unicode could be so cute, and such a problem for those reared on ASCII?

In any case, blaming stuff that goes wrong on PHP is the easy way out – PHP has historically offered honest and complete access to raw user input and doesn’t accept responsibility for reporting when you practice poor security. If you want to be a professional programmer, those problems are yours to solve, young Padawan. PHP has done it’s bit over time giving us the marvel of the filter extension, and adding all sorts of interesting INI settings to play with should a programmer bother to read the INI once in a while and contemplate unholy actions like changing anything after the “=” character. If your shared host’s name occupies a sentence with certain f*** or s*** words (the a*** word is generally rare though popular with “Father Ted” fans) you should of course do your homework and find a more flexible host where the INI file is editable (by some method) and file permissions are a bit less stupid.

This is old news of course. There are a few PHP Security books published you can easily order from Amazon, or if you still live in the stone age, the local bookstore. If adventurous, some of them can be purchased on the cheap as PDF files to feed to your printer or read from your PC. They all note the highlights, and go into detail where it matters and page count allows. Of course, we all know few PHP programmer actually read those books – many sit unread on the shelves of bookstores and sit huddled together in small groups staring at PHP programmers who never glance at them twice. Such is the problem of giving programmers sole authority over security – too many don’t feel any urgency to educate themselves. The result is well publicised – PHP applications litering the web with enough insecure code to depress many a security professional.

It’s perhaps symptomatic then to look at how the community reacts to the growing pressure to prioritise security and make it easier for programmers to implement measures against the common security exploit vectors. One example to take is the Zend Framework. Fast approaching the dubious “1.0″ version which means the API will finally remain stable and actually does not stand for any particular “completion” status – as mysterious as that might be (it’s kind of weird comparing Symfony’s 1.0 state to the ZF’s). In development for over a year, the Zend Framework has a mixed security bag on the basic task of accessing user input. On the one hand, there’s a set of neat classes called Zend_Validate which replace the now defunct and static heavy Zend_Filter_Input – on the other there’s no overall system for pulling these into a neat validator chain and forcing access through it to the relevant superglobals. In other words, it doesn’t add much beyond what direct procedural use of intval(), ctype, or those nifty PCRE functions offer. They might even be faster…and require less typing. Now the argument has inevitably erupted before on the mailing list, and a nebulous something will happen after the 1.0 release – proposals, reviews, all sorts of inevitably good advances – but the fact it’s still not present after over a year? Where was the urgency to add such a basic component to the framework? Already, I’ve seen three examples of programmers retrofitting their home brewed solutions into the framework as a consequence – programmers who care have no intention of using the current system when they’re already spoiled by frameworks like Symfony and it’s nifty YAML-based solution.

A second development worth a little verbose exploration is PHP’s core filter extension. Unfortunately I’m hitting the 1000 word count limit I need to set to reduce the risk of writing too much (okay, so we passed that limit a while back – shoot me!). In summary, the filter’s reception was less than lukewarm. It’s odd to see something so apparently useful given so little attention. It’s so bad in fact, that there’s a rollercoaster ride happening to invent solutions to allow applications pretend it doesn’t even exist. Honestly – the antics of PHP programmers get a little weirder with each passing year… I’ll be writing something on the filter extension at some point – it’s an under explored potential solution.

In conclusion (having broken that damn 1000 word limit), I’ll burn the edifice above and simply beg programmers who know they are behind the curve on security education in PHP to catch up. Don’t put it off and consider it a PITA since if you intend to carve a profitable slice of work from the PHP market you better know your stuff – and not just bits and pieces. On your next project stick a big label at the top of the milestone list which says “Implement basic security” – it’s often surprising at how focusing on security up front and as part of the overall application design can encourage simpler, and very importantly, consistent solutions. Leaving it to the end, or as a low priority will predictably encourage inconsistency which makes mistakes easier to make.

1,130 words… I think I have a charity box I owe €1.30 to for that ;) .

Related posts:

  1. Zend_Yaml Proposal added
  2. YAML for the Zend Framework – well, maybe…
  3. Doing the Poka-Yoke