Security Hardening Essentials to Keep Your Site Safe

A significant part of the website development practice is always keeping in mind that security is not something you can buy off the shelf at the closest convenience store. When it comes to website security, there are lots of things you could do to lock down your website, therefore prevent hackers and vulnerabilities from affecting your business or personal data. Because after all, the last thing you want is to wake up one day and discover that your site is a total mess.

Every year since the end of 2003 has been recognized as National Cybersecurity Awareness Month. To help with raising awareness, we’ve decided to break up this month into four thematic weeks. Join us for a series of website security articles. Learn more about website security, emerging vulnerabilities, and web malware infections.

The topics of discussion for this blog post are the various types of cyberattacks, available types of security measures and protocols that one can apply for the benefit of their safety. It also features commonly overlooked best practices that many take for granted. These same practices are actually the core basis to achieving a relatively impenetrable online existence in this vastly growing network which we all address by the handler of the World Wide Web (WWW).

• 1. Most Common Web Security Vulnerabilities
• Cross-site scripting (XSS)
• Cross-Site Request Forgery (CSRF)
• SQL Injection
• Brute-force attack
• Distributed Denial-of-service attack (DDoS)
• 2. Challenges and Solutions
• Content Security Policy (CSP)
• Secure Sockets Layer (SSL)
• Browsing Path Disclosure
• 3. Routine Security

Most Common Web Security Vulnerabilities

Cross-site Scripting (XSS)

Cross-site scripting is one, if not the most commonly found vulnerabilities due to its lack of evasion during the development process of a given application or website. The simplest explanation of what cross-site scripting would be the inability of an online platform to detect the source of where the code is coming from, thus executing a malformed web page request from the attacker’s side on the server itself. An example of the damage that could be done through this attack includes results as:

• Read local files on the server through web form manipulation
• Gain remote access to the server
• Edit files on the server itself
• Retrieve user essential logs
• Escalate user privileges
• Kill processes
• Reboot Server
• Corrupt data

The list of possible outcomes goes on to a near infinity of options. Luckily, by using the most commonly found applications such as the massively spread WordPress, Joomla, Drupal, Magento, OpenCart and so on, ensures us that we receive regular updates from the developers of the applications and plugins that they use. By providing regular security patches to their development process the overall chances of experiencing one of these unpleasant events slim considerably.

Cross-Site Request Forgery (CSRF)

Very similar to XSS, this method of exploitation throws salt in the cauldron, spicing things up a notch by adding the victim’s interaction into the mix. For this attack to be established, for example, an attack will send to the victim malicious links in hopes of stealing cookie authentication sessions from the victim. Then, by analyzing the obtained information, a request to a given service which the victim uses and manage to log into an account without having to provide their login credentials can be forged. These emails are often sent from email addresses that look very similar to the original, with a copied body message of the original, mimicking it to add authenticity or even with a spoofed origin, copying and looking precisely like the original sender, but often caught by email services with proper spam filtering.

Avoiding this is entirely up to the end-user. Always check before clicking and read thoroughly through the email for things that may give out its origin such as, improper aligning, suspicious ending links and/or broken formatting. Often these may be mass sent phishing emails for services you may not even be registered for, but can still be dangerous if opened.

SQL Injection

Possibly the most often exploited, mass favorite and easiest to successfully perform, SQL injections can potentially be performed on any type of website or application which works with a supplied storage of data within a database storage system, such as MySQL, Microsoft SQL, MariaDB or any of the same syntax top contenders.

The attack has a variety of ways of being established, but will always result in a severe breach if done correctly. It consists of finding a vulnerability, often in search engines on the website or anything that directly displays content from the database, then changing certain parameters on a database and using SQL based syntax commands to SELECT, INSERT, DELETE content from the database itself to gain access to the given application.

