In his latest post Padraic Brady talks some about the recent security issues that happened with Ruby on Rails that allowed for remote code execution and how, if you use code blindly, you could be in for a similar fate.

Code execution vulnerabilities are, by definition, hideous monsters. The ability for external inputs to enter an execution context (i.e. injecting or manipulating code that is executed on the server) can be difficult to spot through the haze of convenience that such machinations are often designed to deliver. In Rail's case, that convenience was to automatically cast data entries in XML or YAML inputs into Ruby types including, unfortunately, Symbols and Objects.

These types of "buried" code execution vulnerabilities are still easy to locate in PHP, at least, because you are still restricted to normal code execution pathways in the absence of Ruby's dark magic, e.g. eval(), include(), require_once(), system() and, let's not forget, unserialize().

He talks about how, if you're not careful with the code (third party libraries) that you use in your applications - or don't adhere to good security practices in your own - you could be vulnerable to a similar style of attack. After some investigation on his part, he discovered an issue related to this in the Symfony2 YAML parser (now fixed with a new release).

To summarise… Pay attention to competing applications or frameworks - their problems may also be your problems. If you're worried about arbitrary code execution vulnerabilities then audit your code. You can even, as a sanity check, use grep to find uses of functions like eval(), unserialize(), etc and analyse where their parameters' might originate from.

On PHPMaster.com there's a continuance of a previous article about security in PHP applications talking about a few more considerations when trying to make things secure.

In a previous article, I talked about some common security vulnerabilities that can affect your PHP web application. But there are other things besides those ten (okay, seven) attacks to think about when you're developing. And so, this article offers a compendium of miscellaneous things that are security related; things you should do, things you shouldn't do, things that other people might try to do, whatever it takes to make an article long enough for my editor to be satisfied with it.

He talks some about the settings that you might need to tweak in your "php.ini" server-side configuration file, some hints on filtering data (like using filter_input) and what to watch out for with error reporting. He also mentions session fixation and the protection of user data and passwords to keep them out of the hands of would-be attackers.

The PHP project has released another update to both the 5.3.x and 5.4 revisions of the language correcting the bug that was found dealing with a flaw in CGI-based setups.

The PHP development team would like to announce the immediate availability of PHP 5.4.3 and PHP 5.3.13. All users are encouraged to upgrade to PHP 5.4.3 or PHP 5.3.13 The releases complete a fix for a vulnerability in CGI-based setups (CVE-2012-2311). Note: mod_php and php-fpm are not vulnerable to this attack. PHP 5.4.3 fixes a buffer overflow vulnerability in the apache_request_headers() (CVE-2012-2329). The PHP 5.3 series is not vulnerable to this issue.

Users are encouraged to upgrade their applications, especially those using CGI-based setups. You can find the latest source on the downloads page and the Windows binaries on windows.php.net.

The PHP development team has officially announced the release of the latest version of PHP in the 5.3.x series - PHP 5.3.10:

The PHP development team would like to announce the immediate availability of PHP 5.3.10. This release delivers a critical security fix. [...] Fixed arbitrary remote code execution vulnerability reported by Stefan Esser, CVE-2012-0830.

It is highly recommended that users upgrade to this latest version to avoid falling victim to this recently introduced bug relating to the new "max_input_vars" setting added to protect from the overflow issue recently brought up in the PHP community.

On the PHPClasses.org blog today there's a new post looking at the security vulnerability that effected not only PHP but lots of other languages making them susceptible to attack from the outside.

In PHP and several other languages used to implement Web applications, arrays are used to store the values of request variables such as $_GET, $_POST, $COOKIE, etc.. IF you receive a request with a large number of request values, until recent versions PHP may run into trouble.

He goes on to explain why there's an issue with the array overloading and what PHP has done in recent releases to help correct the issue - the max_input_vars setting in the php.ini. He also points out that this is not a new issue - it was originally identified back in 2003 (with a video of the original presentation). He points out that the most recent releases of the PHP language have this fix in them and, if at all possible, you should upgrade to protect your applications.

On the Script Tutorials blog today there's a good summary post reminding you of some of the common security issues that your web application can face, mostly due to improper validation and filtering.

Our new article focuses on security in web. Many beginners (and not only) web programmers sometimes can make mistakes when developing its web applications. Our article is intended to eliminate potential gaps in knowledge web developers. It is quite possible that you already know something, but I'll be incredibly happy if you learn anything new. Today we learn about most popular exploits (with samples).

Security issues that made their list include:

• SQL injections
• Cross-site scripting/Cross-site Request Forgeries
• Remote & local file inclusion
• Displaying errors on production
• Including .svn (or any version control meta) files in the production release

As Ruslan Yakushev points out in this new blog entry, the same security issue that's effecting ASP.NET pages running on IIS web servers can still open up PHP scripts running on the same server.

Microsoft has recently released a Security Advisory about a security vulnerability in ASP.NET. This vulnerability exists in all versions of ASP.NET. The PHP applications running on IIS are also subject to this vulnerability if ASP.NET is enabled in IIS.

The issue allows attackers to access the contents of various files on the server and could allow them to tamper with the data inside. Ruslan notes that, while Microsoft is coming up with a fix, one of the safest things you can do is either completely disable ASP.NET in the IIS server or use this workaround.

Beth Tucker Long has posted a new warning about a possible issue with session IDs in PHP dealing with weak random numbers being generated by the language when making the IDs.

Seclists.org has posted an advisory titled "Weak RNG in PHP session ID generation leads to session hijacking." RNG stands for Random Number Generation, and the advisory is warning that not enough entropy is being used to seed the RNG; this, in turn, can lead to a reduced number of possible session IDs under certain specific conditions, thus making brute force session spoofing easier, if not bringing it into the realm of feasibility.

The threat is only marked at a "medium" level of severity, but it could still cause problems if you're not careful. There are specific conditions that have to be in place for it to be a problem including using the standard PHP session generation and that the app shares the information about remote users. To protect yourself you can either install Suhosin and don't use the result of set an external source for entropy to help randomize the session ID even more.

An advisory has been issued on the PEAR blog about two packages - Net_Traceroute and Net_Ping - that could expose your site to a security issue, a remote arbitrary command injection.

Net_Ping is an OS independent wrapper class for executing ping calls from PHP. Net_Traceroute is an OS independent wrapper class for executing traceroute calls from PHP. When input from forms are used directly, the attacker could pass variables that would allow him to execute remote arbitrary command injections.

You can use filtering as a workaround until your packages are updated on your server. You can upgrade to the latest packages here: Net_Ping, Net_Traceroute.

In a recent post to his blog Rafael Dohms reminds readers to not forget about the security of their applications because it can be "a huge mistake which can take a turn for the worse."

I have ran into lots of excuses for ignoring security in the past, one of them is the recurring "This is just a simple application, it has no sensitive data", this may be a valid point for the person repeating it like a mantra, especially because this person is generally suffering of great pressures , short timeframes and a lack of proper management ready to deal with web development. [...] Whatever the reason is for neglecting security the consequences can escalate much higher then the "non-sensitive data" of the application.

He looks at a specific case where a security issue was found in a large Brazillian mobile company's website that was caused by improper filtering on a $_GET parameter, leaving it open to possible attack. Through it, he could load the information for sensitive system-related files and found more on the machine than just the site he was working with.