Taking PHP Security Seriously By Taking It Seriously
The Singing Annoying Thing (Photo credit: DWZ)
Since the dawn of time, circa 1995 AD, PHP and Security have been at constant loggerheads over what priorities programmers should cling to. Programmers, by their very nature, are drawn to getting shit done inexpensively. Building tools, libraries and applications is a time consuming and expensive process and managing that process in the most efficient manner possible has been a focus of untold years of study and experimentation. Interestingly, whereas open source code is subject to greater public review it is not necessarily driven by those same needs.
Many open source programmers are happy to waste countless hours in the pursuit of perfection, to try new things that companies' would blanche at funding and to spread word through their social networks of every possible attractive idea to dare peek out of a window. Only in the open source world could someone suggest completely rewriting a sizeable chunk of code without having project managers and accountants hustle them off to the broom cupboard for a private chat. Not that those two groups are always aware of the costs of fixing stuff that isn't broken!
Nevertheless, for all of open source's charms it also carries around a terrible monster. Programmers will nearly always claim to take security seriously while writing source code which obviously doesn't agree with this publicly proclaimed sentiment. Take such developments in-house to a proprietary setting and that same result is a recipe for utter disaster and a possible ass kicking out of the nearest door. Companies are risk intolerant when the risk offers no potential gain.
Our open source endeavors need to appeal to enterprises and other conservative programmers - not simply to the masses of PHP programmers attracted by shiny new stuff displacing ancient scarred stuff that still works reliably despite a decade of warfare on the frontlines. We also need to be concious that PHP Security is largely viewed as an oxymoron. Putting both of those words into the same phrase is considered a joke in many quarters. Whether we like it or not, PHP has a higher benchmark to meet and we're not meeting it.
Consider for a moment your browser. All modern browsers are maintained by groups which understand a fundamental market force. If your browser fucks up security badly enough, users will use another browser that they perceive as being more secure. The obvious corrective action is to improve security, mitigate the risks of browser based vulnerabilities, and push improvements on multiple fronts to create a Defense In Depth approach protecting against one of the ultimate sources of security problems: The Web Programmer.
It's not just browsers. Both OpenID and OAuth utilise restrictive cryptographic schemes because, at the end of the day, programmers would otherwise find a way to screw it up. Indeed, the idea of OAuth 2.0 doing away entirely with cryptographic signatures was met with relief in some quarters followed by the realisation that it would now depend on programmers correctly implementing HTTPS - so it was added back in!
Let's consider a web application which allows users to send messages to numerous other web applications. It's a simple message exchange system not unlike email with the benefit that all messages are encrypted and communicated across HTTPS. When the browser acts as a client, we can be reasonably sure that this is a secure client. Browsers are market driven products so they are intolerant of security vulnerabilities. When a web application acts as the client, a di
Truncated by Planet PHP, read more at the original (another 9014 bytes)