Testing web applications for security flaws
David Hoelzer is the Director of Research, Enclave Forensics and a SANS Trainer. In this interview he discusses web application testing, offers advice for those on the hunt for web application vulnerabilities and introduces his training course at SANS London 2011.
What are the most important things to keep in mind when testing websites and web applications for security flaws?
I’ll just name three. The first is, if you’ve never tested it, expect to find problems. Don’t be satisfied with a scan that looks clean. You need to dig into the application.
The second, in line with the first, is that since you’re expecting to find problems you really, really ought to be doing your initial testing in your QA environment, not on the production site. While it’s true that attackers will have no qualms about going after your live site, the risk of causing real damage through your testing is too high on the first go, so do the testing in a lab-like environment.
The third one is that web-app testers are a dime a dozen. A top quality web app security tester who knows his business is much harder to find. Figure out a way to vet that tester before you hire him. We actually spend some time at the end of the day on web application security auditing within the Audit 507 Advanced Audit course discussing exactly how to do this.
Many security professionals are interested in hunting for web application vulnerabilities. What advice would you give to those just starting out?
Get training. I know that might sound self-serving, but there’s a lot of bad advice out there. Let me give you an example that’s not precisely a “finding vulnerabilities” issue, but rather a “how do I fix this problem” issue. The two are related because if you’re looking at bad “fix it” advice, you’re not going to do a super job doing the testing.
I’ve seen many people give the advice that requiring the use of Stored Procedures will eliminate SQL injection flaws. In fact, I even came across an article from IBM stating something to this effect! This advice is just plain wrong. There are ways to prevent SQL injection with minimal code modifications, but if you’re following bad advice you’re just never going to get it right. This is why quality training to form that foundation of knowledge is so critical.
What web vulnerability scanners would you recommend and why?
I may not be popular in saying this, but my answer is “None.” It’s not that I don’t use tools of this sort, I do. However, I view this tools as configuration testers.
Why is this? Web application vulnerability testers are only going to be able to identify known flaws that follow previously identified patterns. If you’re using canned web applications that you’ve purchased or downloaded, you may find these tools very useful. However, if you’ve created your own web applications within your enterprise, the value of these tools rapidly diminishes.
How can an automated tool know something bad has happened when it sends some bad input resulting in access to a page it should not be able to get to? Can the tool look at the input requirements, consider the context and come up with a clever but reasonable alternate set of input that leads to something serious happening? The answer to both of these questions is that it can’t. For this reason, some say that the automated tools are able to find only 50% of vulnerabilities in most situations.
There’s just no substitute for a person who knows what he’s doing.
Any suggestions for what users should lookout for when testing/evaluating web vulnerability scanners?
Yes! Here’s a super easy thing to do. Take a past version of your own enterprise application. You’d like something that you know has flaws in it, flaws that you can identify because you’ve already fixed them.
Now run the vulnerability scanner and see how it does. Nine times out of ten you will find proof of what I said in the answer to the last question!
What does your SANS training course look like? What skills can attendees expect to acquire?
While the course is billed as an Audit course (and it surely does cover audit techniques and practices!), it’s actually a phenomenal course for incident handlers, operations staff and security officers. Using a risk driven approach, we deep-dive through major security and operational systems that should be in place, how to test them and even how to develop/implement them.
For instance, on the second and third days, we spend the entire time dealing with perimeter issues, firewall validation, router placement, network design, layer 2 security issues and more.
The entirety of the fourth day is spent drilling down into and performing web application security validations; sort of a crash course in how to effectively audit and test a web application.
The fifth day is spent developing an enterprise wide Windows security auditing system that scales out to touch every workstation and server.
Finally, on the sixth day, we dig into UNIX operating systems and creating a manageable security and audit framework for these systems within our environments.