Automatic Output Escaping In PHP And The Real Future Of Preventing Cross-Site Scripting (XSS)
Even Dexter Knows html (Photo credit: mollyeh11)
A while back, the Zend Framework 2.0 team decided that automatic escaping for Zend\View (a template engine where all templates are written in PHP itself) was too unsuitable and potentially confusing to be included. As a result, Zend\View templates will continue relying on manual escaping against Cross-Site Scripting (XSS) vulnerabilities using a new Zend\Escaper component.
Nevertheless, the decision was not taken lightly. Automatic escaping has a certain appeal given its goal of removing the need to type escape() all over your templates. Funny thing, though, is that this is basically its one and only advantage. The second claimed goal is to remove a factor of human error (i.e. forgetting to type escape() somewhere), however, this hasn't posed an issue for me in the past where simple analysis of templates can quickly locate such omissions. And no, using automatic escaping does not remove the need to analyse templates for security issues - that's still needed regardless. At some point, we seem to have lost the plot and overinflated these benefits in our minds. So, rather than muddy the waters with confusing object-proxies and expending too many CPU cycles for too little of a benefit, ZF 2.0 is back on manual escaping.
In reality, automatic escaping doesn't resolve all (or even most) of your security problems with XSS. Why? Because all escaping, regardless of how automatic it claims to be, still needs one fundamental factor to be successful: manual oversight by a knowledgeable programmer.
Whether you choose manual or automatic escaping, neither will prevent poorly educated programmers from shooting themselves in the foot with XSS vulnerabilities because those kinds of programmers just don't understand XSS. Worse, it still won't prevent even really good programmers from making errors of omission or misjudged context - nobody is perfect and any process needing human input inevitably experiences human errors.
In the game of mitigating against the risks of XSS, how you escape is not as important as knowing why you are escaping. That second point, understanding why you escape data on output, is unfortunately commonly misunderstood. Yet, without that basic understanding - your choice of how to escape is quite possibly incorrect and, worse, it allows insecure escaping practices to thrive as that misunderstanding becomes embedded in what we pass on to other PHP programmers. We're self-perpetuating our own ignorance - Stackoverflow and articles still commonly present escaping notions that are plain wrong.
So, let's travel down the automatic escaping rabbit-hole to understand why automatic escaping hasn't progressed much further than serving as a method for reducing template verbiage. At the end, I'll explain what is being done on the browser-side of XSS prevention to offset the problems ALL programming languages are having with getting escaping done perfectly.
What Is Automatic Escaping?
Defining automatic escaping would probably help to explain why manual oversight of escaping is unavoidable. There are broadly two definitions in use these days, or perhaps it's more accurate to call them styles. The first automates escaping by applying a fixed escaping strategy to all data being output in a template. This is the aoscope limiteda style where the auto escaper is incapable of automatically switching escaping strategies depending on the context into which the data is being out
Truncated by Planet PHP, read more at the original (another 16352 bytes)