10 Ways to Protect Your Web Servers

When we think about how to protect our information systems against attack, the typical things that come to mind are firewalls, encryption and applying the latest software patches. These technical solutions are often where the information security focus is both monetary and administrative. Keep the bad guys out of the network and keep the servers up to date and everything’s safe and secure — that’s the management assumption. What many people do not realize, however, is none of these technologies — in any combination — will protect against the thousands of ways that Web sites and Web applications can be exploited. Something needs to change.
I will venture to guess that every viable business today has some type of Web presence. Be it a marketing site, B2B or B2C e-commerce systems, ERP and HR systems, e-mail, data center control systems — if it is a business application, it is probably Web-accessible. And Web servers are not just externally facing — they are often scattered across the internal network in places you would never think about. I am finding that many network administrators and security managers are not even aware of half of the Web servers on their networks. A lack of awareness equals a lack of administration, which leads to Web security vulnerabilities. It is just a matter of time before someone — either inside our outside of your organization — stumbles across and exploits them.

What’s So Vulnerable?
The key to understanding the importance of Web security is seeing just how vulnerable Web-based systems can be. The attacks and exploits are not some magic voodoo that only the propeller heads in IT can understand. Given that most of us use some sort of Web-based system on a daily basis and are familiar with the technology, the vulnerabilities are pretty simple to grasp. Here’s a list of common Web-related weaknesses I come across in my work that highlight the problems we face:
• Underlying weaknesses at the operating system and Web server levels — such as unhardened systems with missing patches that an attacker can take advantage of in order to gain access “below” the application, and thus, often evade Web monitoring and logging systems.
• Vendors placing default user IDs and passwords assigned to Web servers running on firewalls, wireless access points and even physical security control systems — and network administrators not changing them.
• Login weaknesses that give an attacker a leg up on determining valid user names and cracking passwords. This problem is exacerbated when intruder protection is not in place to lock accounts after a specified amount of failed login attempts.
• Web applications that use the person’s network logon ID to authenticate to the system. Anyone knowing the user naming scheme on the network can simply insert another user ID and make it look like they are the one logged in.
• Weak minimum password requirements such as five or six numbers that can be easily-guessed or cracked in a matter of seconds.
• Simultaneous user logins allowed, which create accountability issues if/when an incident occurs.
• Web browsers leaving login credentials stored in memory on shared computers, which an attacker can exploit by simply installing a hex editor on the system and searching the computer’s memory for the previous user’s login ID and password.
• Unvalidated input in Web forms, login pages, etc., that enable a user to input malicious code or too much data for the system to handle. This can cause the server or application to divulge too much information, including the passage of malicious scripts back to the user (a hack called cross-site scripting) as well as enabling an attacker to download information from the back-end database (a hack called SQL injection). This type of input could cause the system to crash altogether.
• Vulnerabilities such as cross-site scripting and SQL injection only when logged-in at a certain user level — something that’s often overlooked.
• Applications that try to hide hard-coded input to the server in what are called hidden fields. These hidden fields — typically found in e-commerce shopping carts — can be easily manipulated enabling the user to change prices, quantities and more on the fly for ill-gotten gains.
• Application logic problems that a crafty user can exploit and “break” the way the application works.
• Unique errors and “undocumented features” generating sensitive information to someone using an unsupported Web browser to access the system.
• Files loaded on a Web server such as PDF files, Excel spreadsheets and system log files accessible by anyone on the Internet that should, instead, be protected via user login.
• Certain Web server management software left enabled that enables anyone to create and delete folders and files on the system.
There are so many variables involved that the list of Web insecurities is endless. There’s even a widely-accepted “Top 10 Web Vulnerabilities” documented by the Open Web Application Security Project (OWASP). Suffice it to say that one or more of these issues may very well be present on one or more of the Web-based hosts on your network. In most cases, unless Web and application logging is enabled and being monitored, no one will ever know the systems have been breached.

