News and Insight

A blog on Website Security

At Wanstor this week, we have been discussing website security. This is because of news that the Information Commissioner’s Office or ICO had to take its website down after a warning that hackers were taking control of visitor’s computers to mine cryptocurrency.

Following this story, some of our customers have been in contact regarding website security and suggested best practices. In light of this, Wanstor’s security experts have come together to develop the following high level guide to website security.

You may not think your website has anything worth hacking, but corporate websites are compromised all the time. Despite what people think, the majority of website security breaches are not to steal data or deface a website. Instead they are hacked to use servers as an email relay for spam, or to setup a temporary web server, normally to serve files of an illegal nature. Other common ways to abuse compromised machines include using your company servers as part of a botnet, or to mine for Bitcoins. You could even be hit by ransomware. Hacking is regularly performed by automated scripts written to scour the Internet in an attempt to exploit known website security issues in software. By following the tips below, your website should be able to operate in a safer way and put hackers and the tools they use off from attack.

Keep software updated

It may seem obvious, but making sure you keep all software updated is vital to keeping your site secure. This applies to both the server operating system and to any software you may be running on your website such as a CMS or forum. When holes are found in website security software, hackers are quick to attempt abuse. If you are using a managed hosting solution, then your hosting company should take care of any updates, so you do not need to worry about this – unless your hosting company contacts you to tell you to worry!

If you are using third-party software on your website such as a CMS or forum, you should make sure you are quick to apply any security patches. Most vendors have a mailing list or RSS feed detailing any website security issues. Many developers use tools like Composer, npm, or RubyGems to manage their software dependencies, and security vulnerabilities appearing in a package you depend upon but aren’t paying any attention to is one of the easiest ways to get caught out. Make sure you keep your dependencies up to date and use relevant tools to get automatic notifications when a vulnerability is announced in one of your components.

SQL injection

SQL injection attacks occur when attackers use a web form field or URL parameter to gain access to or manipulate your database. When you use standard Transact SQL, it is easy for such individuals to insert rogue code into your query that could be used to change tables, retrieve information and delete data. You can easily prevent this by always using parameterised queries – most web languages have this feature and it is easy to implement.

XSS

Cross-site scripting (XSS) attacks inject malicious JavaScript into your pages, which then runs in the browsers of your users, allowing page content to be modified or information to be stolen or transmitted to the attacker. For example, if you show comments on a page without validation, attackers might submit comments containing script tags and JavaScript, which could run in every other user’s browser and steal their login cookie, allowing the attacker to take control of accounts owned by each user who views the comment. You need to ensure that users cannot inject active JavaScript content into your pages.

The key here is to focus on how your user-generated content could escape the bounds you expect and be interpreted by the browser as something other than what you intended. This is similar to defending against SQL injection. When dynamically generating HTML, use functions which explicitly make the changes you’re looking for, or use functions in your templating tool that automatically ensure appropriate escaping, rather than concatenating strings or setting raw HTML content.

Another powerful tool in the XSS defender’s toolbox is Content Security Policy (CSP). CSP is a header your server can return which tells the browser to limit how and what JavaScript is executed in the page, for example to disallow running of any scripts not hosted on your domain, disallow inline JavaScript. Mozilla have an excellent guide with some example configurations. This makes it harder for an attacker’s scripts to work, even if they can get them into your page.

Error messages

Be careful with how much information you give away in error messages. Provide only minimal errors to your users, to make sure they do not leak secrets present on your server. Although tempting, do not provide full exception details either, as these can make complex attacks like SQL injection far easier. Keep detailed errors in your server logs, and show users only the information they need to see.

Server side validation

Validation should always be done both on the browser and server side. The browser can catch simple failures like mandatory fields which are empty and when you enter text into a numbers only field. These can however be bypassed, and you should 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 into the database or could cause undesirable results in your website.

Passwords

Everyone knows they should use complex passwords, but that doesn’t mean they always do. It is crucial to use strong passwords to your server and website admin area, but equally also important to insist on good password practices for your users to protect the security of their accounts. As much as users may not like it, enforcing password requirements such as a minimum of around eight characters, including an uppercase letter and number will help to protect their information in the long run. Passwords should always be stored as encrypted values, preferably using a one way hashing algorithm. Using this method means when you are authenticating users you are only ever comparing encrypted values.

