Businesses are increasingly moving online and we are already at a point in time where established physical stores and offices are shutting down to give way to online businesses. And on the other hand, due to the ease of setting up a website with one-click solutions, small businesses and individuals are using the power of the internet to maximise this reach. But this ease comes at the cost of website security, which is often overlooked or left to the vendor.
We are not saying that the vendors cannot provide security, but there is a catch. Take popular website CMS platform WordPress. Every hacker worth his money knows the default settings, usernames, login URLs, directory structures and more about WordPress. So leaving security entirely to the CMS or website vendor is not exactly brilliant. There are quite a few things you need to take care of to ensure that months of hard work from your side to set up the website does not go in vain.
From the early days of war and espionage until today, the importance of hiding your presence and details has always been a crucial tactic. Just think about it – how does one take something down when they don’t know what it is in the first place? The same effectiveness is completely applicable when it comes to the details of the content management system at the backend of your website.
As mentioned earlier, the default details about most popular CMS options are very well known to hackers, and without additional protection, they are quite easy to hack into using standard well known methods.
By just retaining the default folder structure, you would be handing over the access to your login URL on a plate. Nowadays most popular CMS providers allow renaming the default folder structure, including the administrator folders. And the best thing to do with that freedom is to go crazy and name them something that only you (and the other people with the authority) can guess.
For the very same reason, also change the default username. This is not what is going to stop all the hackers out there, but it might be just enough to discourage the impatient ones.
Most of our digital devices are now secured with some kind of digital protection – mainly antiviruses and firewalls – like our PC, Laptop, Smartphone etc. because we are more aware of the possibility of an attack on those devices. What we often overlook is the fact that our website is also stored on a physical server somewhere, be it a dedicated server that you have set up, or the standard server provided by your CMS vendor. In both cases, setting up a firewall is not only good, it is essential.
A web application firewall (WAF) is a server plugin or a physical device that sits in between all incoming traffic and your server. Its most basic job is to monitor all the traffic that tries to reach your server.
There is a certain set of rules that each WAF follows to allow or block traffic at the checkpoint. It is especially good with HTTP traffic and can detect XSS (Cross-site scripting) and SQL injection attacks quite well and can also be configured to deal with additional, more sophisticated types of attacks. As we said earlier, this can be deployed at both the physical as well as online level. There are quite a few vendors with competitive offerings, and we suggest you check Amazon’s AWS offering.
A typical WAF layout
This might feel insignificant until you understand the true possibilities. If your website allows files to be uploaded, then there is most probably a way to use that process to gain control of your backend. For example, if your website requires the user to upload an image (for profile pictures, document verification etc) and renames the file using the user ID, then the user can check the URLs of a few consecutive image uploads to figure out the directory address and naming pattern that the upload follows.
Then, instead of uploading an image, the same user can upload a shell file (think of it like a backdoor access to servers; somewhat like a cPanel within a PHP file). Now, when the user hits that URL, instead of getting the image he would get a control panel that would let him take multiple actions that could create a lot of chaos at the very least.
A simple way to make sure this does not happen is to enforce a check for filetypes being uploaded. To reduce the overhead, the check should ALLOW only certain file types and block everything else. Also, this block should not happen on the user end, as then it can be easily detected and worked around by looking at the source of any page. On the other hand, in no situation should the file be brought to the back end.
If the two terms above seem alien to you, just look at their abbreviations – TLS and SSL, the two protocols used for establishing secure and verified connections between websites, apps and web servers. And you clearly need to choose one over the other.
SSL is the precursor to TLS and although it is more widespread, it is definitely less secure. Recently, the POODLE vulnerability in SSL 3.0 has been exposed that allows access to sensitive information like passwords, cookies and more. This has caused a widespread shift to TLS and this one time, you should follow the crowd.
When setting up your website, make sure that you manually configure your webserver, especially you are going to deal with sensitive information like the ones mentioned above. And when you do, definitely go for TLS 1.2 even if it comes at an added premium.
The exchange involved in a TLS authentication
Some of the simplest website (and account) hacks have been done through request alterations, even directly in the URL. Quite recently, someone exploited a YouTube vulnerability that involved request alteration. Before we go further, let us make it clear that request here is the method used by HTTP to communicate with the server/backend (the intricate details about the workings of HTTP are best left for another article).
What the person did was quite simple. When he tried to delete his own video, he simply altered the POST request generated at that point by replacing his video’s ID with a target video ID. This caused the target video to be deleted and understandably created a lot of panic among youtubers. Something very similar could be easily executed on your website.
There are extensions and browser plugins that allow you to tamper with POST (and other) requests, like ‘Tamper Data’ for Firefox and ‘Postman’ for Chrome. Hence it is quite easy to exploit most websites using this method. To avoid this, simply associate a random value to the user’s session when they log in (brownie points for you if you make this value hard to guess). Store a copy of this value on the server side too. WIth every POST request, include this value for validation, and reject any request where the two don’t match. With that, you’ve just made your website a lot safer.
For any poorly coded website, SQL injection is the easiest way to play havoc with their work. For most such websites, login information is handled in an SQL query. A normal user would enter their credentials which would be consequently authenticated. But a hacker could enter a very specific string that would change the logic of your authentication code to grant him access to the the first account of the database, which is usually the administrator.
The example on a login screen
SELECT id FROM users WHERE username = $username AND password = $pwd;
If the hacker enters username as “1 OR 1=1; –” and any password, the statement is executed as
SELECT id FROM users WHERE username = 1 OR 1=1;– AND password = any password;
The double dashes indicate the beginning of a comment, hence the password statement is ignored, and the user gets logged into someone else’s account.
To avoid this, you should use “mysql_real_escape_string()” function (for PHP version < 5.0) or start using ‘mysqli’ (for PHP version >5.0). Both of them will filter out the unwanted characters and stop the hacker from exploiting the vulnerability.
Not all security involves building the strongest walls and the biggest turrets. A strategy for when the enemy does get through the gates is equally important. And when it comes to your website, backups are your best friends. On the rare chance that you actually lose your website, re-building it from day zero might be daunting enough to make you give up. To avoid that, go for regular backups. Use some reliable FTP tool like FileZilla to backup your entire website directory (folders, subfolders, files and everything in there) and put this backup somewhere safe online like Google Drive or Dropbox. And if you have any database associated with your website, backup that as well.
All of this will be on top of the regular server side backups that your CMS provider takes. When in doubt, backup again.
This article was first published in October 2016 issue of Digit magazine. To read Digit's articles first, subscribe here or download the Digit e-magazine app for Android and iOS. You could also buy Digit's previous issues here.