Bad guys are everywhere – and the cyberspace isn’t safe for anyone. Even the most of the experienced web security experts and CIOs get attacked, so it’s safe to say that no one is completely safe in the hallowed walls of the internet.
The trick is to stay vigilant all the time guarding your web assets and reputation against the bad guys. And while at it, seal all the security loopholes that are catnip to them launching an attack. No one knows when they’re going to strike, but a simple security slip-up on your part could end up attracting scores of them.
And the worst mistake of all is to wait until there’s a security breach to start prioritising on your web security. As you’re soon to find out (or assuming you haven’t already), the cyberspace is rife with all kinds of security issues that your website is exposed to; and there’s only one effective approach around this – and that’s, to at all times remain proactive and defensive.
In other words, you’re expected to conduct your online operations on the qui vive, with both your eyes open. And while at it, you want to make sure that you’re checking your website for any of these vulnerabilities so you can iron them right on time before they morph into something you might never be able to recover from.
Let’s jump straight in:
With XSS, hackers can get full access to your web API, and a common occurrence is when a hacker stumbles across a vulnerable input field that they can inject a snipper that will be directing the page to another page.
The hacker then takes full control of what happens to the user once they open your link. For instance, they can direct them to any webpage that pleases them.
And since the attacker gets direct access to your local storage, cookies, and session storage, this vulnerability allows them to do some major damages to your web content to the extent of sullying all of your online efforts.
This Vulnerability has one of the simplest solutions: never make the mistake of returning HTML tags to any of your clients. By avoiding this, what you’ll be simply doing is defending your codes against a malicious HTML injection.
The attacker may choose to inject plain HTML lines of codes or content such as an invisible flash player or images. Their impact might NOT be that scary, but they’re surely annoying.
A simple workaround would be to try converting all your HTML entities when they return. For instance, you could the tag by making it return as <script>.
Another trick would be to make the tags return as regular expressions by stripping away the guillemet symbol. But you have to be extra careful while taking this approach as there’s a risk of other browsers interpreting the results as some broken HTML codes.
SQL injections are mostly targeted towards websites and mobile applications that are powered by the SQL database. For what’s worth, SQL software is what stores and organizes all of your business data, including payment info and customer records.
But since SQL databases can only be accessed after you’ve been subjected to a thorough authentication, the injection has to run the app level.
In other words, the attackers have to figure out how they’ll be retrieving your entire database without undergoing the authentication process. It turns out, it’s much easier than we thought and that 64% of all the web attacks that have been happening in the recent years are as a result of an SQL injection.
Your site is only exposed to an SQL injection when you have not made any effort to filter out untrusted input. So the unfiltered data sips into your SQL server, and to the browser, to the LDAP server, and to anywhere else to wreak havoc.
For an attacker, all they have to do is inject a series of commands into these entities, and the next thing you know, your web presence is in deep shambles that could lead into some serious data loss.
A good example is the eval function, which when misconfigured can leave you exposed to a series of attacks.
To say safe, first, you’re warned against the use of the eval function. While developers use it to
Increase speed and all that, there’s the security issue involved where they leave your server open
Same goes when you decide to use a concatenation of string of the unsanctioned dynamic input; let’s just say that the consequences that follow might not be that pleasant to you.
As the name suggests, remote code execution allows attackers to initiate code execution remotely, via the internet.
Usually, the attacks are launched via email. Either you or one of your employees receives an email from an attacker and rushes to open it without paying much attention to what is contained on the inside.
Immediately you click through the email, a malware software is deployed that will immediately begin taking advantage of your web browser or operating system.
That way, it can access virtually anything on your computer. Or the attacker could use it to access sensitive data from you, lock your computer, or to even demand a ransom.
Ransom attacks have been growing at an alarming rate over the past few years, with different studies suggesting that they might have caused damage amounting to more than $5 billion last year alone.
With this vulnerability, attackers can read your files and directories from outside the root directory.
While launching the file inclusion, intruders are granted direct access to any data that has been stored above the root directory. This leaves some of the web directories accessible to hackers and not users.
This vulnerability can have a great impact on your business where you’re more concerned about protecting your resources. You want to start by making sure that you’re protecting all the sensitive data, at all times.
No exceptions – whether on transit or at rest, you have to make sure that you’ve encrypted all the sensitive data.
Users’ passwords and their credit card information should never be made to travel or stored unencrypted. For passwords, you’d want to make sure that they’re also hashed.
For cryptos, simple logic demands that you use a strong hashing algorithm, not a weak one. A good example of such a hashing algorithm is the RSA (2048 bits and up) and AES (256 bits and up).
A good chunk of the web applications and servers that you’re likely to come across online have been poorly configured. As a matter of fact, the number of those that have been misconfigured trumps those that have been properly configured by far.
And the reason is rather simple: there are a dozen ways that you could mess up a configuration, and people keep making them all the time without knowing they’re putting their websites at risk.
Here are a few examples of how you’re likely to mess up your site by misconfiguring it:
- Running a web app while you’ve enabled the debug option.
- Enabling directory listing on a web server, which has the effect of leaking valuable information.
- Running outdated CMS software, plugin, PhpMyAdmin, or any other software
- Running unnecessary services on the server machine.
- Forgetting to change default passwords and keys. This is a common case to those running their websites on WordPress.
- Revealing some crucial error handling formation to a third party with malice.
There’s only one way to prevent this: consider setting up an automated build and deploy process that will be running a series of tests every time you deploy any web program.
Another trick for countering the security risks associated with misconfiguration would be to post hooks that will be preventing your codes from leaking out built-in development stuff and passwords.
Missing Function Level Control
This vulnerability occurs whenever there’s an authorisation failure. So every time a function is called on a server, no proper authorisation is followed.
What happens most of the time is that developers have to rely on the idea that the server generated the UI. So they’ll be contented with the idea that the client will not access any functionality that’s not generated by the server. How wrong of them.
Attackers have a way of forging requests to hidden functionalities and there’s no way you’re going to stop them by just making these functionalities inaccessible.
Imagine a situation where your site features an admin panel, and there’s a button on that panel that will only be appearing in the User Interface if the person on the other end is an admin.
While it’s easy for developers to assume no attacker will be discovering this button, you’d be surprised to find out that they consider it a no brainer.
To say safe, it’s crucial to make sure authorisation is always done from the server side, all the time. Make no exceptions, or else the consequences to follow will be something you’ll forever live to regret.
Insecure Data Object
This one happens when you place excessive trust in user input, not knowing you’re exposing your site to a security risk.
By direct object reference, what is meant is that there’s an internal object in the server, such as database key or file, that’s exposed to a user on the other end. The problem arises when an attacker provides this reference, and if authorisation is either broken or NOT enforced, the attacker can be tempted to manipulate your system by doing things that they’re NOT allowed to do.
Here’s a classic example: assuming you’re running code with the download.php module. This module is supposed to read and allow the user to download the files therein, so long as they have the CGI parameters specifying the name of the file.
But if the developer made a mistake of omitting authorisation from that code, whether accidentally or because they were too lazy to do it, the attacker can take advantage of the situation and use the opportunity to download your entire file system that any user running PHP can access. Everything, starting from your code to the files lying idly on the server – the attacker has full power to download the files and bring you to your knees.
To prevent the vulnerability, you have to learn how to perform user authorisation more consistently and properly, as you whitelist some of the choices you have. Also, try as much as you can to store all your data internally instead of relying on CGI parameters to pass it from your clients.
Another alternative would be to consider using session variables as they’re the most suited for this function.
Using components that are Stacked with Unknown Vulnerabilities
This is more of a deployment or maintenance issue than it is a vulnerability. Happens when you’re incorporating a new code that you collected from GitHub or anywhere else; you want to make sure that you did some thorough research on the code to establish that it’s i) clean and ii) not vulnerable to attacks.
Or else, that code could be the cause of your site being held hostage or you losing ownership of the site to an outsider. That’s NOT to say that the programmers were dumb. What it means is that the third party software you are using has remained unpatched for several years.
This is a common problem to those with a tendency to use lots of plugins. So before you rush into downloading and installing any plugin, do thorough research to establish if it’s totally clean and NOT a website security risk in any way.
To stay safe, you might want to stop the habit of copy-pasting codes. And if you have to, take your time to go through the lines and inspect it to make sure it’s not broken or if it’s intentionally malicious. Failure to do this can be likened to unwittingly inviting security risks that can prove to be detrimental to the overall wellbeing of your web presence.
This post was meant to instil in you a healthy dose of paranoia. Come what may, you’re NOT supposed to get comfortable where your online security is concerned, NOT even for a second.
You can use this post to figure out how to protect your site from malicious attacks, but just in case you need professional help in tightening the security nuts of your website or your overall online presence, MediaOne marketing is your friend. Talk to us!