Vulnerability Scanners
A number of different tools exist for performing automated vulnerability scans of web applications. These scanners have the benefit of being able to test a large amount of functionality in a relatively short time, and in a typical application are often able to identify a variety of important vulnerabilities.
Web application vulnerability scanners automate several of the techniques, including application spidering, discovery of default and common content, and probing for common vulnerabilities. Having mapped the application’s content, the scanner works through its functionality, submitting a range of test strings within each parameter of each request, and analyzes the application’s responses for signatures of common vulnerabilities. The scanner produces a report describing each of the vulnerabilities it has discovered. This report usually includes the specific request and response that the application used to diagnose each reported vulnerability, enabling a knowledgeable user to manually investigate and confirm the existence of the bug.
A key requirement when you are deciding whether and when to use a vulnerability scanner is to understand the inherent strengths and weaknesses of these type of tools, and the challenges that need to be addressed in the course of developing them. These considerations also affect how you can effectively make use of an automated scanner, and how to interpret and rely upon its results.
Vulnerabilities Detected by Scanners
Several categories of common vulnerability can be detected by scanners with a degree of reliability. These are vulnerabilities with a fairly standard signature — the scanner sends a crafted request designed to trigger this signature if the vulnerability is present; if the signature appears in the application’s response to the request, then the scanner infers that the vulnerability is present.
Here are some examples of vulnerabilities that can be detected in this way:
■ Reflected cross-site scripting vulnerabilities arise when user-supplied input is echoed back in the application’s responses without appropriate sanitization. Automated scanners typically send test strings containing HTML markup, and search the responses for these strings, enabling them to detect many of these flaws.
■ Some SQL injection vulnerabilities can be detected via a signature. For example, submitting a single quotation mark may result in an ODBC error message, or submitting the string ‘; waitfor delay ‘0:0:30’– may result in a time delay.
■ Some path traversal vulnerabilities can be detected by submitting a traversal sequence targeting a known file such as boot.ini or /etc/passwd and searching the response for the appearance of this file.
■ Some command injection vulnerabilities can be detected by injecting a command that will cause a time delay, or will echo a specific string into the application’s response.
■ Straightforward directory listings can be identified by requesting the directory path and looking for a response containing text that looks like a directory listing.
■ Vulnerabilities like frame injection, liberally scoped cookies, and forms with autocomplete enabled can be reliably detected by reviewing the contents of client-side code.
■ Items not linked from the main published content, such as backup files and source files, can often be discovered by requesting each enumerated resource with a different file extension.
Inherent Limitations of Scanners
The best vulnerability scanners on the market have been designed and implemented by experts who have given serious thought to the possible ways in which all kinds of web application vulnerabilities can be detected. It is no accident that the resulting scanners remain unable to reliably detect many categories of vulnerability. There are various inherent barriers to a fully automated approach to web application testing. These barriers will only be effectively addressed by systems with full-blown artificial intelligence engines, going far beyond the capabilities of today’s scanners.
Every Web Application Is Different
Web applications differ starkly from the domain of IT networks and infrastructures, in which a typical installation employs off-the-shelf products in more-or-less standard configurations. In the latter case, it is possible in principle to construct in advance a database of all possible targets, and create a tool to probe for every associated defect. This is not possible with bespoke web applications, and any effective scanner must expect the unexpected.
Scanners Operate on Syntax
Computers can easily analyze the syntactic content of application responses and can recognize common error messages, HTTP status codes, and user-supplied data being copied into web pages. However, today’s scanners cannot understand the semantic meaning of this content, nor can they make normative judgments on the basis of this meaning. For example, in a function which updates a shopping cart, a scanner will simply see numerous parameters being submitted. The scanner is not able to interpret that one of these parameters signifies a quantity, and another signifies a price. Further, it is not able to determine that being able to modify an order’s quantity is inconsequential, while being able to modify its price represents a security flaw.
Scanners Do Not Improvise
Many web applications use nonstandard mechanisms for handling sessions and navigation, and for transmitting and handling data — for example, in the structure of the query string, cookies, or other parameters. A human being may quickly notice and deconstruct the unusual mechanism, while a computer will continue following the standard rules it has been given. Further, many attacks against web applications require some improvisation — for example to circumvent partially effective input filters, or to exploit several different aspects of the application’s behavior that collectively leave it open to attack. Scanners typically miss these kinds of attacks.
Scanners Are Not Intuitive
Computers do not have an intuition about how best to proceed. The approach of today’s scanners is to attempt every attack against every function. This imposes a practical limit on the variety of checks that can be performed and the ways in which these can be combined. There are many cases where this approach overlooks vulnerabilities. For example:
■ Some attacks involve submitting crafted input at one or more steps of a multistage process and walking through the rest of the process to observe the results.
■ Some attacks involve changing the sequence of steps in which the application expects a process to be performed.
■ Some attacks involve changing the value of multiple parameters in crafted ways — for example, an XSS attack may require a specific value to be placed in one parameter, to cause an error message, and an XSS payload to be placed into another parameter, which is copied into the error message.
