Mapping The Application Security Terrain - Part Two

What types of security risks should be considered?

A useful starting reference point is the vulnerability taxonomy maintained by OWASP, the Open Web Application Security Project. There, one can find hundreds of articles defining common application security flaws. OWASP also maintains a TOP 10 list of the most critical web application vulnerabilities. While the Top 10 list is a very useful document to increase security awareness, like most lists of this sort, it is neither intended to be comprehensive nor a sufficient definition of application security. AsTech maintains a more wide-ranging catalog of vulnerability classes which we have developed over the past 10 plus years.

There are a number of approaches to assessing application security involving varying combinations of automated and manual analysis from an external (black box) and internal (white box) perspective.

External Web Application Scanning

Application scanning involves interacting with a running application (essentially using and attacking the application) as a black box to identify points of vulnerability. While the best of breed commercial automated scanning tools can produce some valuable results, they still can't approach the quality and breadth of results that can be identified by a highly skilled ethical hacker.

The strength of application scanning is that because the application is actually attacked, the resulting proof of vulnerability is usually quite concrete and compelling. For example, the results of a successful SQL injection attack might include data or metadata accessed without authorization. If you can see another user's account data or display the structure of the database, it is hard to argue with existence of the vulnerability.

The weakness of application scanning is that it identifies only a limited range of vulnerabilities and often requires a highly skilled practitioner. Since the application user interface is the attack vector, the approach is ill-suited to examining business component, back-end, or external service vulnerabilities. For example, if sensitive data such as social security numbers are not being encrypted, or third-party services operate without proper protection, or critical security events such as failed logins are not being adequately logged, these vulnerabilities are likely to go undetected.

Automated Static Analysis

Static analysis involves the review of the application code for vulnerabilities. For most tools, this usually refers to the source code but less frequently refers to the binary code. This would be considered a 'white box' assessment, as nothing is hidden from the analyst. The application code is a much larger and richer analysis target than the user interface addressed by external, or 'black box' application scanning, and therefore a broader range of vulnerabilities can be identified.

The best of breed static analysis tools utilize sophisticated compiler technologies such as data flow analysis, control flow analysis, and pattern recognition to identify security vulnerabilities. The results of automated analysis generally include a high degree of false positives, requiring a highly skilled security engineer to analyze the results with the source code in hand to distinguish between the truly and the falsely reported vulnerabilities.

In the next installment, we will examine more closely some of the strengths and weaknesses of these tools.

For more information about application vulnerability testing and software vulnerability testing, please visit


Sign in to comment