There are pickpockets in the desert

Back in August 2005 I wrote a piece on the relative security of Linux versus Windows (ie open source versus proprietary) systems in an article entitled “There are no pickpockets in the desert“. The premise of the article was that open source systems appeared to be more secure because they had not yet had the attention that proprietary systems had had for hacks and cracks. In other words, the hackers had not ventured out en masse into the untapped desert of open source systems.

In November 2005, the Lupper Worm (a significant Linux security vulnerability) was revealed (see “The tip of the iceberg“) and in February 2006 I wrote about “PHP Apps a growing target for hackers“. The trend was clear that open source systems, and particularly PHP applications, were less secure than first thought.

In an article dated 21st December 2006, The Register scrutinised PHP Security to attempt to better understand why this trend is happening and why PHP is less secure that once thought. So it appears now that the hackers have ventured en masse into the desert of PHP applications.

The article raises a number of key points which need to be understood to dispel any myth or bad press that PHP may well receive through misquoting. The main point is:

The majority of security flaws detected in applications written in PHP are not as a result of the language itself, but how it has been used by the developer to build the application.

To quote from the article:

A search of the database, maintained by the National Institute of Standards and Technology (NIST), found that web applications written in PHP likely account for 43 per cent of the security issues found so far in 2006, up from 29 per cent in 2005. While flaws in the language itself account for a very small percentage the total, the problems with PHP underscore the difficulty that developers – many of them amateurs – have in locking down applications written in the language, said Peter Mell, senior computer scientist for the NIST and the program manager for the National Vulnerability Database.

The message to clients is very clear – security is paramount on the Web and it is more complex to build better security in a web application than it is in a standalone desktop application by the virtue that the website (application) is exposed to anybody and everybody 24 hours a day, 7 days a week, 365 days a year.

So, is ASP or .NET inherently any more secure? Some would argue that this is the case, but it is actually the Web environment itself that creates many of the security issues and not the language itself. Here are some of the top security issues that affect a Web application:

• Cross Site Scripting (XSS): This is where a hacker uses a script to auto-complete forms on your site to add information to your web site. This is a common technique that hackers use to post spam to forums or via your “contact us” form.
• SQL Injection: This is where a hacker abuses a form on your website (often login forms) to append database code to the script and reveal information about your users, and/or change or delete data.
• Data Validation: Any information input into a form or appended to the query string needs to be checked and double checked. If it’s not in the range that’s expected the application will have undesirable reactions (see SQL Injection above for example).
• Don’t store passwords as plain text: This may be “nice” because it’s easy to look up a password, but it’s also easy for hackers to do this. Always encrypt passwords.
• Encrypt sensitive data: Even outside of the database! Any sensitive data should be encrypted (or at the very least obfuscated) to avoid discovery or abuse. However, on virtual hosting systems (see “Types of Hosting“) this is not always possible due to the security restrictions that ISPs impose on you to prevent their systems being hacked.
• Do some server housekeeping: Check the settings and make sure the server is set up securely – for example turn “safe mode” on (for PHP) and restrict other unnecessary services.
• Use sessions: If you need to store data securely, use server-side sessions to handle this. However, don’t use cookie-less sessions as this exposes you to session hijacking. A standard cookie-based approach is recommended as no sensitive data sits on the visitors machine, but the session is secured to their visit only. A cookie-less session means that the session data can be easily exposed.

The key thing to ensure is that any web application development takes into account these security issues (and any others the client’s particular application requires) and builds in a secure architecture. Remember that integrating any third-party applications (such as phpBB, the open source forum system) may expose you to unexpected security vulnerabilities and/or require constant upgrades to keep ahead of the security problems that may be found with such applications. For PHP, the book “Essential PHP Security“, written by the internationally recognised PHP security expert Chris Shiflett and published by O’Reilly, provides an excellent synopsis of the key security issues affecting PHP applications and their hosting environment, as well as a recipe book of methods for how to deal with them.

You may initially be shocked at the cost of what appears to be a small web system, but the cost of a lack of security for your business may prove to be more expensive in the long run. Once you get beyond a basic Level 2 marketing site (simple meaning not requiring a database or forms) on our Internet Maturity Model, you need to consider security seriously.