How to secure your website against attacks? We can argue, security breach is the fastest growing threat your business is likely to fall victim of at this time and age. And despite all the attention being directed towards high-profile security breaches, examples of JP Morgan Chase and Target, 9 out 10 security breaches that happened in the past involved small businesses.
This begs the question – why would cyber criminals be targeting small businesses in the first place?
Simple – starts with small businesses playing ignorant on this whole cyber security thing. And that’s because it’s NEVER occurred to them that they can actually be attacked.
So they go on with their businesses without installing any security measure in place or investing in resources that could help them thwart cyberattacks just in case they’re targeted.
It’s been said, an effective approach to avert web security threats is to be both defensive and proactive. In other words, securing your site from a possible attack is an ongoing process that requires you to be always on the watch. You don’t want to be caught off-guard. And should an attack happen, you must always be on the ready to defend yourself.
Having said that, this post aims to instil in you a website security mind set.
Nothing complicated – just a simple guide touching on some of the security pitfalls web owners make all the time, and the possible ways to mitigate them and keep your web app and server safe.
But before we get to the meaty part of this post, here’s a little run-through of the two most crucial aspects of cyber security – and that’s Authentication and Authorisation.
To develop an in-depth understanding on the details surrounding web security, it’s important that you be able to tell the difference between authentication and authorization.
There’s a common confusion surrounding the two terms, and more so since both of them use the same abbreviation, auth.
So just to clarify, here’s the distinction between the two terms. Read them more carefully, and make sure that you’ve completely understood them before you can proceed and read the rest of this article:
How to Secure Your Website from Attacks
By authentication, what’s meant is that the user in question has provided all the needed security credential (that includes, username, password, security answer or a fingerprint scan) to be granted access to a particular web resource.
This one confirms that the user has been granted permission to access a particular resource so they can perform a given action.
As you can see, the two terms bear an almost similar meaning. But if we were to draw a very clear distinctive line between the two, we’d say that authentication is mostly about identifying an entity, while authorization is identifying what the entity is allowed to do. In other words, you may be authenticated to access a given resource, but in order to perform a given action, then that demands that you be authorized by the underlying authority to do it.
That being said, here’s a list of common security pitfalls and the corresponding recommendations on how to circumvent them:
Injection flaw occurs when unfiltered data enters your web server, browser, or LDAP server. From the name, the attacker will simply be injecting commands to the above entities, thus gaining access to your web server to steal data or hijack your server for ill-purposes.
To stay safe, it’s recommended that you learn how to filter any kind of data that you receive from untrusted sources. Simple logic demands that you avoid accepting anything from a blacklisted site, and that’s mostly because most of the attacks blacklisted sites wedge cannot be detected by a simple antivirus software.
Come up with effective and tested measures to carefully filter your input – whether or NOT you trust their sources.
Be reminded that input filtering is one of the toughest tasks you’ll be required to do in your web management line of work. It’s for this reason that you might want to cash in on the filtering function installed by the framework you’re using.
Frameworks are recommended because their filtering functions tend to do a thorough job scrutinizing inputs. So before you rule them out completely , you might want to consider the effect of such a decision to your security protocol.
Broken authentication encapsulates all the problems that occurs during the authentication process. Keep in mind that the root cause of the problems don’t necessarily have to be the same.
Here are the possible root cause of broken authentication:
. – Your sites might contain a session ID and leak it to someone else via the referrer header.
. – Unencrypted data either in transit or storage.
. – Predictable session Ids, thus making it pretty simple for an attacker to steal their way in.
. – Simple session fixation.
. – The possibility of session hijacking, mostly because the timeouts are NOT implemented right or you haven’t installed an SSL certificate on your site.
Again, to avoid this common security pitfall, then you might want to consider using a framework. Make sure the framework is implemented properly. But just in case you’re planning to run you own code, then you’re required to understand the above pitfalls and respond to it by at least installing an SSL certificate and encrypting your data where possible.
Cross Site Scripting (XSS)
Usually, the codes are something simple like a crafted link a user might be tempted to click through or something really sinister like sending cookies back to the attacker.
To prevent the problem, it’s recommended that you don’t send HTML tags back to the client. By doing this, you’ll be protecting your site from getting injected with malicious JavaScipt or HTML tags.
You can do this by converting all your HTML entities. All you’re required to do is use regular expressions to strip the tags away. Keep in mind that there are browsers that can still decode broken HTML tags and read them just fine. Meaning, you’re better off converting the codes to their escaped characters instead.
Insecure Direct Object Reference
You simply trust a user input, which ends up putting your site at a security risk. By object reference we mean, that you have an internal object in the line of database key or filed that’s exposed to a user you trust.
What happens is that the attacks provides this reference, and in the event that authorization is either broken or NOT enforced, they can gain access to a resource they aren’t allowed to or end up taking an action they’re strictly prohibited from.
Take for instance a php code with the download.php module. This code can read files and at the same time allow users to download it using a CGI parameter that actually specifies the name of the file.
Now out of laziness, a simple mistake, or pure ignorance, the developer omitted authorization, the attacker is in a position to take advantage of this, and download any file the user running the PHP code has direct access to.
Another common pitfall would be the password reset function that tends to rely on user input to determine the corresponding password to rest. What an attacker could do is click through the valid URL, and modify the username to say, admin.
Both of these scenarios are so common in the world of cyber security and some of the reported cases of hacking. You might be an experienced coder, but there are finer things that we take for granted that exposes our sites to serious cyber-attacks.
To say safe, it’s important that you start by performing user authorization correctly and in a more consistent manner, with your choices white-listed. Another approach would be to try and store all your data internally instead of relying on passing it from your clients through CGI parameters.
Lastly, you might want to take the obvious approach of working with a frameworks, considering most of them have at one point dealt with such a pitfall and ironed it out.
You’d be surprised by the sheer number of web servers and applications that haven’t been properly configured. As a matter of fact, there’s a fair chance the number of misconfigured web servers and application surpasses those that are properly configured by far.
And the reason is that there are so many ways you could mess up your site’s configuration, knowingly or unknowingly.
Here’re few examples:
. – By running your web application while the debug is enabled in production.
. – When the directory listing is enabled on your web server. This could leak out valuable information, thus putting your site at risk of getting hacked.
. – By simply running an outdated software particularly PhpMyAdmin or WordPress plugin.
. – Running unnecessary services on your machine.
. – Forgetting to change the default key and password.
. – When you reveal error handling data or information to a potential attacker, for instance stack traces.
To protect your web server or application from such a problem, it’s important that you start by establishing a great build and deploy process to run serious tests on your application upon deploying.
For security misconfiguration, you might want to post-commit hooks, so as to prevent your codes from heading out with your default keys and passwords or with any of your development stuff.
Using Vulnerable Components
This one is better classified as a maintenance issue. Before you even think of adding some new code to your web app or server, you might want to do some research, like carrying out some serious auditing.
Happens a whole lot when you picked some random code online from, say GitHub and immediately ran it without profiling. The code might be fine, but that doesn’t necessarily imply that’s NOT at risk of security vulnerability.
There have been incidences when attackers managed to hijack a site simply because the owner had a third party software lurking somewhere on their site for years. This could be out of pure ignorance or laziness.
Such stories are common all over the internet more so with WordPress plugins. If you have something on site that you’re NOT using, as a security measure, you’re better off deleting it than leaving it unpatched on your web server.
Keep in mind that software development doesn’t always end with you deploying it. You might want to check out the documentation, test it out, and devise a plan on how to both maintain and keep it updated. This is particularly important for open source software, with 3rd party codes and resources.
To stay safe, you can start by being extra vigilant on how you defend your site from security breaches. It’s also important that you try to avoid copy-pasting codes, and if you really have to, test them out first before you can go ahead and run them on your site.
Try to find out if the code is broken or is in some serious need of repair. Upon suspecting anything, take necessary precautions to fix it or avoid it altogether.
Lastly, if you’re using any software, be sure to keep it updated at all times. Make sure you’re working with the latest version of the software at any given point, and that the company behind it can actually be trusted.
Another form of an input filtering related issue. Often, this happens when the site being targeted has a redirect.php module, and which interprets the URL as GET parameter. By manipulating the parameter, you’ll be creating another URL that redirects it to a malware site such as malwareinstall.com.
So an underlying user sees a link they trust and click on it, only to be redirected to a malicious or malware drop site.
This is likely to happen when you stuff unsanitized user-defined input to an http header, which is pretty bad and risky to both your site and its visitors.
To stay safe, you can start by avoiding redirects at all costs. And as you’re soon to find out, they’re rarely that necessary.
Secondly, you might want to come up with a static list of all the valid locations you can redirect to.
And lastly, learn to whitelist user-defined parameters. The process can be a little tricky and time consuming, but you’re better off working on it than losing your site to attackers.
It’s a Wrap
As far as web security goes, you no longer have the luxury to get comfortable. Cyber-attackers are always on the hunt for the slightest loophole to launch their attacks, and bring your site down or use it for their own malicious interest. As someone concerned about your web security, and that of your clients’ as well, it’s the paranoia of something bad happening that works to keep you on toes.
Securing your site from cyber criminals and attackers is a tough task on its own, requiring serious commitment and a higher level of technical expertise. There’ll come a time when you’d want to outsource the service from an experienced cyber security agency in Singapore.
Contact us today for custom website design services in Singapore. Our team will also give you insider tips on how to secure your website.