Many of these threats are predictable and easily avoidable, while others are unknown and can catch you off-guard. To minimize the possibility of this latter case, we offer a list of essential tips to keep web application servers as secure as possible. Before starting with the tip list, you need to understand that a web application server is not an island. The server is the central component in the web application farm that makes the hosting and operation of a web application possible. Therefore, to secure, you have to take into account all the components that surround it and secure the whole web application environment. A basic environment for hosting and running web applications includes the operating system (Linux, Windows), the webserver software (Apache, Nginx), a database server. If any of these components are broken into, attackers could gain access and perform all the malicious actions they want. A first and basic tip to secure an environment such as the one described above is to read the security guidelines and best practices list for each one of the components. That being said, let’s review a number of common-sense security guidelines that apply to almost every web application environment.
The firewall demystified
You may be tempted to quickly check this item, thinking, “lucky me, I already have a firewall protecting my network.” But you better hold your horses. Your firewall may be taking care of your network’s borders, keeping the bad guys out and the good guys in, but for sure it is leaving a door wide open for attackers to break in your web application server. How? Simple: your network firewall must at least allow incoming traffic on ports 80 and 443 (that is HTTP and HTTPS), and doesn’t know who or what is passing through those ports. What you need to protect your application is a web application firewall (WAF) that specifically analyzes web traffic and blocks any attempt to exploit vulnerabilities such as cross-site scripting or code injection. A WAF operates like a typical antivirus and antimalware: it looks for known patterns in the data stream and blocks it when it detects a malicious request. To be effective, the WAF needs to have its database constantly updated with new threat patterns, in order to be able to block them. The problem with pattern-based attack prevention is that your web application can be one of the first targets of a new threat that your WAF is not yet aware of. For these reasons, your web application needs additional protection layers besides the network firewall.
Scan for web-specific vulnerabilities
Again, don’t think your web application server is vulnerability-free just because your network security scanner says so. Network scanners cannot detect Application-specific vulnerabilities. To detect and eliminate these vulnerabilities, you have to put the applications under a series of tests and audits, such as penetration tests, black box scanning, and source code auditing. None of these methods is bulletproof, though. Ideally, you should perform as many of them as possible to eliminate all vulnerabilities. For example, security scanners, like Invicti, ensure that no exploitable code gets to the production environment. But there could be logical vulnerabilities that can only be detected by manual code auditing. Manual auditing, besides costing a lot, is a human and, therefore error-prone method. A good idea to do this kind of auditing without wasting a lot of money is embedding it in the development process, mostly by educating your developers.
Educate your developers
Developers tend to think their applications run in ideal worlds, where resources are unlimited, users don’t make mistakes, and there are no people with ruthless intentions. Unfortunately, at some point, they need to face real-world issues, especially those regarding information security. When developing web applications, coders must know and implement security mechanisms to ensure it is free from vulnerabilities. Those security mechanisms should be part of the best practices guide that the development team must comply with. Software quality auditing is used to ensure compliance with best practices. Best practices and auditing are the only ways to detect logical vulnerabilities, such as (for example) passing non-encrypted and visible parameters inside a URL, which an attacker could easily change to do what he or she wants.
Turn off unnecessary functionality
Assuming the web applications are as error-free as possible and the web farm is secured, let’s see what can be done on the server itself to protect it from attacks. A basic, common sense tip is to reduce the number of potentially vulnerable entry points. If attackers can exploit any of the components of the web server, the whole web server could be in danger. Make a list of all the open ports and running services or daemons on your server and close, disable or switch off the unnecessary ones. The server shouldn’t be used for any purpose other than running your web applications, so consider moving all additional functionality to other servers in your network.
Use separate environments for development, testing, and production
Developers and testers need privileges on the environments they work on that they should not have on the live application server. Even if you blindly trust them, their passwords could easily leak and fall into unwanted hands. Besides passwords and privileges, on the development and testing environments, there are usually backdoors, log files, source code, or other debugging information that could expose sensitive data, such as database usernames and passwords. The web application deployment process should be done by an administrator, who has to make sure that no sensitive information is exposed after installing the application on the live server. The same segregation concept needs to be applied to the application’s data. Testers and developers always prefer real data to work with, but it is not a good idea to grant them access to the production database, or even to a copy of it. Besides obvious privacy concerns, the database could contain configuration parameters that reveal internal server settings — such as endpoint addresses or pathnames, to name a couple.
Keep your server software updated
As obvious as it might seem, this is one of the most overlooked tasks. SUCURI found 59% of CMS applications were outdated, which is open to risk. New threats appear every day, and the only way to prevent them from jeopardizing your server is to always install the latest security patches. We mentioned before that network firewalls and network security scanners are not sufficient to prevent attacks on web applications. But they are necessary to protect your server from common cybersecurity threats, like DDoS attacks. So make sure you have such applications always updated, and that they are effectively protecting your business application.
Restrict access and privileges
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 where remote access is allowed, making sure that any attempt to log remotely from any other IP is blocked. Administrators occasionally give service accounts all possible privileges because they know that, by doing so, “everything will work.” But this is not a good practice since attackers can use vulnerabilities in the services to penetrate the server. If those services run with administrator privileges, they can seize the whole server. A good balance between security and practicality requires that each account — both login accounts and service accounts — has the privileges it needs to perform its job, and nothing else. For example, you can define different accounts for an administrator to do different task: one to make backups, other to clean log files, others to change the configuration of services, and so on. The same applies to database accounts: an application usually needs only the permissions to read and write data, and not to create or drop tables. Therefore, it should run with an account with privileges limited to do the tasks it needs to perform.
Keep an eye on server logs
Log files are there for a reason. Administrators should monitor them regularly to detect any suspicious behavior before it does any damage. By analyzing log files, you can uncover a lot of information to help you better protect the application. If an attack should happen, log files could show you when and how it started, helping to do better damage control. You must also have an automated procedure to delete old log files or to prune outdated information, to prevent them from consuming all available storage space in the server.
Bonus tip: keep yourself informed
There’s a lot of free and useful information on the Internet that you can use for the benefit of your web application. Don’t miss any new post on reputable security blogs (like this one) and stay informed about what’s happening in the security and web industry. Tutorials, courses, videos, and books are also sources of useful knowledge. Practice spending one or two hours a week just to stay informed of industry news — It will give you the peace of mind of knowing that you are doing the right thing to keep your applications secured.
