Sanctum's AppScan picks up where social engineering and firewalls leave off, helping to soothe your Web site's heebie-jeebies with solid security measures.

Security is the flip side of fear: It is fear of hackers that drives us to attempt to protect our vulnerable Internet-connected systems. Hardware and software vendors in the Internet security area are typically masters at taking advantage of this fear, and, of course, the greater our alarm, the less outrageous their five- and six-figure solutions seem. One systems integrator likes to repeat this line: "One percent of the general population are convicted criminals, so just look at the millions of Internet users and you do the math." This is a scare tactic, but an effective one. In the never-ending arms race of Internet security, where exploits and counter-exploits regularly leapfrog each other, how can we possibly keep up?

It's salutary to note how security is handled in the off-line world: Sometimes you can eliminate risks; sometimes you can only minimize them; and sometimes you just deal with occasional breaches. Once you stop worrying, you can start eliminating and mitigating risks.

Battening Down the Hatches
The first step in securing your company against Internet-borne risks is to set up a good firewall and to "harden" your systems to disallow all but necessary connections and activities. Unfortunately, we usually leave good old port 80 wide open on our Web server machines, and, for most companies, this ends up being the second biggest potential security hole. (The biggest potential security hole is typically the human security procedures that are subject to "social engineering.") Sanctum's AppScan picks up where the firewall leaves off, attempting to secure the content and applications within the Web server itself—by throwing everything but the kitchen sink at a Web app and then reporting profusely on the ensuing chaos.

AppScan installation is straightforward. Sanctum also ships a very useful example Web site ("Acme-Hackme Bank") to showcase the product's abilities. I wanted to point AppScan to one of our corporate sites, but a company representative wisely suggested that I start with a nonproduction site. I hereby emphatically pass along this advice, since the product was able to quickly bring down the Web site running on my test machine.

Stage and Substage
Scanning a Web site with AppScan proceeds in four stages: Setup, Explore, Test and Report. Each of these stages has two to four substages. Which stage and substage you are in is clearly indicated in a column on the left side of the application. The application's main window shows either stage-specific information or an embedded Internet Explorer window (for use in manually browsing your application). You can advance from one stage or substage to the next with Next and Previous buttons, or use icons to jump directly to any stage.

In the Setup stage, you specify the URL of your Web application. You can also save the scan session under a specified name, a useful feature for including AppScan in your regular test procedures. At this stage, you're given fairly fine-grained control of the scanning process via the Scan Settings dialog box. Explore Mode can be set to Manual, which enables you to browse your site by hand; or Automatic, in which you let AppScan crawl your site. You can also choose to have AppScan fill your forms with values you specify in a dialog box. You can specify the depth of an automatic crawl of your site, as well as which file types should be ignored. You can also declare which Web or app server you're running, have AppScan guess the server types, or leave the servers unspecified; this information is used to tailor the search for known vulnerabilities.

The Setup stage also includes a list of 11 vulnerabilities to check for, each of which can be optionally included in the scan. The list has such items as "Cross-site scripting," whereby Javascript snippets are included in form fields with the intent of having them run in subsequent pages. Other vulnerabilities include hidden field manipulation, "Forceful browsing," "Stealth commanding," buffer overflows and seven others. On the downside, although all five of the vulnerabilities I looked into seemed legitimate security concerns, the user manual was a little sketchy on the details about how a hacker would exploit them. However, for those vulnerabilities that actually show up in your app, a well-written, detailed description is shown in a test results page. One very useful feature of the product allows you to specify certain session-varying cookies or HTML fields as "transients" so that they can be reset from one test run to another, preventing your test runs from timing out. You can also choose to include or avoid "unsafe tests"—that is, those that can cause damage to a site. Because a group of settings can be complex, you can save them as "scan types" or simply use one of four predefined types, ranging from the completely automatic (Quick Scan) to the completely manual (Developer Scan).

In the Explore stage, you perform a combination of automatic crawling of the site and manual browsing (and typing). In this stage, you record which pages of your site should be included in the scan, how Web forms should be filled out, and the list of associated potential vulnerabilities. At the end of this stage, a results page shows statistics such as the number of links, the number of dynamic pages and the number of potential vulnerabilities found. You can drill down on each of these items for more information.

The Explore stage is really just a precursor to the Test stage, which actually runs the appropriate tests. Depending on the size and performance of your Web site, testing can take a long time to complete. As the tests run, a list of categories (forceful browsing, for example) is shown, along with a count that's incremented as each potential vulnerability is checked. Tests for the different categories are run in parallel threads. It would be nice to include AppScan in an automated nightly build-and-test procedure. Unfortunately, since the product runs only on Windows (but can be pointed at sites running on any platform) and there's currently no option to invoke AppScan from the command line, this would be difficult.

After testing is complete, statistics for the tests are shown broken down into categories of not vulnerable, suspicious, highly suspicious and vulnerable. You can drill down on each category to see a list of summary information. Drill down farther for a complete report of the type of vulnerability discovered, the exploit mechanism and a suggested solution. The Test stage also has a Content substage, which displays information useful for debugging security problems, such as the form data submitted to each dynamic page, cookie requests and responses, and comments (a potential source of inadvertent disclosure of information).

Judging a Book ...
Results from the tests flow into the Report stage, where you can produce handsome reports of the discovered vulnerabilities. You can filter out certain categories of vulnerabilities, remove specific items from the report and extensively customize its appearance. This reporting tool can be quite effective in convincing decision-makers that there are problems that need to be addressed.

Overall, this product does a good job of exposing known vulnerabilities in Web applications. With the caveat that no single tool can fully address Web security issues, this is a solid product that you should definitely consider including in your Web app toolbox. Many of the security exploits that the product simulates are widely known, but this isn't really drawback—the bad guys will usually try the easiest exploits first.

Article Link: Software Development (user registration required)