The Zend Framework blog has continued their series spotlighting individual components of the framework and putting them to use outside of a ZF-based application. In the latest post they show how to use zend-escaper to handle context-specific escaping.

Security of your website is not just about mitigating and preventing things like SQL injection; it's also about protecting your users as they browse the site from things like cross-site scripting (XSS) attacks, cross-site request forgery (CSRF), and more. In particular, you need to be very careful about how you generate HTML, CSS, and JavaScript to ensure that you do not create such vectors.

As the mantra goes, filter input, and escape output.

They start with some of the main issues around escaping output in PHP (and some of the inconsistencies) and what zend-escaper can to to help. The tutorial then shows how to pull the component into your current application via Composer and set up a new Escaper instance. It briefly covers the built-in escaping methods and then provides some more real-world examples of how it can be used to protect your application.

There's been a lot of chatter about a recent RFC from Pádraic Brady on the php.internals maling list - his proposal to add native escaping to the PHP core. He shares some of his own thoughts about the proposal in a new post to his site.

A short time ago today, I submitted a PHP RFC for discussion which proposes adding an SPL Escaper class and, quite possibly, a related set of functions dedicated to escaping data for output to HTML/XML to PHP: https://wiki.php.net/rfc/escaper. The RFC itself should be a good read if you want to understand why I’m proposing this but the basics are quite simple. Cross-Site Scripting (XSS) is one of the two most common security vulnerabilities in web applications – the other being SQL Injection. Despite this, PHP’s offering of escaping functions is extremely limited.

He talks about what problems the proposed solution solves and how it could help protect PHP programmers more effectively than the more complicated methods they have to go through now. If you're interested in reading the conversations so far, you can start here and walk through the messages.

Paul Reinheimer, one of two behind the funcaday website (providing details on one PHP function each day and special content on the weekends) has posted a supplement to this weekend's posting covering escaping.

The disadvantage with the escape for now, not for later approach is simple. If you save a user's post to the database, then that user's post is displayed 2,000 times there will be some serious differences. [...] You will need to balance your security concerns with performance needs.

The comments on his post back up his suggestions (and include other tips like a recommendation to cache on an even higher level - page blocks).

Paul Reinheimer, one of two behind the funcaday website (providing details on one PHP function each day and special content on the weekends) has posted a supplement to this weekend's posting covering escaping.

The disadvantage with the escape for now, not for later approach is simple. If you save a user's post to the database, then that user's post is displayed 2,000 times there will be some serious differences. [...] You will need to balance your security concerns with performance needs.

The comments on his post back up his suggestions (and include other tips like a recommendation to cache on an even higher level - page blocks).

Davey Shafik has created a cheat sheet useful for any developer out there using a database, one to remind you of the filtering and escaping techniques to use before putting data into your database or outputting it to your site.

You can grab the cheat sheet here in a PDF format.

Davey Shafik has created a cheat sheet useful for any developer out there using a database, one to remind you of the filtering and escaping techniques to use before putting data into your database or outputting it to your site.

You can grab the cheat sheet here in a PDF format.