This can be done for example, in WordPress, by changing the administrative account’s email, which by default is stored in the WordPress database “wp_users” table, to an email which the attacker has access. Then, via the application’s reset password function, he can fully gain access to the backend and download sensitive personally identifiable information (PII).

Like XSS, the solution here is to use more mass spread applications, with time-proven stability and often provided security patches. Because no application can be fully secured, what matters is the reaction time between the threat being caught and the deployment of its countermeasure.

Brute-force Attack

Considered to be one of the first cyber-attacks, this simple attack type consists of trying a variation of provided predefined list of usernames and passwords, checking their result to a given service credential fields for a successful login. While being a basic attack, with previously established attack parameters, it has proven to have a high success rate, due to people’s negligence and constant recycling of passwords.

Services are often shut down, go bankrupt, hacked or so on, often leaking their customer’s content in one way or another, thus many of the passwords you now use may already be somewhere out there on the Internet, so It is best to change our passwords often, completely changing them instead of adding more letters or symbols to the existing core password as often seen in statistics.

Luckily, on most modern applications this can be easily prevented by installing a plugin or two and/or applying IP restrictions, restricting more than a few tries per IP address, then blocking them for a given amount of time.

Distributed Denial-of-Service Attack (DDoS)

Whilst I would hardly consider this an “attack,” it is a commonly spread occurrence, due to its mass availability, easiness of usage, mass sub-methods of execution and so on.

Whether it be to gain an unfair advantage by stopping your opponent’s internet while playing online games or using it as a political tool to spread awareness in the hands of notorious groups such as the “anonymous” this attack always consists of the same.

The attacker sends out large waves of packets to a given IP, be it a website or personal network, flooding it and overloading it with traffic in the form of large size malformed packets. In the end, the network is forced to either slow down or fully shut down/restart.

The source can be hundreds to thousands, considered as a “botnet,” numerous personal computers which have been previously infected by the attacker. These botnets can be awakened at any time and be given remote commands to send traffic to the certain host at the same time till the above result is reached. Another starting point of attack would be configuring one powerful server, initially meant for hosting, and exploiting it to use its full network output (upload speed) stressing the target’s intake traffic.

While there is an abundance of sub-categories to this attack, from the above which is considered a “flood”, where the data is simply sent out in mass quantities to more advanced attack, exploiting kernel vulnerabilities in the hosting machine itself, forcing it to do commands such as shutdown/reboot, which it would be best to not disclose in full detail. Each of them can be either withstood by a more powerful server or better yet mitigated by applying the security patches given by the provider of the operating system.

Challenges and Solutions

Content Security Policy (CSP) – a Whole New Way of Securing Your Website

One of the rather new more advanced methods of security reinforcement that has surfaced in the last few years has gained extreme popularity due to its practicality, easy application, promising countermeasures and modern approach in fulfilling our application safety standards. Content Security Policy is a web platform mechanism designed to mitigate cross-site scripting (XSS) – the top security vulnerability in modern web applications.

It works by using pre-defining given parameters, which then highlight which services are valid to be fetched from the external repositories and by doing so, providing us with only the essentials that the web page itself requires in order to load properly, leaving out any other content that may be of unknown origin or malicious source.

CSP has a goal of restricting a site’s capability to execute a malicious client-side code. This will be done by disallowing inline scripts and allowing only trusted domains as a source of external scripts. Hence, even at the event when an attacker is capable of finding an XSS vulnerability, CSP makes sure to keep the application as safe as possible by preventing the exploitation of the bug – the attacker shouldn’t have the needed access to load up any malicious code without controlling a trusted host.

With this, you can control certain variables to be allowed or mitigated in case of attack, granting you more control over your distributed code and maintaining a safer infrastructure, for both your server’s environment and connecting visitors. With this, you will also gain the ability to:

• Map resources by whitelisting them for the initial end-user connection;
• Protect website visitors from potential code inject manipulation;
• Prevent multiple variations of given attacks types.

