Much of the focus of web vulnerability testing is on the application itself, and deservedly so. Vulnerabilities such as SQL injection, cross-site scripting, and user session management flaws can be quite detrimental when exploited by those looking for ill-gotten gains. One thing to keep in mind with web security, however, is that you must look at it holistically. Application-specific vulnerabilities are one thing, but they don’t paint the entire picture. Looking at the actual web servers themselves is critical.

Reflecting on my web vulnerability and penetration testing projects in recent years, easily one-half and sometimes two-thirds of my reports contain vulnerabilities that are brought about by the web server itself. Web server vulnerabilities that I usually consider to be critical or high priority include:

• Missing patches and unsupported software running (think log4j and the myriad other web server vulnerabilities discovered all the time)
• Encryption misconfigurations such as weak encryption protocols and ciphers, expired certificates and, especially, no encryption at all, exposing login pages and other web forms that process sensitive information
• Directory and file exposures (sometimes these are benign files of no value but sometimes not)
• Open services such as FTP, telnet, and web proxies (imagine hosting a web server that’s facilitating other attacks)

There are other web server-centric vulnerabilities that I would consider to be more moderate, rated as best practices. These include vulnerabilities such as:

• Content Security Policy missing
• Cross-frame scripting protection missing
• HTTP Strict Transport Security misconfigured
• ASP.NET (or similar) debugging enabled

Still, vulnerabilities such as these can be cumulative and facilitate bigger exploits, so it’s good to find them and do something about them in the long-term.

Outside of scanning and testing for these web server vulnerabilities, the next step is determining which of these issues matter. You must factor in a lot of variables and every situation is different. The best way to do this is through detailed scanning and testing and subsequent analysis to determine what the specific risk is in the context of your environment. Obviously, you will want to focus on the critical and high priority items that have the greatest impact to the business. I often see moderate web server-related vulnerabilities falling on deaf ears and never being addressed. The smartest approach is to look at everything and figure out the best place to spend your time, money, and effort. Ultimately, only you will know the answer to this.

The important thing is that you’re doing something to look at every aspect of your web environment – not just the application. The web server needs attention too.