This is a branch off from a separate discussion on the PHP-FIG mailing list about other ways the Framework Interoperability Group can encourage and foster wider interoperability among its member projects (and by extension, the whole PHP community). I’ll start by noting two interesting developments in recent months and one long standing best practice.

1. Launch of the SensioLabs Security Advisory Checker

The SensioLabs Security Advisor Checker is described on its website as follows.

You manage your PHP project dependencies with Composer, right? But are you sure that your project does not depend on a package with known security issues? The SensioLabs security advisories checker is a simple tool, available as a web service or as an online application, that uses the information from your composer.lock file to check for known security vulnerabilities. This checker is a frontend for the security advisories database.

The service operates by having people submit vulnerability data, as YAML files, to a centralised Github repository through pull requests. The upside is that the vulnerability data can be peer reviewed and centrally dispersed either online or via a service API. The downside is that you need to find vulnerability disclosures and people to submit them. The service currently covers Symfony, Zend Framework, Doctrine, Twig and FriendsOfSymfony bundles. It’s a tiny sample of packages available through Composer. I’m also not entirely sure if it’s sufficiently fine grained to report vulnerabilities on a project’s sub-packages where you have no direct dependency on the aggregate package (e.g. using zendframework/zend-db instead of zendframework/zendframework). That said, this is a working model of a service for checking your dependencies.

That said, the service exhibits an ambitious idea – projects sharing their vulnerability disclosures or advisories in a way that allows for automatically checking if any of your projects need to have their dependencies updated for security reasons.

2. OWASP‘s Top 10 security risks for 2013 includes “A9 – Using Components with Known Vulnerabilities”

This is a new entry onto OWASP’s Top 10 (which is currently at release candidate status for 2013). In summary, it recognises that applications are becoming ever more dependent on code not developed internally. We’ve had web application frameworks for years. Composer and Github have unleashed a storm of accessible libraries, bundles, modules, and other units of reuse that have revealed Not Invented Here (NIH Syndrome) as a psychological problem in ways not previously possible.

As reliance on externally controlled dependencies increases, so too does the risk of your applications using insecure dependencies. This is a risk that requires a lot of work to mitigate. For each dependency, you need to do a security review (no, I’m not kidding), check for security disclosures (whether voluntary or involuntary) and ensure that you end up rolling out to production with safe versions.

Quoting from the OWASP advice on preventing the use of components with known vulnerabilities…

One option is not to use components that you didn’t write. But realistically, the best way to deal with this risk is to ensure that you keep your components up-to-date. Many open source projects (and other component sources) do not create vulnerability patches for old versions. Instead, most simply fix the problem in the next version. Software projects should have a process in place to:

1. Identify the components and their versions you are using, including all dependencies. (e.g., the versions plugin)

2. Monitor the security of these components in public databases, project mailing lists, and security mailing lists, and keep them up-to-date.

3. Establish security policies governing component use, such as requiring certain software development practices, passing security tests, and acceptable licenses.

3. Disclosing security vulnerabilities in a timely and responsible manner is a best practice

As programmers, we have a responsibility to users to disclose security vulnerabilities and fix them in a timely manner to ensure that those users are protected from harm. It’s almost impossible not to end up in such a situation at some point in your career. In fact, it may even be impossible for it not to happen multiple times in a single year!

The sad truth, however, is that disclosing security vulnerabilities can be terribly hit and miss. I’ve seen people ignore vulnerabilities or fix them but fail to disclose the fact to their users. Opinions over the severity of a vulnerability can vary dramatically within even a small group of programmers. Nobody likes to air their dirty laundry in public but not doing so can mean someone including a dependency with a known vulnerability without any means of becoming aware of that vulnerability.

It is always a good thing to come clean. Fixing a vulnerability, disclosing it, and having a good security policy in place prevents the reputational damage you might suspect would occur. It’s usually the secretive rollout of fixes that gets you in trouble when someone is attacked or the reporter discloses the vulnerability through other means (usually making note of your refusal to come clean).

The method of disclosure is usually in release notes, commit messages, blog posts or emails. This article suggests using formats that are more fundamentally consumable and standardised.

Centralised Tracking Of Decentralised Vulnerability Data?

