Automated Application Vulnerability Scanners
by Roshen Chandran, CISSP | Discuss this article »»
Organizations have been looking at Application Vulnerability Scanners to automate the task of assessing the security of applications. This article explains how these scanners work, where to use them and where they are inadequate.
Like OS and Web server vulnerability scanners before them, modern day Application Vulnerability scanners maintain a database of vulnerabilities and generalized methods to check for them. The scanner has a set of input patterns that it tries against an application, and a set of output patterns it compares the results against to see if the application is vulnerable.
For instance, to check for SQL Injection, the scanner gives an input with a quote [‘] and checks if the web page returned an ODBC error message. The error message would signify that the application accepted the quoted input and might be vulnerable to SQL Injection. If no ODBC error message is received, the application is probably safe. This does not always work though, as the application might employ a custom error page that masks the ODBC error message. At such times, the scanner gives false negatives and misses out on holes.
An automated scanner is essential to check for highly repetitive tests that require a large number of iterations. For instance, a scanner can alleviate the task of checking through the long list of possible hidden files and folders lying around in a web server. An automated tool is also handy if one wants to mount a password guessing attack to look for simple passwords.
Anecdotal evidence suggests that scanners account for between 5 to 20% of the vulnerabilities discovered in an assessment. What then are the kind of vulnerabilities that scanners do not discover that account for 80—95%?
In the author’s experience, the most damaging and numerous vulnerabilities in today’s applications are those which have a direct business impact. For instance, bugs in an online banking application that allow unauthorized transfer of funds. Or holes in a gaming application that lets a user increase his score artificially. Or even vulnerabilities in an extranet that lets a competitor steal costing details of components.
Identifying vulnerabilities that could lead to direct business impact requires the adversary to understand the business context of the application. For instance, unless an adversary “knows” the concepts of accounts and fund transfers, he cannot perform an unauthorized fund transfer. Or in the case of gaming fraud, the adversary needs to understand the scoring rules before he can possibly violate them.
Automated scanners operate at a different level where they repeatedly try out a large number of “attack inputs” and compare the outputs. The scanner is not really aware of the concept of a bank transaction or the rules of the game, and so it does not envision threats that can violate them. Since many high risk vulnerabilities require an understanding of the business context, automated scanners tend to miss them.
In conclusion, automated scanners should be used to identify bugs that don’t require understanding of the business and where the adversary has to try a large number of inputs before the hole is discovered.