By finding app vulnerabilities during development, AppScan DE prevents big trouble later

Sanctum's AppScan is a tool for testing a Web application's security. Read the product documentation, and it's difficult to avoid the impression that AppScan is a sort of "automated hacker." That’s true in at least one sense: AppScan applies the same type of techniques as a hacker would use to infiltrate your site. Fortunately, AppScan is a benign mechanism, not a malevolent person, because it does its job very well.

AppScan DE (Developer’s Edition) explores a Web site, searches for potential security loopholes, "attacks" the site based on knowledge gathered during the search, and reports its successes and failures. Developers can then use AppScan's information to shore up the discovered security leaks before they go live.

A Benign Mechanism

While AppScan can stand alone, it is available in versions that integrate with various integrated development environments, including Visual Studio .Net, Visual Basic 6.0, IBM WebSphere Application Developer Studio 5.0, Eclipse, and Borland JBuilder. I ran the stand-alone version and was pleased by how quickly I could set it up and turn it loose on my sample application.

The AppScan GUI is arranged so that the four phases of its operation -- Setup, Explore, Test, and Report -- appear as tabs arranged vertically on the left side of the window. Select one of the tabs, and the other tabs slide apart to reveal sub-tabs associated with a step within each phase.

This arrangement provides a good mix of guided hand-holding and unchaperoned navigation. Your first time through a session, you follow the tabs from top to bottom, filling in parameters and executing functions. Once you've gotten the hang of it, you can tweak and refine that same session by stepping backward or forward and tuning and rerunning.

In the Setup phase, you provide the information AppScan needs to prowl your target site: the starting URL, how many links "deep" the scan will delve, which URLs to avoid, and more. You can also fill in all the data for the input fields, selection boxes, and so on that AppScan will encounter as it prowls the site. (This is not a required step. When AppScan does its exploration of the site, it tracks all the entry fields for which it has no input information and requests the information afterward.)

The next phase, Explore, is the scan itself. There are two kinds of scans: automatic and interactive. Automatic is the more comprehensive, as AppScan crawls mechanically through the site like a living algorithm climbing a tree structure, bypassing only those links you previously identified.

In an interactive scan, AppScan watches as you click through the site, recording and remembering the links you visit, the fields you fill in, and so on. Interactive scanning is therefore more constrained than automatic, but since you control the process, you can quickly focus on what you think might be a trouble spot rather than wait for AppScan to find it. One of AppScan's bits of cleverness is that you can flip easily between automatic and interactive scans, as the circumstance requires.

After exploration, AppScan mulls over the gathered information and builds a database of known or suspected site vulnerabilities. In short, AppScan draws up its attack plan and assembles its weapons (dubbed "mutated" requests), legitimate HTTP requests modified to test specific weaknesses.

The actual attack is more politely called the Test phase. AppScan sends its volley of mutated requests to the site and records the results. Even the attack can be tweaked by the developer, literally fine-tuning the assault so that only specific mutated requests are sent to look for one vulnerability in particular. In addition, AppScan identifies those requests that might actually crash the system and gives you the option of skipping them.

Results can be filtered based on a variety of criteria divided by severity, such as whether the test query reviewed a vulnerability that was certain, highly suspicious, suspicious, or not vulnerable. I found the filtering feature particularly useful, allowing me to slice away those categories that simply were not applicable to my testing.

What's important here isn't so much that AppScan employs any heretofore unknown kinds of attacks; in fact, they're all pretty well understood. What is important is that AppScan automates the process of locating vulnerabilities and testing those attacks on a target site. AppScan DE's value is not the novelty of its "hacking," but its speed and thoroughness.

A Grim Job

Working with AppScan DE is relatively uncomplicated thanks to the tab-navigation interface. I was initially confused by the way that the tool kept all form input data global, rather than associating each with its specific URL. However, a discussion with Sanctum convinced me that AppScan trades that kind of excruciating precision for ease of use and emerges the better for it.

You may also run AppScan from the command line. This allows you to incorporate the tool into script-driven build processes to run automated sessions after each build of your application so that security problems can be located -- and, hopefully, tracked and fixed -- before they hit the real world.

While using the system is straightforward, AppScan DE's licensing is understandably tricky. Licenses are typically granted for scanning a specific IP address, or a range of nonroutable addresses. Anything beyond that requires special licensing from Sanctum. (Of course, scanning a Web site on your local system is always permitted.)

In addition, for accountability tracking, AppScan DE binds your license to your system's IP address and MAC address, and embeds those addresses in HTTP headers so that servers logging HTTP transactions deposit the identifying information in system logs. That allows enterprise managers to track precisely who is using AppScan to explore a given server, just in case someone tries to use the tool, er, “inappropriately.”

While one might be tempted to judge AppScan DE on the cleverness of its attacks, doing so is missing the product's more important characteristic: comprehensiveness. This became clear to me when I turned AppScan loose on a small, three-servlet, MySQL-based Web application I had been using at work. AppScan turned up no vulnerabilities, and while I would have been amazed if it had, I was still more amazed by the sheer number of individual attacks the tool attempted -- well over 900.

After pondering this for a moment, I realized how many valid and unique variations of HTTP requests were possible with just my simple application, then shuddered at the thought of how many would exist for a complex enterprise Web site. AppScan DE’s thoroughness will be much appreciated by any IT security team.