Adam Culp has posted his latest episode of his "Run Geek Radio" podcast series with Episode #8: Escaping PHP Variables Forgotten

Escaping variables in PHP is as important as ever, and developers can sometimes forget about it when using a modern framework. Adam Culp, the host of Run Geek Radio, talks a little about common pitfalls and how to handle them. Also covered is the ZendCon and SunshinePHP preparations and status of Adam speaking at some other upcoming conferences. Plus a brief update on the running front and training.

You can listen to this latest episode either through the in-page audio player or by downloading the mp3 directly. If you enjoy the show, be sure to subscribe to the feed and get information about the latest episodes as they're released.

In his latest post Derick Rethans shares his answer to a question he was asked at a recent PHP conference regarding the escaping of input before use in a MongoDB query.

At last weekend's PHP Benelux I gave a tutorial titled "From SQL to NoSQL". Large parts of the tutorial covered using MongoDB—how to use it from PHP, schema design, etc. I ran a little short of time, and since then I've been getting some questions. One of them being: "Should I escape my input, and if so, how?". Instead of trying to cram my answer in 140 characters on Twitter, I thought it'd be wise to reply with this blog post. The short answer is: yes, you do need to escape.

He uses the rest of the post to get into the longer answer, a bit more detail about why you should escape and what kinds of things can be done. He points out that, because of how MongoDB queries are created, SQL injection is much more difficult. He does remind you that superglobals can also be used to send arrays too which could lead to unexpected data input. He gives an example of how this would work and why it would be a problem.

So although MongoDB's query language does not require you to build strings, and hence "escape" input, it is required that you either make sure that the data is of the correct data type.

The Code Yellow site has recently posted an article pointing out an issue that's all too common in PHP frameworks, more specifically those that bundle some kind of ORM into their functionality. They wonder if your framework is telling you everything about what they're doing to prevent SQL injection.

We've discovered that SQL injection is to this day not a fully solved problem, even in most popular frameworks. In this post, we'll explain how these frameworks fail at escaping parts of a query, culminating in the discovery of a critical vulnerability in the popular Laravel framework which affects a large percentage of applications.

He starts with an illustration using the FuelPHP framework and the protection it offers from garden variety SQL injection attempts. Unfortunately, things start to break down when it gets much past this typical case. They found this same issue to be a wide-spread problem in many PHP frameworks and tools including the Laravel, CodeIgniter and CakePHP frameworks, each with their own ORMs. He also talks about issues with blacklisting and whitelisting and how, sadly, most of the frameworks just don't support it for model data filtering. There's a mention of some of the work they've done to help try and fix the issue (including patches and contacting authors) and some recommendations of how to correctly quote identifiers in SQL statements.

In his latest post Dougal Campbell shares his findings from a bug he was having with a plugin in WordPress. It revolved around the use of mysql or mysqli and errors being thrown to his logs.

The plugin had previously worked fine (it generates a sidebar widget), and I wasn’t actively working on my site, so I wasn’t really sure when it had quit working. In the course of debugging the problem, I discovered that the plugin was throwing warnings in my PHP error log regarding the mysql_real_escape_string() function. As a quick fix, I simply replaced all of those calls with WordPress’ esc_sql() function. Voila, problem fixed.

He was interested in why this worked, though, and went digging in the code. As it turns out, the WordPress code tries to determine which mysql extension you have support for. As it turns out, his installation fit the "mysqli profile" so the "mysql_real_escape_string" wasn't available. To the WordPress users out there, he suggests esc_sql or $wpdb->prepare() instead.

Pádraic Brady has a new post to his blog about the state of output escaping in PHP and the steps that need to be taken to help prevent and protect applications from the real threat of cross-site scripting.

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.

He goes on to define what "automatic escaping" is and isn't and how it relates to the context of the information (the same data may not always be filtered the same way in every place). He talks about scope-limited escaping, context-aware escaping and an idea that could help make life easier - a content security policy defining how the client should behave when interpreting HTML.

On the Working Software blog there's a new post showing a solution to a issue with escaping quotes in XPath queries that's not just an issue in PHP.

I've been working with the Basecamp API to plugin our IRC bot that we use for time tracking and I'm astounded to learn that escaping single and/or double quotes for XPath queries in PHP does not have a well documented, best practices solution. In fact, it seems as though this is not peculiar to PHP. I took a look around and found this excellent article by "Kushal": http://kushalm.com/the-perils-of-xpath-expressions-specifically-escaping-quotes.

He's put together his own (PHP) solution to the problem - running the entire XPath query through a filtering method that splits it up, replaces the quote characters and combines it back down to a single string.

Alan Skorkin has a recent post to his blog about a trouble that many WordPress users have come across in working with their content and the WP-Syntax plugin (for displaying code) - a special character escaping bug that escapes characters that don't need it.

Suffice to say, [WP-Syntax] does the job fine except for one very annoying issue. Whenever you have any kind of special characters in your code (which you inevitably do e.g. <, >, & etc.), these always render as their escaped representations.

It only happens with the WYSIWYG editor for writing content (which the tool's FAQ recommends turning off) but there's a better solution that Alan found - change a line of code in the plugin to use the htmlspecialchars_decode function to rid your install of this pesky escaping bug.

PHPBuilder.com has a new article from Jason Gilmore on security in command-line applications posted today and what you can do to help protect your scripts from unwanted system command access.

In this tutorial, I'll show you how to securely execute a variety of system-based commands via a PHP script, demonstrating how to build web applications that can tightly integrate with both the operating system and third-party software.

He mentions the proper filtering of input strings (user input), how it can protect your and your application as well as a few examples of using the PHP execution functions (like exec or passthru) and how to apply the shell escaping commands (like escapeshellarg) as a first layer of security.

In a project she's been working on Lorna Mitchell was frustrated with something the CodeIgniter framework does natively - escape SQL statements done through the databaase layer's "select()" method. Thankfully, there was a simple fix to turn this behavior off.

I've been getting increasingly impatient with its tendency to try to escape my SQL code for me - this is a really useful default feature but it seems to assume I don't know what I'm doing and so it puts backticks all over perfectly acceptable SQL code, very annoying!

Thanks to a reply on twitter from damiangostomski to her frustrations she found the optional second parameter you can give the "select()" method, a boolean that tells it whether or not to escape the query (it's mentioned here) for those that were wondering.

Keith Casey has a suggestion for budding (PHP) developers out there looking to jump head first into their first project: "Don't trust the users."

Recently I taught a class of bright-eyed, bushy-tailed PHP'ers just getting their start in the world. They haven't done their first production application and we were working in the "safe" confines of a classroom, but there was one concept that I pounded into their heads: Don't Trust the Users.

Generally, as Keith mentions, users aren't malicious/incompetent/ignorant 99 percent of the time, but there's always that off chance that they are and you need to protect you and your application from it by filtering input and escaping all output to prevent any mishaps.