PHP Security, Authorative Knowledge and Combining Forces
NIST NVD 2006 Data - Ed Finkler (Photo credit: tychay)
It's about a year since I sat down, quite despondant and discouraged, faced with the seemingly insurmountable task of overcoming PHP's culture where it concerns PHP Security. Over the previous couple of years I had accepted the status quo, trusted in PHP and its programmers to be secure, reported vulnerabilities responsibly, and made occassional forays into research concerning how well PHP programmers actually practiced security. All the while, my blog activity fell, my open source contributions diminished to piecemeal status, and I invented a new persona, Mr. Grumpy, with which to terrify my foes (and optionally dispatch them with fatal fits of laughter). Mixing humour and the deadly serious has produced some of my better writing.
It turns out that PHP Security is a time consuming topic and my return on investment was, shall we say, far from satisfactory. That experience was doubtlessly necessary. Once you start to dig around PHP Security in earnest, you begin to notice trends and patterns in how programmers behave and accumulate knowledge. The most obvious feature of PHP culture is that we do not have an active aoleadershipa in security. There is no appeal to authority in PHP security debates, only personal opinions informed by a nebulous entity called aoTheya. There are individuals that I have learned to trust and that's about as far as we can go.
When I actually spent time considering my experiences, I realised I had been taking the wrong approach in trying to improve PHP Security by treading too lightly. PHP security problems are like the moving tide. You can stand on a beach and screech like a baboon all day long attempting to stop them. The tide won't care. However, if by some miracle you could push the Moon itself into a higher orbit you might just make an impact. So, all one needs to do is accomplish the impossible. Of course, PHP Security is not quite that difficult (I think) but it does have its equivalent of a Moon. That Moon is Authorative Knowledge.
Authorative Knowledge is not fact-based, per se, but a social perception of what is and is not authorative. Therefore, it's a function of the perceived reliability and correctness of the knowledge source. Is the source trusted? Is it an authority on the topic? How much support does it have among the community? All of these factors play into the creation of a source of Authorative Knowledge.
In the PHP community, the Authorative Knowedge for PHP Security is derived from a concensus. A concensus based on published articles, the practices of libraries and frameworks, printed books, and the vague meandering thoughts of whoever you follow on Twitter.
In other words, our current Authorative Knowledge is you. You're writing source code. You're tweeting. You're probably blogging and may contribute to Devshed or something similar. And I don't doubt that you talk to other people. Do YOU view yourself as an authority on PHP Security? Most of you probably do not, however, some of you will turn it over in your minds or quickly think YES. That, right there, is the true division of authority but that division has never been clearly established in the PHP community. As a result, nobody really knows in whom or where that authority sits.
That, my dear readers, is the root problem with PHP Security. Until the community can say aoThis is authorativea without doubt or hesitation, the concensus hivemind (it's like a flock of sheep) will rule all of our security futures. Sheep are stupid animals. I should know, I spent enough time growing up on a sheep farm to form an authorative opinion of them "/
Truncated by Planet PHP, read more at the original (another 3543 bytes)