Testing Web applications for security vulnerabilities can be exciting. There are neat tools and interesting ways you can make a Web application hiccup, crash or otherwise give out information you shouldn't be able to see. As fun as it may be, testing your Web application security is also something that needs be taken seriously. The best way to be successful is to prepare in advance and know what to look for. Here's an essential elements checklist to help you get the most out of your Web application security testing.
[IMAGE]Set everyone's expectations
The Golden Rule of performing security assessments is to make sure that everyone affected by your testing is on the same page. Start by working with your project sponsor (i.e., CIO, VP of audit, IT director or compliance manager) and determine the business goals for what you're doing. It sounds trite, but it's important that everyone understands what outcomes are expected and what the next steps will be. It's also extremely important to select testing dates and timeframes that will minimize the impact on the business. There'll likely never be an ideal time, so go for the next best thing by figuring out when the network bandwidth and processor cycles consumed by your testing will hurt the least.
Also, don't be afraid to tell others that problems such as locked accounts, performance hits and server reboots may occur. Better to get it out on the table now rather than let it fester and become a major issue later when people are caught off guard. Finally, keep people in the know during your testing and follow up with them when you're done to share how things transpired, what was found, and what they may need to do to help fix any security vulnerabilities.
[IMAGE]Gather good tools
As with all things security-related, your tools will make or break your assessments. In fact, the number of legitimate vulnerabilities discovered is directly proportional to the qua
To continue reading for free, register below or login
To read more you must become a member of SearchSoftwareQuality.com
lity of your security tools. There are several open source Web application testing tools that I depend on in my work -- most of which are available in the BackTrack suite of tools.
Outside of that, you usually get what you pay for. There are low-cost Web application security testing tools and several others with much higher price tags. I've found out the hard way that, by and large, high-end equals high quality. Good tools translate into more (and more complex) security flaws discovered, as well as less time and effort wasted trying to track them down. The reporting capabilities of commercial tools are unmatched as well. The tools I've come to depend on are HP's WebInspect and Acunetix Web Vulnerability Scanner. When I can I use both tools, because they tend to find different things that I don't want to overlook. Keep in mind that tools aren't everything, though. (There's more on this below.)
[IMAGE]Look at your application from every perspective
Perform a reconnaissance on your Web application and see what the world can see using Google and its hacking tools such as Foundstone's SiteDigger. Odds are you won't find a lot of stuff, but you'll never know until you check. Next, run a Web vulnerability scanner such as the ones I mentioned above. Where you can, be sure to run your scans as both an unauthenticated and untrusted outsider as well as an authenticated and trusted user (via basic HTTP, NTLM or form authentication).
Web abuse knows no boundaries. By looking at your application from different angles, you'll undoubtedly find different types of vulnerabilities that can be exploited from both outside and inside your network. With your authenticated scans, test out every role level or user type if possible, since some vulnerabilities will be available only to users with certain privileges.
[IMAGE]Test for underlying weaknesses
One of the most commonly overlooked areas of Web application testing is failing to scan the underlying operating system and installed applications. With tools such as Nessus and QualysGuard, you'll be able to root out problems such as missing patches and misconfigurations in your operating system and other software you have installed (including the Web server itself) that can lead to a Web application compromise. If you want to get the entire picture, you should also look at your back-end databases and related network infrastructure systems. A single weakness outside of the Web application that's overlooked can put everything at risk.
[IMAGE]Go back and verify your scanner findings
As much as the marketing machine wants us to think that security testing tools are void of any shortcomings, they aren't. Don't believe what you see and hear. Get in and validate that the security weaknesses they discovered are legitimate. Validating and reporting on genuine security vulnerabilities in the proper context will save everyone time and effort in the long run. It will also instill confidence in others and make them want to take you seriously.
Verifying your results simply requires going back to your original scanner data or exported reports and seeing if you can reproduce the problems the tools found. For certain issues, you may need only a simple Web browser for validation. For others, you may need the power of a Web proxy tool or HTTP editor, such as the free Paros proxy tool or the tools bundled with many commercial scanners. Check to see if you can reproduce the problem. If you can, take a screenshot of your findings and stick it in your report. If you can't and you're confident it's a false-positive, move on to the next issue.
[IMAGE]Manually check for weaknesses
Don't stop now. Your security testing tools may have uncovered a lot of weaknesses in your Web application, but there are likely several more things left to exploit. This is where your human context and Web usage expertise come into play. Get in and poke around in the application a bit more to see what else can be done from a malicious point of view. I can't tell you how many times I've found flaws in login mechanisms, form input validation and sensitive information buried in HTML and server directories that automated tools would never uncover.
[IMAGE]Test your source code
Until you look at your Web application's source code, you won't be able to say with conviction that everything's been tested. Sure, timing, politics and the old security budget tend to overshadow what's important in a situation like this. At least make it a priority on your to-do list for the next go around. Source code analysis tools have matured greatly over the past few years, and they're not just for developers anymore. Tools such as DevInspect and Checkmarx can help both developers and security professionals check for software flaws at the source.
I'll admit, static analysis tools are not the simplistic point and click tools that general Web application vulnerability scanners are -- especially when setting things up and getting the source code loaded in. But once you get rolling, they are easy to use and can find flaws that you'd likely never know about until someone exploited them. With the detailed findings and beneficial reports that these tools can produce, more and more I'm hearing seasoned developers say such things as, "Interesting -- I hadn't thought about that."
Plan your testing, cover all your bases when looking for flaws, and -- most important of all -- use good old-fashioned common sense and you're sure to improve your Web application security.
-----------------------------------------
About the author: Kevin Beaver is an independent information security consultant, speaker, and expert witness with Atlanta-based Principle Logic, LLC. He has more than 19 years of experience in IT and specializes in performing information security assessments revolving around IT compliance. Kevin has authored/co-authored six books on information security including Hacking For Dummies and Hacking Wireless Networks For Dummies (Wiley) as well as The Practical Guide to HIPAA Privacy and Security Compliance (Auerbach). He's also the creator of the Security On Wheels series of audiobooks. Kevin can be reached at kbeaver@principlelogic.com.
