Many companies are under the impression that testing for Web application security simply involves a cursory check for easy-to-guess usernames and passwords. But Ryan English believes application security testing can and should involve more complex checks, such as testing for SQL injection and cross-site scripting. In this column, Ryan explains that management should avoid postponing this sort of review until the Web application is in production, when it is too late to stop a hacker or a malicious program from attacking and much more expensive to remediate the vulnerability. Instead, QA groups should enter the SDLC early to help mitigate risk.
Quality assurance (QA) departments have traditionally focused on functional testing--making sure that an application works properly and seamlessly performs all its necessary tasks. However, as Web application security becomes more important, your QA department is more likely to become a critical participant in application security testing.
Getting Your QA Department Involved
There are three ways that your QA department may become involved with Web application security testing:
- Your company's Web security experts request that the QA group perform application security testing to ensure that all fixes have been implemented and no security holes exist prior to releasing the product to production.
- Your compliance officer, facing concerns about SOX, HIPAA, PCI, and so on, requests that more application security testing is performed during the QA process.
- Your QA department requests being involved in testing Web application security because end-users won't perceive an application with security holes as high-quality software.
No matter how the department gets involved, certain steps will need to be taken to establish an application security testing process. You will need to determine if specific, dedicated staff members will perform Web application security testing or if the task will be dispersed throughout your entire QA group. In addition, the timing of this testing during the QA process will need to be managed. Ideally, application security testing is performed as early as possible, so that developers can fix any security issues in a timely manner without compromising the project's schedule. Choosing the right software for application security testing and implementing it is another crucial step.
Choosing the Right Tool for Web Application Security Testing
Application security testing software should perform three different types of testing--as a non-authenticated user, an authenticated user, and an administrative user--to determine the vulnerabilities inherent in each user class. Additionally, the tool should be able to perform both automated and manual crawling/spidering of your Web application.
Automated application security testing software "spiders" the entire application by clicking every button and link, filling out data fields to identify the structure of the program, and then auditing each page for vulnerabilities. It should do this from the outside in, reviewing each portion of the site the way an external hacker might, ideally from behind the scenes. This comprehensive approach ensures that all security holes have been identified and can be fixed. On the down side, it can also produce false positives, and it may not be able to access all of your Web pages due to the coding of certain pages.
Manual crawling allows a user to focus on specific pathways or tasks on a Web site while the software follows silently behind, tracking the process. The program audits the particular path for security vulnerabilities and provides a report. Manually crawling an application can be time consuming, but it ensures that specific pages are tracked and analyzed.
Basic Guidelines for Choosing an Application Security Testing Product
These basic questions should be addressed when you are looking for a Web application security testing product:
- How easy is the product to use?
- What kind of training will your QA department require in order to properly use the product?
- How well does the product integrate into the tools and software that are already used by your organization?
- How often is the product updated with new security checks--daily, weekly, or monthly?
- What is the false-positive rate of the product? (While no product is perfect, you want to find one with the lowest rate possible so that you don't waste resources going through false positives.)
- What partnerships does the manufacturer have in place? Is it partnered with IBM, Microsoft, or Mercury? (Note that the more partnerships a company has, the more likely the Web application security product will easily integrate with commonly used systems and products.)
- Does the product appear to evaluate each page of your application, or does it get stuck on certain pages?
- Does the product allow the end-user to easily modify scan settings?
- What kinds of restrictions are in the product's license?
- In which formats are reports offered (PDF, HTML, XML)? Are they easy to read? Do they contain information on the location of the vulnerability, how to execute it, how to verify it, and how to fix it?
- Will the company allow you to evaluate the product before committing to purchase it? (Confident vendors often provide a seven- to fifteen-day evaluation period.)
Web application security is of major importance, and your QA department needs to be involved in order to ensure that your final product is free of security defects. By implementing the proper tools and establishing application security testing early in the QA process, you can avoid many last-minute security problems and be more confident that you are releasing secure, robust applications.
