News Stay informed about the latest enterprise technology news and product updates.

Recipe for successful Web application security testing

Paco Hope, co-author of the "Web Security Testing Cookbook," talks about the importance of having a security testing plan and what tools and techniques are necessary.

It seems like everybody is susceptible to cross-site scripting (XSS) and SQL injection, and testers just don't have the time, tools, and expertise to test for them.
Paco, your book -- "Web Security Testing Cookbook" -- is about techniques for finding Web security flaws. Why is it important to have a plan and approach Web security testing in a systematic and methodical way?
QA and testing teams are being asked to do more with less, and that "more" often includes increased attention to specialized concerns like security. To meet these tough expectations, you have to have a good plan and a good set of tried-and-true methods to build your security test cases right. What Web security vulnerabilities are the most predictable -- the ones you know you're going to find regardless of how secure the application supposedly is?
It's always the usual suspects: cross-site scripting (XSS) and SQL injection. I do security assessments throughout the financial sector (retail banking, financial services) as well as routine retail and commercial services. It seems like everybody is susceptible to these two attacks, and testers just don't have the time, tools, and expertise to test for them. Just how important are manual analysis techniques when testing Web applications such as those you outline in Chapter 9 -- Seeking Design Flaws? If you use good tools, do you really need to look at the application the old-fashioned way?
We'll never eliminate the human element. One of my colleagues just finished assessing a major retail bank's site and Recipe 9-5 in the book found something major. At this bank, initial passwords were the same as user IDs. Knowing that, an attacker could try popular user IDs or user IDs that were generated using the site's standard formula and begin taking over accounts that had not been initialized by their rightful owner. No tool has the smarts to intuitively figure out that this is a bad idea, even though humans smack their foreheads as soon as they see it. During your Web security testing, what is the craziest thing you've seen Web developers do to "lock down" an application using security by obscurity?
The craziest thing I've seen, of course, is nothing. Lots of people deny the problem and do nothing. I've seen people try to make long lists of all the SQL verbs and keywords (e.g. SELECT, UPDATE, WHERE, DROP TABLE). It never works. The worst was in response to a human resources (HR) system that allowed job seekers to submit HTML resumes over the Internet. I pointed out that the HTML could contain lots of malicious JavaScript that would run in the HR director's Web browser. Their solution was to only accept file names ending in .txt or .pdf. If, however, your .txt file was actually HTML with JavaScript, Internet Explorer happily interpreted it as a Web page, executing the malicious JavaScript. They were satisfied. There's a big focus on Web application source code these days. Just how important is static source code analysis in the overall Web security equation?
Recipe from the "Web Security Testing Cookbook"
Learn how to test how your application handles files with malicious content in Recipe 8.8, Uploading Malicious File Contents.
Source code analysis is a vital complement to what we're describing in our book. Our techniques are outside-in techniques, and they find symptoms of problems. Ultimately, the problem is in the code, and it has to be found and fixed there. Source code analysis tools are the inside-out half of that equation. For people entering the field of information security, specifically Web application testing, what are the advantages of using freeware and open source tools that you use in your book?
Free tools can be worthwhile even if they fill a narrow, vital niche. Expensive tools need to be broadly applicable to justify their return on investment. Source code lets you keep using a tool even if its authors abandon it. Many of us test legacy software with historical batteries of tests. Source code for our tools helps us keep old tools around to test our legacy software. Is it your experience that these free Web security testing tools are every bit as good as their commercial alternatives?
Major commercial scanning tools represent thousands of man-hours of test case development and test automation that you can't build from scratch with free tools. Those tools are unwieldy, though, when your developers fix a specific vulnerability, and you need to build a test case for that one fix. To build individual security test cases, use our techniques. To assess an entire application from top to bottom, use a commercial tool. You have an entire chapter dedicated to testing Ajax security. Can you recommend any must-have tools for uncovering Ajax flaws or is manual analysis the most dependable way to find client-side weaknesses?
The must-have tools are Firefox with the Firebug and TamperData add-ons and a good proxy like WebScarab, Paros, or Burp. As source code analyzers get better at JavaScript, they'll start to add to our security picture. The complex interplay between server-side code that generates a DOM (Document Object Model) on the fly and client-side code that asynchronously operates on DOM later limits the security defects that can be found automatically.

Paco Hope is a technical manager at Cigital. His areas of expertise include software security, security testing, and online casino gaming. He specializes in analyzing the security of software, software systems, and software development processes.

About the author: 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 security assessments and information security career counseling for up-and-coming IT pros. He's still trying to pin down exactly how the certifications and degrees he has earned have benefited his career, but he knows deep down that they have. Kevin has authored/co-authored seven books on information security, including Hacking For Dummies and Hacking Wireless Networks For Dummies (Wiley). He's also the creator of the Security On Wheels information security audio books and

Dig Deeper on Software Security Test Best Practices

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.