Being aware of these three, we can see the immediate value in something like SensioLabs security advisory checking service. You have dependencies which very likely have had or will have vulnerabilities, and you probably would love to know about those before releasing a new project build to production servers. The problem is that this involves work in importing vulnerability data into the checking service and, failing that at present, a trawl of the internet for vulnerability disclosure blog posts, commit messages and emails. What would happen if, as a means of improving interoperability and common security, more vendors published their disclosures at fixed URIs in just one or two easily consumable formats (e.g. YAML or RSS/Atom)?

For example, instead of relying on someone submitting a pull request to SensioLabs each time Library X discloses a vulnerability, one could simply store a URI to Library X’s disclosure feed and/or a YAML formatted summary stored in its git repository. The SensioLabs service, or something like it, could now pull in vulnerabilities automatically assuming Library X uses a predetermined consumable format. This sounds, at least to me, as a more sustainable system.

If a sufficient number of packages on Composer followed this practice, we’d have something quite brilliant and possibly easier to promote in the community. People are now very familiar with maintaining a composer.json file. Adding one more file, in lieu of an alternative RSS/Atom feed, is not that big of a stretch if enough projects request it of their dependencies. The rest would be down to the boring work of agreeing formats, procedures and other technical aspects with a view towards, *if* called for, a PSR on the topic.

Let me know what you all think in the comments or catch me on the PHP-FIG mailing list.

Watching some asshat fail at cross site scripting attacks against gearfuse.com. (Photo credit: vissago)

Summarising knowledge has as much value as writing a 200 page treatise on a topic, so here is a list of 20 brief points you should bear in mind when battling Cross-Site Scripting (XSS) in PHP. Minus my usual book length brain fart . Chances are good that ignoring or acting contrary to any one of these will lead to a potential XSS vulnerability. It’s not necessarily a complete list – if you think something needs to be added, let everyone know in the comments.

1. Never pass data from untrusted origins into output without either escaping or sanitising it.
2. Never forget to validate data arriving from an untrusted origin using relevant rules for the context it’s used in.
3. Remember that anything not explicitly defined in source code has an untrusted origin.
4. Remember that htmlentities() is incompatible with XML, including HTML5′s XML serialisation – use htmlspecialchars().
5. Always include ENT_QUOTES, ENT_SUBSTITUTE and a valid character encoding when calling htmlspecialchars().
6. Never use htmlspecialchars() as the primary means of escaping Javascript, CSS or URL parts.
7. Never use json_encode() to escape Javascript strings unless using PHP 5.3 and RTFM.
8. Use rawurlencode() to escape strings being inserted into URLs and then HTML escape the entire URL.
9. Never ever pass escaped or sanitised data from untrusted origins into a Javascript execution context: a string later executed as Javascript, e.g. setAttribute(“onclick”, “PLEASEGODNOTHERE”).
10. Validate all complete URLs if constructed from untrusted data.
11. Never validate URLs using filter_var(). It doesn’t work and allows Javascript and Data URIs through.
12. Never include resources loaded over unsecured HTTP on a page loaded over HTTPS.
13. Sanitise raw HTML from untrusted origins using HTMLPurifier before injecting it into ouput.
14. Sanitise the output of Markdown, BBCode and other HTML replacements using HTMLPurifier before injecting it into output.
15. Remember that HTMLPurifier is the only HTML sanitiser worth using.
16. Adopt the Content Security Policy (CSP) header and abandon the use of inline CSS and Javascript where feasible.
17. Always transmit, with content, a valid Content-Type header referencing a valid character encoding.
18. Ensure that cookies for use solely by the server are marked HttpOnly.
19. Ensure that cookies which must only be transmitted over HTTPS are marked Secure.
20. Always review dependencies and other third party code for potential XSS vulnerabilities and vectors.

Cross-Site Scripting remains, by far, the most common vulnerability in web applications. Things that will sink your application, framework or library become very obvious from the list. There are more than enough naughty applications, frameworks and libraries around that you should have little trouble identifying offenders with grep and some mental acrobatics. Rumour has it that you can now locally search any project on Github without even cloning a repository.

Yes, some entries are reminders. It’s surprising how many people try to avoid HTMLPurifier in favour of the month’s Regular Expression Powered Miracle option which is riddled with holes or have formulated the belief that, contrary to its official syntax rules, Markdown magically prevents Cross-Site Scripting.

I’m very happy to announce the release of Mockery 0.8.0.

