PHPMaster.com has posted a new article with some high level security tips and reminders for PHP developers when wanting to help prevent issues with their applications. The article provides eight tips, each with a brief description.

When it comes to application security, in addition to securing your hardware and platform, you also need to write your code securely. This article will explain how to keep your application secure and less vulnerable to hacking.

The good practices they recommend include input data validation, protecting against XSS attacks, preventing SQL injections, protecting session data, proper error handling and protecting included files. There's some good reminders here, but it barely scratches the surface of effectively protecting your application. These tips are the "low hanging fruit" for securing your app, so be aware that there's more things to worry about than just these eight.

On PHPClasses.org today they've posted their latest "Lately in PHP" podcast - episode 21, "Is PHP Source Quality really Good or is it still Insecure?".

A study from Coverity claims that the source code of Open Source projects such as PHP has a low defect rate. Meanwhile, a few weeks ago, the security expert Stefan Esser claims that PHP source security bug prevention has a lot to be desired because PHP core developers do not have the habit of using source code auditing tools to prevent security bugs. The matter of the PHP source code quality and security bug prevention was one of the main topics discussed by Manuel Lemos and Ernani Joppert in episode 21 of the Lately in PHP podcast.

You can listen to this latest episode either via the in-page player or by downloading the mp3 directly. You can also subscribe to their feed to get this episode automatically (and past/future ones too).

Ulf Wendel has a new post today with details on using stored procedures with mysqli - not overly difficult if you know how to handle the IN, OUT and INOUT parameters. He includes a few code examples showing how to use them.

Out of curiosity I asked another friend, a team lead, how things where going with their PHP MySQL project, for which they had planned to have most of their business logic in stored procedures. I got an email in reply stating something along the lines: "Our developers found that mysqli does not support stored procedures correctly. We use PDO.". Well, the existing documentation from PHP 5.0 times is not stellar, I confess. But still, that's a bit too much... it ain't that difficult. And, it works.

He describes the three parameters (IN, OUT and INOUT) and gives some examples of setting/getting them from your SQL statements. They're all still set up using the query method on your connection as well as handling the result sets that come back and working with prepared statements.

In response to this article from DevShed about creating a "simple and secure login script", Anthony Ferrara has written up this post to help dispel some of the inaccuracies, bad practices and security issues that could result from DevShed's code.

I decided to click the link [in my feed reader] and give the article a read. Not overly shocking was the fact that I didn't find the content of the article to be, how shall I say this..., overly factual. It's not really a "tutorial", but more of a "here's some code that's secure". A quick review of the code found more than one vulnerability, and some significant things that I would change about it (as well as a few "really bad practices").

He walks through each of the files included in the original tutorial - Authenticate.php, Register.php and Logout.php - and talks about things like brute force detection, password verification, registration handling and session serialization. He finishes it off with a list of twelve overall issues he noticed during his work along with solutions for each (usually very simple ones too).

In this new tutorial on DevShed, they walk you through the creation of a secure login script that uses sha256 encryption, a captcha to prevent automated signups, XSS attack protection and several other features.

Recent advancements in PHP offer the developer a variety of tools to improve the security of login systems. [...] This programming tutorial will teach you how to create a simple, yet secure login script utilizing PHP using MySQL and bracing for XSS attack prevention.

Other features include no persistent logins, preventing direct file access, an idle timeout on the user session, protection against session fixation and anti-brute force measures. Full (procedural) code is provided as well as screenshots from phpMyAdmin showing the database table structure. You can grab the code for the project here.

In a response to this post that introduced some basic security methods for your applications, Anthony Ferrara has posted some corrections and updates to the suggested methods, even pointing out where some of them are completely wrong.

Today an article popped into my feed reader that raise my eyebrows. The article's title is "Building Secured Web Applications Using PHP - The Basics". The summary of the item looked interesting, so I decided to open it up...What I found blew me away. It was filled with loads of bad information including some down-right wrong suggestions. Let me go through point by point and shed some light on the subject...

His response goes back through the original article by section header and explains either why the advice was bad and/or the more correct way to do things.

Security is not something you can learn in a page. It's not something that you can learn in a single book. It takes a lot of time and effort. It should not be trivialized into a simple "Do this and you'll be secure" style post. It sends the wrong message...

Michael Nitschinger has a new post to his blog today showing how you can secure the forms in Lithium using the handy CSRF token implemented directly in the framework.

CSRF (Cross-Site-Request-Forgery) attacks work by sending arbitary (form) requests from a victim. Normally, the receiving site (in our case the Controller who processes the form data) doesn't know where the data comes from. The CSRF protection in Lithium aims to solve this problem in an elegant and secure way. You can read more about those attacks here. Note that you'll need to clone the latest master branch of Lithium if you want to try it out now.

There's two parts to the protection, one on either side of things - a field in the form output and a check in the controller to see if the submitted value is correct. He includes code for a simple form (a title field and submit button) that lazy loads the Security helper and generates the token for you. He walks through the controller side of things a line at a time and includes a sample logging/forwarding bit in the second example to redirect users when the CSRF check doesn't pass.

In a new post to his blog Till Klampaeckel looks at something the Zend Framework's Zend_Db component dosen't seem to support - an "IN" on a fetchAll - and how he worked around it.

The IN-clause is only supported when I wrap my statement with Zend_Db_Select, which is something I rarely do. Part of the reason is that I still don't feel comfortable writing my SQL in a DSL which doesn't really do anything besides wrapping a string into an object and IMHO it doesn't add to readability either. And the other reason is that I don't plan to run this import against any other database than MySQL. Which is why I don't see the need for abstraction either.

He shows some failing code where the IN isn't populated correctly when an array is passed in and the warnings that come with it. He solution's pretty simple, though - rewrite the query string before sending it with the correct number of bind locations ("?") for the number of parameters. In the comments, other approaches are suggested including using a simple select() call or tricking the bindings with a special kind of array.

On the PHPBuilder.com site today there's a new tutorial posted from Octavia Anghel about creating a login for your site that's powered by Ajax and uses a bit more security than normal. It includes hooks to use the Ajax Server Secure Layer or an OpenSSL connection.

In this article you will learn how to write a login application in PHP using Ajax and SSL/TLS in two ways either using aSSL (Ajax Server Secure Layer), a library that implements a technology similar to SSL without HTTPS or a simple Ajax and OpenSSL, an open source implementation of the SSL and TLS protocols.

They start with the aSSL method and link you to a download of the tool as well as some sample code to help you get started passing data to it via the session. The second example shows the OpenSSL method, mostly consisting of checking on the server side of the certificate that's passed along with the request.

On NETTUTS.com today there's a new tutorial about installing and configuring a secure WordPress installation for your site.

A comprehensive WordPress installation, albeit simple to produce, often requires multiple steps '" many of which can easily be omitted accidentally. How many times have you forgotten to customize your permalink structure? How about adding in a sitemap plugin? What about changing your timezone? If you've installed WordPress more than once, chances are you've missed something. Take the following steps and you'll never miss anything again.

Some of the steps are larger - "Get WordPress from SVN", "Add .htaccess Rules", "Apply the 4G Blacklist" - and some are smaller changes like setting up profiles, changing read/write/discussion settings and generating a sitemap. This is a great guide even if you already have WordPress installed.