A fun bit of trivia for the Joomla users out there from Brian Teeman's blog today - why the default user ID is 62 and how it could effect your site's security.

Andrew attempted to give the most complete answer but the truth is the answer is lost in the dim and distant past. There is nothing you can do about it. On every install a superadmin user is created with username "admin" and userid "62".

Since this is a common "feature" of the older Joomla installs, it could potentially be used in a sort of attack on the site. Fortunately, as of the Joomla 1.6 release, the installation allows you to select a username of your own (while still suggesting "admin") with a new change to the user's ID - 42 instead of 61.

Brian Swan has a new post today looking at one way you can protect your web application from potential attack - preventing SQL injection by filtering input.

How to prevent SQL injection in PHP scripts is probably a topic that doesn't need anything more written about it. [...] However, it is important to have fresh information for new Web developers and I don't necessarily agree with some of the most common suggestions for preventing SQL injection. [...] So, this will be yet another post about preventing SQL injection, but I will offer my 2 cents about what I think is the right way to prevent it.

He explains SQL injections for those that are unsure on the concept with a basic form example and what he thinks is a better way to prevent it than just trying to escape the SQL - bound parameters. These allow you to both filter and protect your application from any would-be attacks that might come your way. He is, of course, using SQL Server so the parameter binding is included in the database functionality. Other databases might have to use something like PDO to accomplish the same kind of thing.

On the Zend Developer Zone there's a new tutorial for those using the Zend Framework (and more specifically the Zend_Auth component) on a way that you can prevent identity theft in validating your users.

As I am building my applications, I always try to improve the code I write in some way. Today I thought about the security issues of any PHP application that uses an authenticating system. [...] There is one particular issue that bugged me for some time. The Identity theft - Broken account and session management issue. Why can one so easily still my session id cookie and suddenly gain access to my account in one particular web application?

He shares a class he's developed as a guideline to help your application automatically test to ensure that the information being given by the user is valid. It checks a security level and validates against the user agent and remote IP of the user to ensure they match. These two criteria might not always be the best choices, but it gives you a push in the right direction.

Code is also included to show how to integrate it into your Zend Framework application by loading it into your base controller and using the "hasIdentity" and "hasSecureIdentity" methods to check the user's credentials.

The PHP.net site has posted the release announcement for the latest PHP version in the PHP 5.3.x series - 5.3.2:

The PHP development team is proud to announce the immediate release of PHP 5.3.2. This is a maintenance release in the 5.3 series, which includes a large number of bug fixes. [...] For users upgrading from PHP 5.2 there is a migration guide available here, detailing the changes between those releases and PHP 5.3.

Security/bug fixes included in this release take care of things like:

• Safe_mode validation inside tempnam
• A possible open_basedir/safe_mode bypass in sessions
• Added support for SHA-256 and SHA-512 to php's crypt.
• Fixed a bug in the garbage collector that could cause a crash
• Crashing when using ldap_next_reference

For more information on the release and what was fixed see the Changelog. You can download this release immediately - source code or Windows package.

As mentioned on the main PHP site today, the latest version in the PHP 5.2 series has been released - PHP 5.2.13.

The PHP development team would like to announce the immediate availability of PHP 5.2.13. This release focuses on improving the stability of the PHP 5.2.x branch with over 40 bug fixes, some of which are security related. All users of PHP 5.2 are encouraged to upgrade to this release.

For more information about the changes included in this release you can check out the full release announcement or the Changelog. As always, you can get this latest version from the downloads page.

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 one of his recent posts Alex King looks at three things that most plague WordPress users in their day to day running of their sites - the security of their installation, upgrading when a new version comes out and making good backups of your information just in case.

I often get questions about WordPress security and how best to manage WordPress upgrades. These issues are closely related, and I've thought about them a good deal over the years (and I've been doing this long enough to have experimented with a variety of approaches). These are the approaches I am currently using and recommend for the technically savvy.

For each of the three topics (security, upgrades and backups) he talks a bit about the current situation of it in the WordPress world and offers up some helpful hints to guide you along a good path as well as links to a few services and tools that can help save you when you need that all important file from a backup.

Richard Thomas author of the "Solar Shorts" series has branched out from just talking about the framework and has a new short article posted about security in PHP applications in general.

A search for the phrase "secure php" on Google returns a ton of results but scanning through the first couple pages of results it becomes clear that when you talk about security and PHP people tend to focus on 2 things, the code and PHP itself.

He talks about what should be considered when it comes to PHP applications security, some of the software tools you can use and a few questions to ask yourself to help you get your site along the path to being more secure (like asking about temporary folders, excess packages or firewalls that may or may not be active).

In this recent post to his blog Padraic Brady looks at the Zend Framework security releases that were made the other day - versions 1.9.7, 1.8.5 and 1.7.9 - to correct a number of security issues in each release. For those that are curious, you can find the full list of fixes here.

While an ongoing process, the initial [security] review focused on specific areas most likely to deal directly or indirectly with user input and the output of user sourced data. [...] The review also included an examination of all new components due to enter service with Zend Framework 1.10. This yielded a number of issues whose fixes will preempt their release into a stable version, and have been reported to the relevant lead developers.

Padraic mentions some of the things that were found and corrected in these security releases including the enforcement of a default character set throughout the framework (with new functions to help with keeping your data consistent) and several potential XSS vulnerabilities in components like the Zend_Json, Zend_Dojo_View_Helper_Editor and Zend_Filter_StripTags.

In this recent post to the DevCentral blog (from f5.com) they ask why reusable code, one of the foundations of good development (especially in PHP) is so hard to secure.

Being an efficient developer often means abstracting functionality such that a single function can be applied to a variety of uses across an application. Even as this decreases risk of errors, time to develop, and the attack surface necessary to secure the application it also makes implementing security more difficult.

The article talks about a project the author was working on and how, when he came across a need for a component and found one that worked, they were surprised to see how difficult it would be to secure it without adding on extra code bloat. He describes some of the issue and talks about how the development of the component must not have included any thought into things like input validation or filtering. One suggestion is to employ a firewall to sit in front of the entire application and handle all of these things without changes to the code.