Mockery is a simple yet flexible PHP mock object framework for use in unit testing with PHPUnit, PHPSpec or any other testing framework. Its core goal is to offer a test double framework with a succint API capable of clearly defining all possible object operations and interactions using a human readable Domain Specific Language (DSL). Designed as a drop in alternative to PHPUnit’s phpunit-mock-objects library, Mockery is easy to integrate with PHPUnit and can operate alongside phpunit-mock-objects without the World ending.

The new version of Mockery is the first in a year (since 0.7.2) and is packed with new features, bug fixes and even better support for PHP’s OOP model. It’s also the first version to be released with my new co-conspirator, Dave Marshall (@davedevelopment), who threatens to make me redundant as a maintainer! This version focuses primarily on stability but it’s worth reviewing the README for the new sections on Creating Partial Mocks and Behaviour Modifiers for mock objects.

For those who haven’t been using dev-master in their composer.json project file, you can now update to the 0.8.0 stable tag using Composer or grab the 0.8.0 package from the PEAR channel at http://pear.survivethedeepend.com.

A very special thanks to those who opened pull requests and reported issues over the past year.

The Zend Framework team recently released versions 2.0.8 and 2.1.4 to address a number of potential security issues including advisory ZF2013-02 “Potential Information Disclosure and Insufficient Entropy vulnerabilities in Zend\Math\Rand and Zend\Validate\Csrf Components”. Quite the mouthful!

In short, Zend Framework used the mt_rand() function to generate random numbers in situations where neither openssl_pseudo_random_bytes() nor mcrypt_create_iv() were available. This is possible when the openssl and mcrypt extensions are not installed/compiled with PHP. The mt_rand() function is a particularly weak Pseudorandom Number Generator (PRNG) selected for speed over security so it should never be used unless for obviously trivial use cases. Consider the following as food for thought:

if ($_GET['rand'] == mt_rand()) {
    exec($_GET['command']);
}

This example has two characteristics. It has nothing to do with cryptography and it gives attackers something interesting to work with if they can guess what mt_rand() will return. It demonstrates that the concept of reserving good random number generation solely for “cryptographic” purposes is entirely false and misleading. You should use good generators for all but the most trivial purposes. If guessing a random number or string leads to an unauthorised outcome, then using mt_rand() is a security vulnerability. This applies to a whole range of uses for random number generators: session IDs, API tokens, CSRF tokens, nonces and unique ids. These all rely on randomness as do core functions like uniqid() and array_rand(). What happens if they are predictable?

What makes mt_rand() and uniqid() such bad choices for anything when it comes to security? I wrote a new chapter for the slowly expanding security book I’m writing which you can read here online:

http://phpsecurity.readthedocs.org/en/latest/Insufficient-Entropy-For-Random-Values.html

The extremely short and sweet version is that all of PHP’s internally used and externally exposed PRNGs use seeds. Those seeds are based on limited information like current seconds, microseconds, and process PID. These values are not very uncertain and even partially predictable, i.e. they have “insufficient entropy”. If you use the same seed, those PRNGs output the exact same values every time. If you get a random value from a server, you can brute force it to get the seed used (e.g. use HTTP Date head to guess seconds and twinned requests to minimise microsecond deltas). Servers can output brute forcible random numbers either automatically (i.e. Session IDs) or by design (e.g. CSRF Tokens). Now an attacker can predict future values – for the same PHP process! Finally, there’s this thing called KeepAlive that lets an attacker reuse the same PHP process multiple times…and predict random values on future requests. For example, the token generated when resetting an account password that is appended to a secret reset password URL sent by email to the account owner whose account can inject unsanitised HTML into any part of a website.

In any case, take the time to read the longer book chapter . It has a lot more practical information including a walkthrough of a theoretical attack and links to some tools publicly available for mounting proof of concept attacks. I also discuss solutions including Anthony Ferrara’s RandomLib.

As some of you are likely aware by now, Ruby On Rails posted a security advisory concerning critical remote code execution (RCE) vulnerabilities in its Action Pack for all versions of Rails since 2.0.

This vulnerability can likely be used in a wide variety of potential attacks so you should immediately update any Rails applications you are currently running. There’s a good analysis of the issue over on http://www.insinuator.net/2013/01/rails-yaml/ and it raises the very real risk that the global nature of this vulnerability may make automated attacks or worms feasible. A concrete POC has not been released to give folk more time to update their applications before attackers figure out how to take advantage of this.

