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.

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 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.

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.

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.

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 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).

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.

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.

PHP 5.3.9 release was mostly meant to fix a security bug, but it introduced a new more serious bug. PHP 5.3.10 was just released to fix this issue. [...] This time it is a bug that allows arbitrary remote code execution. This means that it allows to run arbitrary code on the server, injected by an eventual attacker, so it can be used to cause many types of damage inside a server.

The upgrade to PHP 5.3.10 is highly recommended to prevent this issue from effecting your applications. The post also mentions the dropping of Suhosin support (a security plugin for PHP) on the Debian linux distribution's default installation and how the PHP community has reacted to the decision.