8 Essential Tips for Securing Web Applications Servers

 In most cases, web application servers must be open to the public, which means that they are exposed to all types of threats.

Many of these threats are predictable and easily avoidable, while others are unknown and they can meet unprepared. In order to minimize the likelihood of this case, we offer a list of important tips to keep web application servers as safe as possible.

Before you start with the tip list, you have to understand that a web application server is not an island. The server is the central component in the web application farm, which enables the hosting and operation of a web application. Therefore, you have to take into account all components that you surround and secure the entire environment of the web application.

The operating system (Linux, Windows), the web server software (Apache, Nginx), and a database server include a fundamental environment for hosting and executing web applications. If it is broken into one of these components, attackers could gain access and perform all malicious actions they want.

A first and basic tip to secure an environment like the above is to read the security guidelines and the best practice list for each of the components. However, we look at some reasonable security guidelines that apply to almost all web application environments.

The firewall demystified

You could be tried to check this point quickly and think: "Fortunately, I already have a firewall that protects my network." But you better keep your horses.

Your firewall may take care of the boundaries of your network and keep the bad outside and the good inside, but it will certainly leave attackers wide open to penetrate her web application server.

As?

Quite simply: Your network firewall must allow at least incoming data traffic on ports 80 and 443 (ie http and HTTPS) and do not know who or what these ports happen to.

What you need to protect your application is a web application firewall (WAF) that specifically analyzes the web traffic and blocks every attempt to use weaknesses such as cross-site scripting or code injection. A WAF works like a typical antivirus and antimalware: it searches for known patterns in the data stream and blocks it when it recognizes a malicious request.

In order to be effective, the WAF database must be constantly updated with new threat patterns in order to be able to block it. The problem with sample-based attack defense is that your web application can be one of the first goals of a new threat that your WAF is not yet known.

For these reasons, your web application needs additional protective layers in addition to the network firewall.

Search for web-specific weaknesses

Also, do not think that your web application server is free of weaknesses just because your network security scanner says this.

Network scanners cannot detect any application-specific weaknesses. In order to recognize and eliminate these vulnerabilities, you must subject the applications to a series of tests and audits, such as B. penetration tests, BlackBox scans, and source code auditing. However, none of these methods is bulletproof. Ideally, you should perform as many of them as possible to eliminate all weak points.

For example, safety scanners, such as Invicti, make sure that no exploitation of code can get to the production environment. But there could be logical weaknesses that can only be recognized by manual code auditing. Manual auditing is not only very cost-intensive but also a human and therefore error-prone method. A good idea to carry out this type of auditing without wasting a lot of money is to embed it into the development process, mainly by training its developers.

Fit your developers

Developers tend to believe that their applications run in ideal worlds in which resources are unlimited, users do not make mistakes and there are no ruthless intentions. Unfortunately, they have to face real problems at some point, especially those in relation to information security.

When developing web applications, programmers must know and implement security mechanisms to ensure that they are free of weaknesses. These security mechanisms should be part of the Best Practices guidelines that the development team must comply with.

The software quality test is used to ensure compliance with best practices. Best practices and auditing are the only ways to recognize logical weaknesses, such as B. the handing over unencrypted and visible parameters within a URL that an attacker could easily change to do what he or she wants.

Disable unnecessary functions

Assuming that the web applications are as error-free as possible and the web farm is secured, we look at what can be done on the server to protect it from attacks.

A basic, sensible tip is to reduce the number of potentially endangered entry points. If attackers can take advantage of one of the components of the web server, the entire web server could be in danger.

Create a list of all open ports and ongoing services or daemons on your server and close, deactivate or switch off the unnecessary. The server should not be used for any other purpose than to execute your web applications, so consider shifting all additional functions to other servers in your network.

Use separate environments for development, tests, and production

Developers and testers need authorizations for the environments in which they work that they should not have on the live application server. Even if they trust them blindly, their passwords could easily seep through and get into unwanted hands.

In addition to adhesive and authorizations, there are usually back doors, log files, source code, or other debugging information in the development and test environments that could reveal sensitive data such as database user names and passwords. The provisioning process of the web application should be carried out by an administrator that must ensure that no confidential information is disclosed after installing the application on the live server.

The same separation concept must be applied to the application data. Testers and developers always prefer to work with real data, but it is not a good idea to give you access to the production database or even a copy of it. In addition to obvious data protection concerns, the configuration parameter database that reveals internal server associations - such as endpoint addresses or path names, could just be mentioned.

Keep your server software up to date

As obviously it may seem, this is one of the most frequently overlooked tasks. Sucuri found that 59 % of the CMS applications were out of date, which is a risk.

New threats appear every day, and the only way to prevent them from jeopardizing their server is to always install the latest security patches.

We have already mentioned that network firewalls and network security scanners are not sufficient to prevent attacks on web applications. However, they are necessary to protect your server from common cyber security threats such as DDOS attacks. So make sure that you always have such applications up to date and that you effectively protect your business application.

Limit access and permissions

A basic security measure is to keep remote access traffic - such as RDP and SSH - encrypted and tunneled. It is also a good idea to keep a reduced list of IP addresses from which remote access is allowed and ensure that any attempt to log in from another IP is blocked.

Administrators occasionally give service accounts all sorts of privileges because they know that "everything works". However, this is not a good procedure, since attackers can take advantage of weaknesses in the service to penetrate the server. If these services are carried out with administrator rights, you can confiscate the entire server.

A balanced relationship between security and practicality requires that each account - both registration accounts and service accounts - has the authorizations that it requires to carry out its task, and nothing else.

For example, you can define different accounts for an administrator to perform various tasks: one to create a fuse, another to clean up protocol files, others to change the configuration of services, and so on. The same applies to database accounts: An application usually only requires the authorizations for reading and writing data, but not for creating or deleting tables. Therefore, it should be carried out with an account, the authorizations of which are limited to the execution of the tasks that it has to carry out.

Keep an eye on the server protocols

There are protocol files for a certain reason.

Administrators should monitor regularly to recognize suspicious behavior before causing damage. By analyzing protocol files, you can uncover a lot of information that helps you to better protect the application. If an attack should take place, protocol files can show you when and how it started and thus contribute to better damage limitation.

You must also have an automated procedure to delete old protocol files or to clean up outdated information to prevent you from consuming the entire available storage space on the server.

Bonus tip: stay up to date

On the Internet, you will find many free and useful information that you can use for your web application. Do not miss a new contribution in reputable safety blogs (like this) and stay up to date on what happens in the security and web industry.

Tutorials, courses, videos, and books are also sources of useful knowledge. Practice it to spend an hour or two a week to stay up to date through industry loys - this gives you the certainty that you do the right thing to protect your applications.