Ruald Gerber and Toby Compton set out best practices for avoiding security disas ters You

may not think your site has anything worth being hacked for, but websites ar e compromised all the time. The majority of security breaches are not to steal y our data or deface your website, but instead attempts to use your server as an e mail relay for spam, or to setup a temporary web server, normally to serve files of an illegal nature. Hacking is regularly performed by automated scripts writt en to scour the Internet in an attempt to exploit known security issues in softw are. Here are our top 10 tips to help keep you and your site safe online: 1. Keep software up to date It may seem obvious, but ensuring you keep all software up to date is vital in k eeping your site secure. This applies to both the server operating system and an y software you may be running on your website such as a CMS or forum. When secur ity holes are found in software, hackers are quick to attempt to abuse them. If you are using a managed hosting solution then you don't need to worry so much about applying security updates for the operating system as the hosting company should take care of this. If you are using third-party software on your website such as a CMS or forum, yo u should ensure you are quick to apply any security patches. Most vendors have a mailing list or RSS feed detailing any security issues. WordPress, Umbraco and many other CMSes notify you of available system updates when you log in. 2. SQL injection SQL injection attacks are when an attacker uses a web form field or URL paramete r to gain access to or manipulate your database. When you use standard Transact SQL it is easy to unknowingly insert rogue code into your query that could be us ed to change tables, get information and delete data. You can easily prevent thi s by always using parameterised queries, most web languages have this feature an d it is easy to implement. Consider this query: 1. "SELECT * FROM table WHERE column = '" + parameter + "';" If an attacker changed the URL parameter to pass in ' or '1'='1 this will cause the query to look like this: 1. "SELECT * FROM table WHERE column = '' OR '1'='1';" Since 1 is equal to 1 this will allow the attacker to add an additional query to the end of the SQL statement which will also be executed. 3. XSS Cross site scripting is when an attacker tries to pass in JavaScript or other sc ripting code into a web form to attempt to run malicious code for visitors of yo ur site. When creating a form always ensure you check the data being submitted a nd encode or strip out any HTML. 4. Error messages Be careful with how much information you give away in your error messages. For e xample if you have a login form on your website you should think about the langu age you use to communicate failure when attempting logins. You should use generi c messages like Incorrect username or password as not to specify when a user got h alf of the query right. If an attacker tries a brute force attack to get a usern ame and password and the error message gives away when one of the fields are cor rect then the attacker knows he has one of the fields and can concentrate on the other field. Keep your error messages vague 5. Server side validation/form validation Validation should always be done both on the browser and server side. The browse r can catch simple failures like mandatory fields that are empty and when you en ter text into a numbers only field. These can however be bypassed, and you shoul d make sure you check for these validation and deeper validation server side as failing to do so could lead to malicious code or scripting code being inserted i nto the database or could cause undesirable results in your website.

6. Passwords Everyone knows they should use complex passwords, but that doesn t mean they alway s do. It is crucial to use strong passwords to your server and website admin are a, but equally also important to insist on good password practices for your user s to protect the security of their accounts. As much as users may not like it, enforcing password requirements such as a mini mum of around eight characters, including an uppercase letter and number will he lp to protect their information in the long run. Passwords should always be stored as encrypted values, preferably using a one wa y hashing algorithm such as SHA. Using this method means when you are authentica ting users you are only ever comparing encrypted values. For extra security it i s a good idea to salt the passwords, using a new salt per password. In the event of someone hacking in and stealing your passwords, using hashed pas swords could help damage limitation, as decrypting them is not possible. The bes t someone can do is a dictionary attack or brute force attack, essentially guess ing every combination until it finds a match. When using salted passwords the pr ocess of cracking a large number of passwords is even slower as every guess has to be hashed separately for every salt + password which is computationally very expensive. Thankfully, many CMSes provide user management out of the box with a lot of thes e security features built in, although some configuration or extra modules might be required to use salted passwords (pre Drupal 7) or to set the minimum passwo rd strength. If you are using .NET then it's worth using membership providers as they are very configurable, provide inbuilt security and include readymade cont rols for login and password reset. 7. File uploads Allowing users to upload files to your website can be a big security risk, even if it s simply to change their avatar. The risk is that any file uploaded however innocent it may look, could contain a script that when executed on your server c ompletely opens up your website. If you have a file upload form then you need to treat all files with great suspi cion. If you are allowing users to upload images, you cannot rely on the file ex tension or the mime type to verify that the file is an image as these can easily be faked. Even opening the file and reading the header, or using functions to c heck the image size are not full proof. Most images formats allow storing a comm ent section which could contain PHP code that could be executed by the server. So what can you do to prevent this? Ultimately you want to stop users from being able to execute any file they upload. By default web servers won't attempt to e xecute files with image extensions, but it isn't recommended to rely solely on c hecking the file extension as a file with the name image.jpg.php has been known to get through. Some options are to rename the file on upload to ensure the correct file extensi on, or to change the file permissions, for example, chmod 0666 so it can't be e xecuted. If using *nix you could create a .htaccess file (see below) that will o nly allow access to set files preventing the double extension attack mentioned e arlier. 1. deny from all 2. <Files ~ "^\w+\.(gif|jpe?g|png)$"> 3. order deny,allow 4. allow from all 5. </Files> Ultimately, the recommended solution is to prevent direct access to uploaded fil es all together. This way, any files uploaded to your website are stored in a fo

lder outside of the webroot or in the database as a blob. If your files are not directly accessible you will need to create a script to fetch the files from the private folder (or an HTTP handler in .NET) and deliver them to the browser. Im age tags support an src attribute that is not a direct URL to an image, so your src attribute can point to your file delivery script providing you set the corre ct content type in the HTTP header. For example: 1. <img src="/imageDelivery.php?id=1234" /> 2. 3. <?php 4. // imageDelivery.php 5. 6. // Fetch image filename from database based on $_GET["id"] 7. ... 8. 9. // Deliver image to browser 10. Header('Content-Type: image/gif'); 11. readfile('images/'.$fileName); 12.