Yes, but HOOEY! How does this relate to PHP, Paddy?!

Code execution vulnerabilities are, by definition, hideous monsters. The ability for external inputs to enter an execution context (i.e. injecting or manipulating code that is executed on the server) can be difficult to spot through the haze of convenience that such machinations are often designed to deliver. In Rail’s case, that convenience was to automatically cast data entries in XML or YAML inputs into Ruby types including, unfortunately, Symbols and Objects.

These types of “buried” code execution vulnerabilities are still easy to locate in PHP, at least, because you are still restricted to normal code execution pathways in the absence of Ruby’s dark magic, e.g. eval(), include(), require_once(), system() and, let’s not forget, unserialize(). Anyone can perform a mini-audit using grep searches just by checking for instances of these and similar functions and then identifying whether they are in unusual places or accepting variable inputs that could be exploited. For example, a few years back many applications were found to be unserializing user inputs which allowed for code execution attacks by manipulating parameters to __wakeup() and __destruct() method calls.

Rails is a battle hardened framework but all frameworks will suffer from unanticipated security vulnerabilities. You just won’t see them become as well publicised as Rails! It’s the nature of programming for programmers to err or fail to foresee unintended uses for their code. PHP applications and libraries are already suffering from any number of obviously pervasive ills including three security problems I called the Three Ugly Sisters in my recent article for December’s Web Advent series (SSL Peerjacking, XMl Injection and Cross-Site Scripting). We all have the capacity to do better on the security front.

No PHP project is immune to security vulnerabilities simply because of its size, user base, or funding. Even a good security audit is not immune to the blind spots of the reviewer, emerging security issues still flying under the radar and the continuing assault by researchers on practices and techniques we take for granted.

One part of being prepared for unexpected vulnerabilities is to find common ground with your competitors. Ruby on Rails is a web application framework. If you are a PHP framework developer and not monitoring Rails’ or Django’s security woes then it’s time to start. We can learn a lot because, despite the barrier of a different programming language, many security problems are universal. Frameworks in Ruby, PHP, Java and Python can all run afoul of very similar vulnerabilities. Using that knowledge can lead into avenues of investigation you did not previously consider. Within PHP itself, monitoring frameworks like Zend Framework and Symfony can reveal security advisories that, in all probability, are not unique to those frameworks.

As a case in point, the Rails vulnerability I opened this article with led me to wonder if something similar might be possible in a PHP framework. So, I took a look at Symfony 2′s YAML component. Johannes Schmitt apparently had the same thought! As it happens, there are two possible points in the YAML classes where code execution could potentially be manipulated by untrusted input. The component is generally used to parse local configuration files (so typical Symfony applications will not be vulnerable) but there is nothing to stop it from being used as a generic YAML parser for other use cases such as user submitted files or YAML output from a remote API. As always, Fabien promptly set the Elves in his North Pole hideout on red alert and has already released fresh versions of Symfony 2.0 and 2.1 to rectify these issues. You can read the official advisory at http://symfony.com/blog/security-release-symfony-2-0-22-and-2-1-7-released.

The code execution vulnerabilities in Symfony’s YAML component relied on calls to include() and unserialize(). One included a file as PHP and parsed its output as YAML (disabled by default since Symfony 2.1 but still enabled by default on Symfony 2.0 versions) and the other unserialised objects stored to a YAML scalar value (enabled by default in all versions). As I mentioned earlier, grep can be really helpful in locating these types of problems – so get cracking on the command line!

To summarise…

Pay attention to competing applications or frameworks – their problems may also be your problems. If you’re worried about arbitrary code execution vulnerabilities then audit your code. You can even, as a sanity check, use grep to find uses of functions like eval(), unserialize(), etc and analyse where their parameters’ might originate from. The answer “somewhere out there” or “how the heck am I supposed to know what crazy users will do” usually means it’s untrusted by definition. Keep in mind that code execution vulnerabilities can also appear in the form of arbitrary object instantiation, i.e. the constructor and destructors being executed for any object targeted even if there are no other method calls made. Manipulating code execution can be just as bad as arbitrary code execution.

Related articles

• Analysis of Rails XML Parameter Parsing Vulnerability (insinuator.net)
• Extremely crtical Ruby on Rails bug threatens more than 200,000 sites (arstechnica.com)

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.