Speculated to soon gain even higher following, the development of CSP is supplied with regular improvements, adding more features and expanding its pool of defense against evermore threats. During WordCamp 2018, Miriam Schwab, founder, and CEO of WordPress firm Strattic gave a great ordeal of information on the topic, along with various other interesting statements on today’s most trending CMS, which you can read and hear about in full details here.

Use Secure Sockets Layer (SSL) for Secure Connections

One of the most underestimated methods for hardening your website’s security is to install an SSL certificate. “It will never happen to me.” – Is what many people assume I’ve misheard thousands of people assume, and then one day come to the conclusion that indeed they should have taken the time to add that extra-click. Whether it is on your local home network or your multi-website hosted business, generated traffic should be encrypted at all costs.

The difference is not just in your padlock being green or red, HTTPS or HTTP, if you will be warmly welcomed into the page, or prompted for permission to be let in accompanied by a warning sign based on the browser you are using. It’s there for a reason, and that reason is to make sure that the connection between you and the host from the other side is secure, and transmitted sensitive data is encapsulated into multiple packets, which are then decrypted and reassembled at their final destination, providing the message to the given system and allowing it to serve its intended functionality.

As you may have already concluded, if such basic precautions are not in place at the time of an attempted hacking, you may fall victim to the situation of having your information “sniffed” and leaked into the wrong hands, uncovering yourself as an easy target and later being marked to a follow-up series of different types of attacks.

Watch Your Step!

You must literally watch your step. Most websites that you visit, whether legitimate in intents or of unknown nature will receive and keep logistical files, log history other information to gain information on the page from which you came, in order to predict the next page you will visit.

How can this potentially be of harm to an end-user?

Let us imagine the scenario in which while you are managing your web pages, you stumble upon a link to an interesting article on cybersecurity and decide to click it. Depending on the previous page you come from, the website owner may now have the access token/session key from your “referring” link which can be used to obtain access to your cPanel and/or management panel.

What can I do in order to avoid this?

The most basic of security applies to the fullest here. Keep your passwords safe and your browser history clean. Check before you click, hover over a link to see the page it will bring you to and always keep in mind that the internet is a jungle that can be just as dangerous to adults, as it can be to children.

Clumsy vs. Cautious

Statistics undeniably confirm that the majority of non-technically induced breaches occur due to user error. We can all unanimously agree that nobody has the capability of keeping their passwords secure without extreme means of self-management. Whether it be due to using a simple password, the same password you thought of while back in high school, or the stranger-to-none, award-winningly famous password “123456”, your WordPress backend will nevertheless cower with the constant anxiety of someday being accessed by the wrong person.

However, things like:

• File copies with non-file-extension symbols (https://domain.tld/wp-config.php~)
  When accessed directly, this file, if existent will display its content in plain readable text, meaning that your application’s connection details, username/password/etc. will fall into the wrong hands. Near all applications will have such a configuration file, regardless of which folder it is located or the syntax of its content. If obtained, your application will be a step closer to finding its inevitable demise in the form of defacement.
• Publicly accessible backups with user-given names
  (https://domain.tld/backup.zip)
  (https://domain.tld/database.sql)
  (https://domain.tld/restore.tar.gz)

are WIDELY SPREAD and will lead up to a lot of frustrating moments and unwanted situations that could have been avoided with ease just by cleaning up all unnecessary development phase website installations, broken bulk of plugins, outdated backup files, and used scripts prior to them fulfilling their intended use. The content of your /home/USER/public_html/**** is meant for you and you alone, and it will be a real issue if unauthorized access to this folder can be achieved.

I can agree that it is important that we have at least a few of these many variations of security to better our odds of withstanding a dire situation. Nevertheless, in order to guarantee both our own as well as 3rd party customers day-to-day safety, we must first better ourselves in handling this type of info. We should do this, rather than relying only on the promised fortification of a firewall, because the highest castles are the ones that burn the quickest if their roots are poor.