Irishisms

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!

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.