In this recent post to Reddit.com, the question of application security is asked - the poster wants recommendations on how he should keep his app safe from would-be attackers:

I can code fairly well in PHP these days, but my security isn't so hot. Is there a tutorial or plugin you guys can recommend as to how I should be protecting my php pages/inputs? I want to avoid common attacks like XSS, inputs with NULL or DROP TABLE etc?

Responses on the post include recommendations related to:

• Using the Chorizo scanner to find common issues in your code
• Using PDO for database connections (with bound parameters)
• Not trusting "$_SERVER"
• Data sanitization

There's also links to a few other resources with more details.

The PHP-Security.net site has two posts related to the recently discovered bug in PHP (hence the new versions) related to the CGI handling in certain server configurations.

In the first they detail more of what the bug is, how it could be exploited and link to the original advisory for the problem. Also included are more details on the issue, including sample avenues of attack.

In the second post they look at the recent PHP release and note that it does not completely rid the language of the problem. They point out that the Rewrite rule that's included in their post (not the one on PHP.net) should be used to prevent this issue from effecting your installations.

PHPMaster.com has a new tutorial posted today (by George Fekete) about preventing cross-site scripting attacks in your PHP-based applications.

Unfortunately, cross-site scripting attacks occurs mostly, because developers are failing to deliver secure code. Every PHP programmer has the responsibility to understand how attacks can be carried out against their PHP scripts to exploit possible security vulnerabilities. Reading this article, you'll find out more about cross-site scripting attacks and how to prevent them in your code.

