Security issues associated with Web applications are pretty cut and dried. In fact, if you focus solely on login mechanism and input validation flaws you can eliminate the majority of weaknesses in any given application. Add to that some tightening down of the application's logic and you'll have one of the more secure Web applications out there.
But what about the server your application is running on? Have you tested it using good vulnerability scanners to see how the Web server, OS and related software stand up to abuse? If you've only focused on the application layer and trusted the security of the server to someone else (i.e. your network admin or your hosting provider) you might be surprised to find out there's a shaky foundation underneath.
In my work performing Web application penetration tests and vulnerability assessments I see consistent issues at the server level that usually make up 25% or more of the overall findings. Many weaknesses I find are considered "medium" and "high" priority. Here are common weaknesses I find in Web servers that can lead to problems such as unauthorized file disclosures, denial of service, or worse, full remote access to the system using an exploit tool such as Metasploit:
- Outdated versions of Web server software (especially common with Apache).
What can happen? Denial of service, remote command prompt access, authentication bypass, and more.
- Outdated versions of security technologies such as OpenSSL and
Requires Free Membership to View
When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.
Hannah Smalltree, Editorial Director
- OpenSSH that have known exploits.
What can happen? Denial of service and remote command prompt access.
- Vulnerable Web server technologies such as PHP, WebDav, and ColdFusion.
What can happen? Denial of service, remote command prompt access, authentication bypass, directory enumeration, and local file access.
- Open ports providing access to services such as DNS, FTP, and Windows Terminal Services.
What can happen? System enumeration, password cracking, remote command prompt access, and other unauthorized remote access.
- Unnecessary HTTP methods enabled such as CONNECT, DELETE, and PUT.
What can happen? Web service enumeration, unauthorized HTTP proxying, file addition and deletion, and more.
- Open HTTP proxies.
What can happen? Unauthorized HTTP proxying and system overload leading to denial of service.
- Web server misconfigurations that divulge the system's internal IP address.
What can happen? System enumeration and mapping of the internal network for future exploitation.
- Weak directory permissions.
What can happen? Authentication bypass, directory enumeration, and local file access.
- Weak encryption configurations such as SSL version 2 and low encryption ciphers.
What can happen? Interception and subsequent cracking of the encrypted communications stream.
- Lack of protection against malware uploaded to the server via Web application forms. What can happen? Malware uploads and subsequent infections.
The first four items in the list can have the greatest impact on your Web systems and, interestingly, they're the ones I see the most in my work. Regardless, all of these server-level issues are often taken for granted but with enough time are sure to knock the legs out from underneath an otherwise secure Web application.
The key is to never assume that looking at layer 7 alone will be enough. A proven way to ensure you're looking at everything that counts in your Web environment is to use vulnerability scanners that perform server side checks. I've had good results using the QualysGuard vulnerability scanner over the years. Also, Acunetix has recently integrated some of these checks in their Acunetix Web Vulnerbility Scanner product which can be a valuable addition to its application checks. Such scanners will find the issues listed above and more. When looking for tools to perform server-side vulnerability checks you'll want port scanning, system enumeration, and exploitation (or at least data extraction) capabilities. The specific scanner you end up with doesn't matter as much as how often its vulnerability database is updated, how comfortable you feel using the tools, and the responsiveness of the vendor.
Do yourself and your business a favor and not only look at your Web applications but also what they're riding on. It's surprising just how vulnerable any given Web system can be made by a few underlying server issues. It'll require minimal additional effort and there's nothing to lose.
This was first published in December 2009
Join the conversationComment
Share
Comments
Results
Contribute to the conversation