The best website is a secure website. To be sure, securing a website does require a bit of effort, but failing to secure your website properly can lead to so many problems, it’s actually crazy not to put in the effort.
Having said that, it really doesn’t do a lot of good to just wake up one morning and declaring “Today I am going to secure my website!”, because you need to have a proper plan before you start tinkering with the system.
So how do you come up with a security plan? It requires you to know your system, test for vulnerabilities, and patch up any leaks. You should also regularly check your website (including source code) for any signs of alteration, and occasionally check your logs for signs of suspicious entry.
1. Get to know your system and understand it’s weaknesses
The first step in securing your system is to know what system you have and how to secure it. Even the selection of what system you are going to use for your website should form a part of your security plan. In particular, you should know that the more popular a given system type is, the more likely it is that somebody will try to exploit it, and the more likely it is that they will succeed.
It’s true that security through obscurity is not really security, but it may help to make you a less viable target. WordPress is one of the most popular CMS platforms that people use for websites, and consequently it’s also the system that people try the most often to hack. This is helped a bit by the fact that WordPress is notoriously difficult to customize, and so very few users have the ability or even the bravery to attempt to obfuscate their WordPress site. You would have a choice to either not use WordPress, learn how to harden WordPress, or simply use it as normal and hope that the inevitable hacking attempts are not successful.
That does not mean that using some other CMS platform than WordPress will guarantee you safety, because it won’t. But it will result in some hackers moving on from your site to find easier targets. It depends on whether they were specifically targeting your site, or if they were just trawling to find a vulnerable site. Unless you’re a high profile target, it’s unlikely that somebody is out to get you specifically.
The main drawbacks to WordPress from a security viewpoint are it’s widespread popularity combined with difficulty to modify the system, resulting in making a system that is much easier to hack than many others. On the other hand, it’s widespread popularity also means there is a large community of users from which to get security advice about that specific system.
Other popular systems such as Drupal and Joomla are also affected by the popularity problem, but they may be a bit more versatile in terms of how easy it is to mess around with their internal structure.
At the pinnacle of secure CMS options are systems like MODX, which gives the developer much more control over it’s internals right from the start. The drawback is that because these systems are less popular, if you have difficulty understanding the documentation, there is much smaller community that you can turn to for advice compared with the larger systems.
2. Use folder level security and move things out of default locations
Sometimes all you need to do to make a site more secure is to change the names of your folders. Your “images” folder, for example, could become “x3sgge” and it would function just as well, only it would be more difficult for somebody to find where your images are stored than if you conveniently named the folder “images”. Again it is security through obscurity, so you can’t rely entirely on this approach to protect anything, but it doesn’t hurt to add extra strings to your bow.
Folder level security is simple to implement. For a start, you should always have an index.php (or equivalent) in every directory of your site to reduce unauthorized folder browsing. In addition to this, you can use htaccess to restrict access to a folder. Users of cPanel can simply find the “Directory Privacy” link in their cPanel menu and then simply find the folder you want to protect and add a password to it.
3. Guard against SQL injections
These are one of the most commonly exploited website vulnerabilities, despite the fact that they’re one of the easiest to guard against. The reason why these exploits are often successful is that site developers often don’t know the simple techniques that would prevent them, and perhaps worse don’t know that the possibility exists.
A SQL or LDAP injection is simply a situation where some input being passed to an internal server function for processing contains some executable code that causes the server to respond. If you’re using PHP, the first thing you should be doing is researching commands like real_escape_string(), addslashes(), stripslashes() and htmlentities(). When you understand what these do and how to use them, you can filter most attempts to inject malicious SQL instructions into a data field.
It’s actually even better to use prepared statements with input, because this should automatically apply all the proper character escaping to prevent execution of added commands.
4. Use htmlentities() and str_replace() to reduce XSS attacks
Similar to the above. You just create a function to strip out any special characters and convert what are intended to be instructions into raw text. If any given string contains a HTML instruction, that instruction will be rendered harmless. This is not going to stop every XSS attempt, but it will stop the amateur XSS attempts.
5. Don’t use GET if POST will do
This is fairly obvious. When you use GET, it shows the data in the URL. When you use POST, it doesn’t show anything in the URL. Users can also see what is being evaluated and where. They may be able to make educated guesses about how your page processes the data and then use that information to exploit a vulnerability. When you do use GET, you should sanitize the variables before doing any processing of them.
For most GET strings, it only take a malicious user as much effort as appending 8 characters to the string to delete your entire website, but that won’t work if you’re properly sanitizing the string before doing anything with it. Obviously all of the preceding also applies to the ASP equivalents of these PHP commands.
6. Long passwords are better than complicated ones
Many systems are designed to suggest users must enter a password that is between 6 and 10 characters long and composed of many different character styles. Something like:
As you can guess, the above is pretty stupid, because most people can’t remember a string like that without writing it down, and it take a real effort to type it. That just means you get a lot of “I forgot my password” requests being sent, which is a waste of bandwidth.
Long passwords are better than gibberish passwords. For a start, they are much easier to remember, and they are harder to crack. Here’s an example:
It’s Friday night, and I’m alright!
can be converted to:
Now you can see what we have there is a phrase that is very easy to remember (it even rhymes, which is a useful way to make a phrase mnemonic). Furthermore it has a mix of upper and lowercase letters without that being forced. It contains punctuation symbols (two apostrophes, one comma, and one exclamation mark). And because there are no spaces, it’s not vulnerable to dictionary attacks. Even better, it’s 29 characters in length, and would take approximately nine duodecillion years to crack using brute force. In other words, the Sun will have already burned it’s last before that password could be cracked.
Long easy-to-remember passwords are far better than short difficult-to-remember passwords. You can also usually type them a lot faster, which means less time for shoulder-surfers to watch your key strokes.
Feature image curtsey of Matt Stevens