Included in the tutorial is an example with a simple form and definitions of different types of XSS attacks - reflected XSS, persistent XSS and three ways to prevent them: data filtering, output filtering and data validation. He also links to a few "cheatsheets" to help even more (including this guide and a Zend Framework set of XSS test data.

The PHP project has officially released the latest versions of the language - PHP 5.3.11 and PHP 5.4.1:

The PHP development team announces the immediate availability of PHP 5.3.11 and PHP 5.4.1. These releases focuses on improving the stability of the current PHP branches with over 60 bug fixes, some of which are security related. [...] For a full list of changes in PHP 5.3.11 and PHP 5.4.1, see the ChangeLog. For source downloads please visit our downloads page, Windows binaries can be found on windows.php.net/download/. All users of PHP are strongly encouraged to upgrade to PHP 5.3.11 or PHP 5.4.1.

Several bugs were fixed in both releases including issues with validation of the name of the uploaded file, adding open_basedir checks to readline_write_history/readline_read_history, and the addition of debug info handler to DOM objects.

While not specific to PHP, security is something that all developers need to think about in their applications. To that end, the Infosec Institute has published this guide to helping you prevent SQL injection attacks that could come in via the HTTP headers of requests to your site.

During vulnerability assessment or penetration testing, identifying the input vectors of the target application is a primordial step. Sometimes, when dealing with Web application testing, verification routines related to SQL injection flaws discovery are restricted to the GET and POST variables as the unique inputs vectors ever. What about other HTTP header parameters? Aren't they potential input vectors for SQL injection attacks? How can one test all these HTTP parameters and which vulnerability scanners to use in order to avoid leaving vulnerabilities undiscovered in parts of the application?

They start by describing the different kinds of headers that the attacks could come in on - GET, POST, cookies and the other HTTP headers. According to some results, the HTTP headers option is the least protected in most common applications. He includes some good examples of headers that might contain malicious data such as:

• X-Forwarded-For
• User-agent
• Referer

Techniques are also included showing you tools and methods to help test your own applications including some in-browser tools and external applications (like Sqlmap, Nessus, WebInspect, SkipFish and Wapiti) with some average scores from running them on various coverage scores.

Gareth Heyes has pointed out an interesting tool today for analyzing the source of your application and trying to discover security-related issues: RIPS

RIPS is a tool written in PHP to find vulnerabilities in PHP applications using static code analysis. By tokenizing and parsing all source code files RIPS is able to transform PHP source code into a program model and to detect sensitive sinks (potentially vulnerable functions) that can be tainted by userinput (influenced by a malicious user) during the program flow. Besides the structured output of found vulnerabilities RIPS also offers an integrated code audit framework for further manual analysis.

The project site lists out the features that come with the tool, what it searches for (including command execution issues, header injection, file manipulation and SQL injection) and some example screenshots of its interface. You can download the latest version and try it out for yourself.

Pádraic Brady has written up an exhaustive guide to using htmlspecialchars correctly and securely in your applications (though it's technically how "not to use it"). This is part one of a series looking at preventing cross-site scripting in PHP applications.

While it's no harm poking fun at ourselves, in PHP we do have a serious problem. Cross-Site Scripting (XSS) remains one of the most significant classes of security problems afflicting PHP applications. Despite years of education, community awareness and the development of frameworks which can offer a huge boost in consistent practices - things are not getting any better.

So, I finally figured out what the core problem is: PHP programmers are completely clueless about XSS. It's that simple. Instead of going out and studying the topic, we blindly follow some preferred herd of people offering advice with heartfelt conviction despite the fact that they are probably just as ignorant as the rest of us. Does that sound like the behaviour of something which allegedly evolved into an intelligent species? The result is a mix of ignorance and stagnant knowledge that leaves PHP in an unenviable position beset by wrongheaded zealots.

He introduces the htmlspecialchars function and how it has been generally assumed a good method for presenting XSS attacks. He talks about issues with quotes, problems that IE6 seems to have that no one else does and the all-important third parameter of the function (character set detection) and the optional fourth (decoding HTML entities automatically).

He's created this github repository with the examples from the post.

The PHP project has officially announced the latest release candidate for the upcoming PHP 5.4.0 series - PHP 5.4.0 RC8.

The PHP development team would like to announce the 8th release candidate of PHP 5.4. PHP 5.4 includes new language features and removes several legacy (deprecated) behaviours. Windows binaries can be downloaded from the Windows QA site. THIS IS A RELEASE CANDIDATE - DO NOT USE IT IN PRODUCTION! This is the 8th release candidate. The release candidate phase is intended as a period of bug fixing prior to the stable release. No new features should be included before the final version of PHP 5.4.0.

Improvements in this release include bugfixes for an issues with htmlspecialchars/htmlentities as well as improving on the "max_input_vars" configuration setting to work better with nested variables. You can find the full list of changes in the NEWS file and download the release for testing from the QA site (Windows binaries).

The Boston PHP User Group will be having their next meeting tonight (the 15th) at 7pm at the Microsoft N.E.R.D Center in Cambridge. The featured speaker for the evening is Chris Shiflett, a well-known member of the PHP community. He'll be speaking on "Security-Centered Design: Exploring the Impact of Human Behavior".

Join Boston PHP and O'Reilly Author Chris Shiflett as we take you through a fascinating talk on the human behavior and social aspect of security. We'll explore topics such as change blindness and ambient signifiers, and we'll show some real-world examples that demonstrate the profound impact human behavior can have on security. If your a designer, developer, human interaction designer, you won't want to miss this talk.

So far there's over 150 marked as attending - if you plan on trying to make it tonight, be sure you RSVP so they know how many to expect.

Davey Shafik has a recent post to his blog about what he calls "The Blowfish Debacle" - the issues that came up with the PHP 5.3.7 release to upgrade the crypt_blowfish version that resulted in a larger error being introduced.

This was a great security fix, solving an issue with insecure passwords due to incorrect behavior. HOWEVER, what wasn't made clear, is that this change was actually a backwards compatibility break. If you upgraded to 5.3.7+ data hashed pre-5.3.7 would no longer match data hashed post-5.3.7; this means if you use it for passwords, it will no longer match. So what's the deal here?

He talks about the differences in the two methods of encryption, the newer being the "more correct" way of doing things. If you need the backwards compatibility because of previously hashed values, you can use the "$2x$" prefix instead of the usual "$2a$". He includes a snippet of code that can be used to upgrade all of your previously hashed blowfish passwords up to the new format.