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!
Unlike browsers and open standards, PHP appears to defy these shared realities. 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 different picture emerges. Web applications don’t have friendly icons and other visual cues indicating the use of a secure SSL/TLS connection. Like most Twitter clients in PHP, chances are good that it actually doesn’t even use SSL/TLS properly. Just because the security vulnerability is not obvious, it doesn’t excuse its existence. It is, afterall, a SECURITY VULNERABILITY that would allow anyone capable of intercepting network traffic from the vulnerable application to examine all of its users’ messages in complete defiance of what users’ expect.
From a conservative viewpoint, this is a complete nightmare. SSL/TLS is one of the most basic concepts on the internet. How can you NOT get it right? Isn’t there a box on a checklist for that? And yet, with every passing month, PHP programmers wheel out source code which not only gets it completely wrong but will even disable it deliberately rather than deal with the work of ensuring it’s secure.
Within this scenario, something has gone a wee bit wrong. Users expect their data to be protected. Not doing so is either a security vulnerability introduced by a lack of experience or an act of deliberate sabotage performed in the service of some other goal. Either way, such source code is dead, untrustworthy, in need of nuking. It should not be used, it should not be advocated, it should be publicly disclosed and, if it’s still not fixed, it should be abandoned and consigned to a historical archive of mistakes to bring out when teaching new programmers. More relevantly, we should ask ourselves why this scenario sounds so familiar…
SSL/TLS issues are as common as sand on a beach in PHP. If I were not a PHP programmer with a severe bias, I might begin writing a blog post about how insecure and dangerous PHP is. Oh…wait…;).
The moral of the story is pretty simple. If you respect a user’s right to have their data handled securely, use libraries and applications that are themselves secure. Otherwise, just use libraries that are insecure, inherit their security vulnerabilities, and pray that nobody ever notices how completely irresponsible you are. It would also be healthy to quit pretending that PHP is a “secure programming language” – it’s not. It will only ever be as secure as the programmers writing it can accomplish. PHP itself contains so many default insecure settings and functions that writing insecure source code is just matter of opening an editor and typing.
This is, of course, not the correct conclusion…it’s merely a symptom of an underlying disease that desperately needs to be addressed.
If I ask any number of PHP programmers why they are sabotaging SSL/TLS and exposing their users to umpteen zillion other security vulnerabilities, there is a common trend in their responses. Most programmers treat security as an afterthought and engage in zero self-directed education about security in general. The most common response is actually shock, followed by denial, followed by excited elation at the idea of fixing stuff, followed by the sobering realisation that someone somewhere is an evil fucker for making their lives harder by not telling them all this sooner. Some graduate further into taking security seriously, seriously.
This is actually PHP’s current failing: Knowledge.
If I go digging for information about how to do some simple set of security tasks, like output escaping, I will be faced with a massive wall of misinformation. Some of it dates from ancient blog posts written in the early 2000s that have been regurgitated blindly ad nauseam. Some is completely wrong just because the writer never actually tested any of it against known vectors. Some is based on personal experience alone. A tiny fraction is perfected knowledge lost in the noise of a hundred other chattering idiots. And threading its way through everything is the constant barrage of popular excuses that defy logic, common sense, and simple security principles such as Defense In Depth – the simple is popular, the more complicated truth not.
In PHP, programmers have created their own mini-reality based on a set of beliefs that dismisses all else as heresy to be ignored. In the absence of knowledge, we’ve founded a religion that makes it okay to tolerate security vulnerabilities, to excuse ourselves from fixing them and to foist solutions on the PHP community as the One True Way. Through it all we ignore the reality of serving the needs of the user. They are the ones who stand to suffer from our failings.
PHP Security is a war on a religion that is stoutly defended.
Signs of this religious dogmatic approach to PHP Security are everywhere. The last PHP Security book I picked up was so incredibly stupid that it now probably occupies egg cartons and cereal boxes made from recycled material (though secretly I hope it made it to toilet paper). Incremental improvements to security, based on a concensus of security experts across multiple programming languages, have been openly ridiculed and debated. Something as simple as enabling secure SSL/TLS has ended up heading down a rabbit hole where apparently the ability to do so is itself unreliable in PHP’s core implementation compared to CURL and needs far more configuration to boot. Why bother? Just use CURL! A sign of another recurring theme is the PHP documentation’s weird aversion to explaining how it even addresses security issues or does so with the vaguest of nods as if unsure of itself. Then again, we do have settings like “allow_url_fopen” so maybe it is a bit crazy to expect anything else.
The only solution that I can imagine is the simplest: Knowledge! PHP is riddled with knowledge gaps, missing documentation, a lack of progressive improvement, reliable security tools and features, and people with the will and a flair for stubborness to accept the impossible task of tackling all of these and much more. A long as those gaps persist, the vacuum they leave behind will be filled with utter bullshit created by idiots and documentated as fact which promotes further inactivity because programmers at large then remain unaware that a problem even exists. A self sustaining cycle of ignorance emerges.
Eventually, we all need to start asking some simple questions. There’s a massive list of them unfortunately. However, if we ask enough basic questions, check for what everyone outside of PHP thinks the answer is, examine PHP with this new knowledge and a cold glare, we may actually find those simple questions revealing the very bits and pieces of knowledge we so desperately need.
Seriously, why is it that so many HTTPS dependent clients in PHP disable SSL/TLS protection by disabling peer verification or by never enabling it at all as the case may be? Why do PHP programmers appear to rally round such insecure libraries? How many third party applications have inherited that vulnerability from their dependencies? Are those dependencies themselves compiled from insecure HTTPS connections during deployment? How many of those have a Man-In-The-Middle eavesdropping and manipulating unprotected HTTP requests? Actually, that’s a trick question. It doesn’t matter how many – it only takes one MitM screwing over a single user of one application on a random day at any moment in history. You failed that user by abandoning your responsibility to them.
We can never predict how security vulnerabilities will be used – the concept of “low risk” is the ultimate fallacy generated by an appealing dogma with no foundation in acceptable security principles. It’s a lie. Like the one where no security measure is perfect and therefore we don’t need to try. Technically though, that last one is simple gibberish which roughly translates to “I don’t want to do my job”.
Knowledge is the essential ingredient to improving PHP Security. What you don’t know can bite you; what you do know can be hunted down and shot.
In our next edition of “The Raving Lunatic Who Escaped Custody In His Undies”, I will spend a bit more time focusing on this need for Knowledge, some developments in that arena, and a few examples of where it is already leading to a slightly more secure baseline for PHP applications.
The Framework Interoperability Group (FIG): Openness, Accountability and Community Involvement in PHP Standards
Recently, Anthony Ferrara posted “Open Standards – The Better Way“, a blog post questioning the operation of the PHP Framework Interoperability Group (FIG). The FIG is a body representative of PHP “frameworks” (with a broad definition since it includes phpBB, Drupal and even more divergent members) which issues PSR standards such as the PSR-0 standard which governs requirements for autoloader interoperability and the upcoming PSR-1 and PSR-2 standards which, together, form a coding standard for PHP.
Anthony, whose views always make good reading, raises concerns about the way in which this group generates standards. He contrasts the current approach to RFC 2026 which defines the IETF’s Internet Standards Process. That approach evolved to balance conflicting requirements. On one hand the rapid evolving nature of the internet demands the timely production of standards while, on the other hand, the standards must be subject to an open and fair process, proper testing and technical development. Surrendering to either side of this conflict tends to give rise to poor standards.
Where Anthony’s arguments seemingly fall flat is that the FIG is not the IETF. The Framework Interoperability Group was founded to allow cooperating members to develop shared standards. It does not claim to be PHP’s standards body and so there is no obligation for any PHP programmer to adopt their standards (unless they work on a member project obviously!). On this simplified basis, the FIG doesn’t need to balance the conflicts described by the IETF. It serves its own interests, i.e. those of its members who may voluntarily adopt accepted standards at their convenience to boost interoperability between their software. If they be happy, they be happy.
However, the FIG is not a closed standards body. Anthony’s article simply targeted the FIG’s processes which have been slowly evolving from a semi-closed process (there was a time when the mailing list was not open) towards a more open process. By inches, the FIG is becoming a defacto PHP Standards Working Group and I’m skeptical of anyone who doesn’t see that. The only technical reason they can’t really use their original title as-is is probably because of licensing concerns in using the “PHP” moniker. The phrase “Framework Interoperability Group” is much…er… better. It’s catchy even if nobody will have a slightest clue what the heck it means.
It gets even more interesting though. While it’s easy to assume that the FIG is operated by some undetermined number of individuals one can ignore as a bunch of power hungry people, the truth is that the voting members are not people at all – they are nearly all open source projects. FIG is operated by individuals on the basis that they represent the interests of the FIG’s real members, i.e. projects which include Zend Framework, Symfony 2, Lithium, Aura, phpBB, Joomla, Drupal and even an individual who, as an honorific, represents “the community at large”.
This is why PHP programmers need to pay attention to what the FIG is doing. The Group is, by definition, an open standards working group. It does actually wield real authority and influence by virtue of the fact that its members represent a not inconsiderable number of open source programmers both within their projects and among those who build any sort of dependent library or plugin against those projects. Once PSR standards are issued, they also benefit from the reputation of the members, the knowledge that it was subject to an open process, and an assurance of independence since it was agreed to by a majority of the member projects and not just one of them.
In other words, the FIG is actually something really really good for PHP. PHP needs standards so we can make interoperability between various frameworks and applications a true reality. The hodgepodge of APIs and standards we’ve relied on to this point only serve to reinforce PHP’s NIH obsession (the bad type, not the good type that keeps PHP reinventing better variants of everything under the Sun). These days you can’t simply pick a library to replace another – they’ll have different APIs. Besides NIH, it also encourages stagnation since different APIs generate a barrier to new replacements. Thankfully, that whole APIs are copyrightable lark is now officially dead in the EU (and close to it in the US!).
But let’s not forget Anthony’s article. Can the FIG improve its processes for creating standards? I’d venture that it could and articles like Anthony’s are part of that improvement. Far from being a case of “pitchforking”, questioning the open process of FIG should be as acceptable as having some weird people called Mr. Grumpy ranting and raving on an open source mailing list. Open source projects embrace the programmer community as their most valuable resource. Open standards bodies are no different – they derive their authority and influence from the communities they serve.
What the FIG should do, in my opinion, is clearly define its purpose and better document its bylaws/processes. At the moment, the messaging is confusing. Some member statements leave no doubt that the purpose of the FIG is to serve its member projects in producing shared standards but other statements demonstrate a hope that PHP at large will also adopt the same standards to improve PHP’s overall open source ecosystem. Do observers need to flip coins to figure out what the FIG’s mission is? Personally, I see absolutely nothing wrong with the FIG encouraging the PHP community to adopt its standards. It’s not a power grab or a selfish act to do so – it’s just a group of open source minded folk trying to promote greater cooperation among programmers. Documenting bylaws and processes would clear up any other elements of how the community can become involved and remove any perception of a closed network of individuals. What is the criteria for membership? Who can submit new proposals? How are member representatives selected, replaced, etc? How are proposals handled, reviewed and progressed? Why are proposed standards not obviously available in the Github repo under the proposed directory?
It really all comes down to better communication and pushing the community engage with the FIG. To this end, bear in mind that the FIG members are open source projects. The FIG membership is also growing (presumably it will stop growing eventually unless the group wants an unwieldy number of chefs in the kitchen). Each project has a voting representative who is assumed to represent the interests of that project. If you are a contributing member to or a user of any representated open source software, your first step should be to hold your representative accountable. Open source projects tend towards Meritocracy’s with an optional Benevolent Dictator – you may already have a voice in how the FIG operates and how your representative should be voting. You just have to use it!
On the flipside of this communication route, ensure your FIG representative keeps the project’s community involved and informed. They should be seeking your feedback, building support for their votes, and using whatever internal proposal mechanism exists (formal or informal) typical for such decisions prior to casting their vote. The FIG should never involve bypassing an open source project’s normal operations. Hold your representative accountable and ensure they represent that project’s interests. If they don’t – pitchforks can be bought at most reputable hardware stores.
- Open Standards – The Better Way – Anthony Ferrara (ircmaxell.com)