In the event of someone hacking in and stealing your passwords, using hashed passwords could help damage limitation, as decrypting them is not possible. The best someone can do is a dictionary attack or brute force attack, essentially guessing every combination until it finds a match.

Thankfully, many CMS’s provide user management out of the box with a lot of these website security features built in, although some configuration or extra modules might be required to use to set the minimum password strength. If you are using .NET then its worth using membership providers as they are very configurable, provide inbuilt website security and include readymade controls for login and password reset.

File uploads

Allowing users to upload files to your website can be a significant website security risk, even if it’s simply to change their photo, background picture or avatar. The risk is that any file uploaded however innocent it may look, could contain a script that when executed on your server completely opens up your website. If you have a file upload form then you need to treat all files with great suspicion. If you are allowing users to upload images, you cannot rely on the file extension 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 check the image size are not fool proof. Most images formats allow storing a comment 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 execute files with image extensions, but it isn’t recommended to rely solely on checking 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 make sure ensure the correct file extension, or to change the file permissions so it can’t be executed.

In Wanstor’s opinion, the recommended solution is to prevent direct access to uploaded files. This way, any files uploaded to your website are stored in a folder 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. Image 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 correct content type in the HTTP header.

The majority of hosting providers deal with the server configuration for you, but if you are hosting your website on your own server then there are few things you will want to check. E.g. Make sure you have a firewall setup, and are blocking all non-essential ports.

If you are allowing files to be uploaded from the Internet only use secure transport methods to your server such as SFTP or SSH. Where possible have your database running on a different server to that of your web server. Doing this means the database server cannot be accessed directly from the outside world, only your web server can access it, minimising the risk of your data being exposed. Finally, don’t forget about restricting physical access to your server.

HTTPS

HTTPS is a protocol used to provide security over the Internet. HTTPS guarantees users that they’re communicating with the server that they should be, and that nobody else can intercept or modify the content in transit. If you have anything that your users might want to remain private, it’s highly advisable to use only HTTPS in delivering it. That of course means credit card and login pages. A login form will often set a cookie for example, which is sent with every other request to your site that a logged in user makes, and is used to authenticate those requests. An attacker stealing this would be able to perfectly imitate a user and take over their login session. To defeat these kind of attacks, you almost always want to use HTTPS for your entire site.

Website security tools

Once you think you have done all you can, then it’s time to test your website security. The most effective way of doing this is via website security tools, often referred to as penetration testing or pen testing for short. There are many commercial and free products to assist you in this. They work on a similar basis to scripts hackers will use in that they test all know exploits and attempt to compromise your site using some of the previous mentioned methods such as SQL injection.

Some free tools that are worth looking at include:

Netsparker (Free community edition and trial version available). Good for testing SQL injection and XSS.

OpenVAS claims to be the most advanced open source security scanner. Good for testing known vulnerabilities, currently scans over 25,000. But it can be difficult to setup and requires a OpenVAS server to be installed which only runs on *nix. OpenVAS was fork of Nessus before it became a closed-source commercial product.

io is a tool offering a free online check to quickly report which security headers mentioned above (such as CSP and HSTS) a domain has enabled and correctly configured.

Xenotix XSS Exploit Framework is a tool from OWASP (Open Web Application Security Project) that includes a huge selection of XSS attack examples, which you can run to quickly confirm whether your site’s inputs are vulnerable in Chrome, Firefox and IE.

The results from automated tests can be daunting, as they present a wealth of potential issues. The important thing is to focus on the critical issues first. Each issue reported normally comes with a good explanation of the potential vulnerability. You will probably find that some of the issues rated as low or medium in importance aren’t a concern for your site. If you wish to take things a step further then there are some further steps you can take to manually try to compromise your site by altering POST/GET values. A debugging proxy can assist you here as it allows you to intercept the values of an HTTP request between your browser and the server. A popular freeware application called Fiddler is a good starting point.

So what should you be trying to alter on the request? If you have pages which should only be visible to a logged in user then try changing URL parameters such as user id, or cookie values in an attempt to view details of another user. Another area worth testing are forms, changing the POST values to attempt to submit code to perform XSS or to upload a server side script.

Hopefully these tips will help keep your site and information safe. Thankfully most Content Management Systems have inbuilt website security features; it is a still a good idea to have knowledge of the most common security exploits, so you can make sure that you are covered.