Steps to improve an application environment and fix flaws

Application security is complex. From nuanced security flaws in modern JSON Web Token implementations to good old-fashioned input validation weaknesses that allow for SQL injection, there are a thousand things that can go wrong and that you must test for to ensure that your applications are resilient to attack.

However, there's one aspect of application security that's often discounted or overlooked, yet can have just as much of an impact on the security of your application environment: the servers running it all.

Many security gotchas can crop up on web servers and related systems, but these are the main issues that I have seen in my vulnerability and penetration testing work:

• Missing patches that facilitate exploits: This can lead to denial-of-service attacks or -- worse -- full remote access to the system. This is particularly problematic on Linux-based web platforms, as I often see OpenSSL, Apache and similar software that hasn't been patched in years.
• Encryption weaknesses: This includes SSL and older versions of TLS, as well as weak encryption ciphers that can be exploited if the attacker has enough time on his hands. Believe it or not, I still come across applications -- sometimes business-critical ones -- that are accessible over HTTP and do not require encrypted authentication.

Do the necessary testing and hardening of your servers beyond the application front end.

• Unhandled HTTP exceptions: These HTTP 500 errors can disclose system configuration information and ultimately facilitate SQL injection. Make sure that you have detailed error messages and debugging disabled at the server level so this information is not returned to the user.
• File permission configurations: This can expose web server directories and files that contain configuration information and can lead to further system enumeration and exploitation.
• FTP services enabled: This can expose login credentials, as this protocol transmits them in clear text. FTP can also be misconfigured, potentially allowing unauthorized access, either anonymous or otherwise. It can also be abused with password cracking tools, as intruder lockout is rarely enabled.
• Open proxies: These may not directly expose the application, but they do put the overall environment at risk of denial-of-service attacks.
• Lack of malware protection: This is a tricky one because it's understandable that people may not want to run antivirus software on their web servers. However, what happens when you have a vulnerable page or form that allows an attacker to upload malware to your server? Everything can be impacted at that point. Quite often, I see unprotected pages and forms that don't filter by file type, which is compounded by web servers that have no means to deal with malware that gets uploaded.

Given all of this, you should take a hard look at your application environment; not just layer 7, but everything -- all the moving parts, including your development, testing and staging systems. You should also evaluate the server vulnerabilities that can be accessed and exploited from inside the network. It's not just external attackers you need to be concerned with, after all. Someone with ill-intent inside your network can inflict as much, if not more, harm.

The last thing you need is a web server or OS-related flaw that brings down your business. Do the necessary testing and hardening of your servers beyond the application front end.

While you won't be able to find everything at first or all at once, creating an ongoing application security testing program that looks at all the right areas is essential. Think relentless incrementalism -- doing what you know needs to be done periodically and consistently over time. Time is going to pass anyway, so why not go ahead and lock down your server environment so that this variable is eliminated?