Organizations of all sizes use Web applications to deliver services and expand business processes. However, hackers are always searching for weaknesses within these online applications, as they can represent a gateway into valuable back-end databases. With the advent of Web 2.0 features, including blogs, wikis, RSS and other advanced Internet technologies, Web applications are powerful, complex and constantly changing, increasing the likelihood of new vulnerabilities within an application.
To help developers track down and find potential security holes, there are a host of tools available called Web application vulnerability scanners. Their aim is to automate and speed up a process that, when performed manually, is a long and painstaking one. By crawling through a Web site and injecting various attack scenarios, scanners compare an application's responses against a database of security vulnerability signatures.
Despite their usefulness, Web application vulnerability scanners have not become a must-have for every development team, largely because of cost. Yet there are several good open source scanners available for free. In this tip, we'll examine a few other reasons for the holdup in Web application vulnerability scanner adoption.
1) So many choices
One problem many potential buyers have is that it's difficult to compare and choose among the different scanners. No one scanner seems to do it all, or match both budget and feature requirements for a particular application platform. Help is at hand in this area, however. The Web Application Security Scanner Evaluation Criteria are a planned set of guidelines to evaluate Web application security scanners on their ability to identify Web application vulnerabilities.
2) Web app scanners can only find so much
Scanners have not caught on in the enterprise, partly because they only find "well-known" network security flaws, ones that have been assigned a signature. Over-hyping what scanners can do has led to unrealistic user expectations. The tools cannot perform an entire vulnerability assessment on their own. Sure, they are great for finding common technical vulnerabilities, such as SQL injection flaws, cross site scripting vulnerabilities, parameter tampering, hidden field manipulation, backdoors, debug options and buffer overflows.
But custom-written Web code Is another story. A Web site's custom application code is a dangerous point of insecurity, particularly if it uses Ajax, as each of its server-side functions represent additional attack points for hackers. With so many possible permutations of user and service interaction, these particular types of apps make it difficult to automate testing, since some vulnerabilities can pass through a scanner's checklist.
3) Scanners can't work alone
Until scanners can harness true artificial intelligence, they will always struggle to find certain categories of vulnerabilities. Scanners can only process syntactic information; they can't put the anomalies into context or make any normative judgments about them. Until the technology can improvise or draw intuitive conclusions, making analytical inferences to determine that data has leaked, for example, is never something that a computer is going to be able to detect. Only security experts can identify business logic flaws, because these types of vulnerabilities are contextual.
Finding a place for application vulnerability scanners
Application security scanners do have a role, though, in the secure application development life cycle. The tools can quickly find common programming errors, leaving more time for human code reviews and analysis. An ideal scanner has regular updates that help search for the latest known problems. Scanners should be usable throughout the application development lifecycle, not just on the finished product. To be effective, a scan should be able to utilize information it gathers to form the basis of the checks that follow. It should also allow a combination of manual and automated analysis. For example, by using a scanner that allows the viewing, changing and recording of HTTP/HTTPS requests and responses, developers can expose application behavior on-the-fly or during a later review. Finally, scan reports should be easily understood, and the scanner itself should be straightforward to use. There should also be clear guidelines on what the tool can and cannot check. These features are all available on different scanners, but no one scanner yet really has them all.
It's going to take time to learn and get the best out of a scanner, and developers tend to be over-stretched as it is. The cost of fixing vulnerabilities in a live production environment, however, suggests that the application testers are tools worth considering.
About the author:
Michael Cobb, CISSP-ISSAP is the founder and managing director of Cobweb Applications Ltd., a consultancy that offers IT training and support in data security and analysis. He co-authored the book IIS Security and has written numerous technical articles for leading IT publications. Mike is the guest instructor for several SearchSecurity.com Security Schools and, as a SearchSecurity.com site expert, answers user questions on application security and platform security.
BUFFER OVERFLOW TUTORIAL
Buffer overflow protection introduction
How to prevent buffer overflows
What causes buffer overflows
Testing for buffer overflows
Web application vulnerability scanners
