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.

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

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.

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

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.

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

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.

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.

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.

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.