The layman’s guide to securing your website

Website security

Following on from our article How secure are your passwords? we’ve decided to summarise a list of common website vulnerabilities together with preventative measures or recommended fixes. If you’re currently looking for a web designer, it might be worth noting down points from this article and discussing them with a potential supplier to ensure your new website is as secure as possible.

SQL Injection

This is a common website vulnerability often mentioned in the media, although usually no explanation is given as to exactly what it is.

Many websites sit in front of a database which controls the content on some or all of the pages. More often than not such a database would be in MS SQL or MySQL format. Website pages interact with a database using “SQL queries” – these are a collection of formal statements used to select, update or add data. This could include customers placing orders or logging in to amend or retrieve their information.

Certain characters such as a quotation marks and percentage symbols have a special meaning in SQL queries, and if these characters are maliciously input into a website (most commonly via a registration form or such like) they can be used to destroy or steal data.

For example, you might have a contact form on your site that takes a customer’s name and email address and records it in a database. A malicious user could include a quotation mark in the name field, followed by additional code which is then used to hijack the database in a number of different ways.

How to prevent

At the most basic level there are two main ways of preventing SQL Injection:

1) Validate all user input – you wouldn’t normally expect a person’s name to include a quotation mark or other symbols, so data should be validated and rejected before it makes contact with the database. However, sometimes user input can contain characters that are unsafe in a SQL query but are none-the-less legitimate in context. For example, a dating website that asks a user for their height might accept input in the form of 6’2” (six feet and two inches). To overcome this see step 2.

2) Escape data – escaping refers to the process of making data safe before it makes contact with the database. This is different to validating user input in the fact that even valid data can contain unsafe characters. Escaping data doesn’t remove such characters, but rather makes them safe for contact with the database.

At a more advanced level it’s also advisable to ensure that character sets between pages, scripts and databases are consistent. This can help to prevent non-dangerous characters becoming dangerous if data shifts character set.

Cross Site Scripting

Cross Site Scripting or XSS enables attackers to inject client-side script into web pages viewed by other visitors. This can allow an attacker to steal other user’s data or otherwise interfere with their browsing session.

XSS attacks often happen when user input is later output to a webpage without sufficient validation or cleansing. For example, a user might submit a contact form that, upon success, displays the message, “Thank you for your enquiry John – we will contact you back soon.” The problem is, “John” could maliciously enter unsafe characters in his name. On the subsequent success page these characters could be crafted in such a way so as to call external scripts not controlled by the website owner.

Although the above example would not effect anyone other than the attacker himself, a specially crafted link, email or external webpage can be used to direct unsuspecting users to the site in question and affect them via the exploit.

How to prevent

1) The most common way to prevent XSS attacks is to encode any user input that is output to a page. This also includes user data that is stored in a database and output to a page later on (although it’s best to encode data at the point of output rather than the point of storage).

2) Set the HttpOnly flag for cookies which don’t need to be accessed by client-side scripts

Update 3rd Party Applications

Third party applications such as WordPress and phpBB contain thousands of lines of code which are publicly available for scrutinisation. This means that periodically bugs and security exploits are discovered that can put your website at risk.

As a matter of course all such applications should be updated regularly to the latest versions which can help to remove known issues.

Web Hosting

Securing your web hosting is just as important as securing your website, since both work hand-in-hand. Here are a number of things to consider:

  1. Close down ports and services that are not used.

  2. Restrict database connections to localhost – don’t allow external connections to your database server unless you really need to.

  3. Lock services and administration panels to a fixed IP address if you have one. Use HTTPS rather than HTTP where appropriate.

  4. Use Secure FTP rather than standard FTP.

  5. Use strong passwords and change them regularly.

  6. Ensure database and file permissions are set correctly.

Remember that security is a huge and specialised subject – this article covers some of the basic points that affect many websites day-to-day.

Good luck!

3 replies to “The layman’s guide to securing your website”

  1. Smiling Specialist says:

    The setting for HttpOnly doesn’t provide much protection at all and is easily circumvented. Additionally the HttpOnly protections that exist only apply to session cookies and not regular cookies.

    The use of a cookie nonce can help by making stolen cookies unusable.

  2. Mike P says:

    Can I also add that some sql escaping functions are more suitable than others. I see lots of people still using PHP’s addslashes() when mysql_real_escape_string() is more appropriate. Or alternatively developers could use prepared statements.

    • Gareth says:

      Mike, you are correct. The same also applies to encoding user data that’s output to the screen. It’s not uncommon to see htmlentities() being used with only the first parameter, when in fact that are an additional 3 parameters that should nearly always be used. I didn’t go into great detail about this because I felt it might be too technical for the average layman, which is who this article was aimed at. Thanks for your comments though.

Leave a reply

(won't be published)
Email us Web enquiry form