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?
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?
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 firstname.lastname@example.org.