Where to Start
Just like in the physical security realm, we cannot assume that no business risks exist unless we actually verify it by performing an in-depth security assessment. The following are the 10 steps required to ensure you (or your IT team) are testing the right systems in the right ways. You may consider hiring an outside consultant for this type of work as well as they can often find new things that every day system administrators take for granted.
1. Take an inventory of your Web-based systems — You will know the obvious ones, but it is the not-so-obvious ones that you have got to dig up. Do not forget to look at things like Ethernet switches, copiers, and networked cameras since almost every networked system has a Web server built-in these days. You can find Web servers on the network by running a simple port scan of the network segments looking for the common Web server ports (TCP 80, 443, and 8080). Many of the Web security scanners listed below have such a discovery tool built right in.
2. Prioritize your systems based on business function and the information they process — Even though every Web system needs to be looked at, it is important to focus on where “the money” is to get started.
3. Gather the right testing tools — The success of your Web security testing is directly proportionate to the quality of tools that are used. You will need both network/operating system-level tools such as LANguard Network Security Scanner and QualysGuard as well as Web-centric tools such as WebInspect, N-Stalker Web Application Security Scanner and Acunetix Web Vulnerability Scanner. Also, do not forget about password cracking tools such as Brutus and Cain. Outside of a handful of free tools, you almost always get what you pay for.
4. Set everyone’s expectations — The cardinal rule of security testing is to make sure all the right people are in the know and on the same page. Outline what outcomes are expected and make sure everyone is on board with the testing dates and timeframes. This will minimize the impact on the network, servers and business overall.
5. Perform automated scans — Run the tools listed above to find confirmed and potential vulnerabilities on the Web server and applications. This is a very important step as there is no way to realistically uncover all the Web vulnerabilities by just manually assessing the system yourself.
6. Perform a manual analysis — Looking at the systems yourself, you can determine which of the scanner findings are valid as well find other application logic flaws that automated tools will not be able to find. Look at your system from every possible perspective as an untrusted outsider as well as a trusted user (at all user levels).
7. Focus on the urgent and important vulnerabilities — You will undoubtedly find numerous vulnerabilities on most if not all your Web systems. Do not get caught up in the minutiae — instead, focus on the easily-exploitable security flaws on the most critical systems and then follow-up with the lower-priority findings when you have the time.
8. Perform a source code analysis on custom-written software — A source code analysis looks at the actual code the developers have written. The only reasonable way to perform a code review such as this is to use an automated static analysis tool such as Klocwork, DevInspect and Fortify 360. I have yet to perform a source code analysis that did not uncover critical flaws that were difficult to find using other means yet still could have been easily exploited under the right conditions.
9. Delegate remediation tasks and follow up to ensure the holes are plugged — This is perhaps the most important part of security testing, but for some reason, it often gets overlooked. I have seen many organizations spend lots of time, effort and money to determine where their Web systems are vulnerable, and then not follow up on any of it. It is a classic case of limited accountability and lack of management buy-in.
10. Test and test again — Web security testing is not a one-time deal. It is something that needs to be integrated into the organization’s overall risk management practices. As with the lack of follow-up mentioned above, I often see people test once, fix the problems, and assume all’s well in Web-land for years to come. Given that security flaws are constantly evolving, the complexities associated with Web servers and applications, and the fact that Web systems are the front-end to the lifeblood of your business, they need to be tested periodically and consistently without fail. No exceptions.
Do not get caught off-guard by a Web server or application hack. The weaknesses are there. It is just a matter of making it a higher business priority to find and fix them before someone else exploits them. Once you do, you will have one more reason to rest easier at night.

Kevin Beaver is an independent information security consultant, keynote speaker and expert witness with Atlanta-based Principle Logic LLC where he specializes in performing independent information security assessments. He has authored/co-authored seven books on information security including “Hacking for Dummies” and “Hacking Wireless Networks for Dummies” (Wiley). He is also the creator of the Security On Wheels information security audio books and blog providing security learning for IT professionals on the go. He can be reached at [email protected].