01. Keep software up to date
It may seem obvious,
but ensuring you keep all software up to date is vital in keeping your site
secure. This applies to both the server operating system and any software you
may be running on your website such as a CMS or forum. When website security
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, you should ensure
you are quick to apply any security patches. Most vendors have a mailing list
or RSS feed detailing any website security issues. WordPress, Umbraco and many
other CMSes notify you of available system updates when you log in.
02. SQL injection
SQL injection
attacks are when an attacker uses a web form field or URL parameter 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 used to
change tables, get 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.
Consider this query:
"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:
"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.
03. XSS
Cross site scripting
is when an attacker tries to pass in JavaScript or other scripting code into a
web form to attempt to run malicious code for visitors of your site. When
creating a form always ensure you check the data being submitted and encode or
strip out any HTML.
04. Error messages
Be careful with how
much information you give away in your error messages. For example if you have
a login form on your website you should think about the language you use to
communicate failure when attempting logins. You should use generic messages
like “Incorrect username or password” as not to specify when a user got half of
the query right. If an attacker tries a brute force attack to get a username
and password and the error message gives away when one of the fields are
correct then the attacker knows he has one of the fields and can concentrate on
the other field.
Keep your error messages vague
05. Server side validation/form
validation
Validation should
always be done both on the browser and server side. The browser can catch
simple failures like mandatory fields that 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.
06. 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 such as SHA. Using this method means when you are authenticating
users you are only ever comparing encrypted values. For extra website security
it is 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 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. When using salted passwords the process 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 these website
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
password strength. If you are using .NET then it's worth using membership
providers as they are very configurable, provide inbuilt website security and
include readymade controls for login and password reset.
07. File uploads
Allowing users to
upload files to your website can be a big website 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
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 full 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 ensure the correct file extension, or to change
the file permissions, for example, chmod 0666 so it can't be executed. If
using *nix you could create a .htaccess file (see below) that will only allow
access to set files preventing the double extension attack mentioned earlier.
deny from all
<Files ~
"^\w+\.(gif|jpe?g|png)$">
order deny,allow
allow from all
</Files>
Ultimately, the
recommended solution is to prevent direct access to uploaded files all
together. 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.
Most 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.
Ensure you have a
firewall setup, and are blocking all non essential ports. If possible setting
up a DMZ (Demilitarised Zone) only allowing access to port 80 and 443 from the
outside world. Although this might not be possible if you don't have access to
your server from an internal network as you would need to open up ports to
allow uploading files and to remotely log in to your server over SSH or RDP.
If you are allowing
files to be uploaded from the Internet only use secure transport methods to
your server such as SFTP or SSH.
If 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.
09.SSL
SSL is a protocol
used to provide security over the Internet. It is a good idea to use a security
certificate whenever you are passing personal information between the website
and web server or database. Attackers could sniff for this information and if
the communication medium is not secure could capture it and use this
information to gain access to user accounts and personal data.
Use an SSL certificate
10. 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 the use of some website security tools,
often referred to as penetration testing or pen testing for short.
There are many commercial
and free products to assist you with 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:
- 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 is fork of a Nessus before it
became a closed-source commercial product.
