Web Application Scanners Rolling Review Ends - Only One Scanner Was Capable of Scanning the AJAX web Application....You Guessed It - IBM Rational AppScan!

(Subtitle: "We Support AJAX")

Jordan Wiens just concluded the Web Application Scanners Rolling Review, which had been going on for a few months now. This rolling review was very different from past attempts, as it required scanners to be able to scan real-world AJAX web applications, and it was done extremely professionally, while putting an emphasis on scanners' capabilities, rather than on eye-candy features alone.

I must admit that I am very proud today - AppScan, a product that I have been working on for 7 years now, was the only product that managed to scan the application properly, and received great compliments from Jordan.

Here are a few excerpts from AppScan's review, and some final words:

With the exception of IBM's AppScan, automated Web application scanners are simply not yet up to the task of finding security flaws in Ajax code. And it's not like we made it hard on them

 

AppScan's review subtitle:

WatchFire Blazes Past Field.

AppScan was the only product in this Rolling Review to handle Ajax, and it did it without the gotchas that plagued rivals. Now that's hot.

And...

Not only is AppScan the most mature Web application vulnerability scanner on the market, developed in 2000 as a companion to Sanctum's AppShield Web application firewall, it's now owned by one of the most well-known names in computing, IBM, as a result of Big Blue's July acquisition of WatchFire. In the context of this Rolling Review, we weren't sure AppScan's experience would be enough: The Ajax applications we've been feeding our scanners have proved troublesome, even for long-established products. Fortunately for IBM, AppScan looks like a sound investment. It impressed us with its ease of use, advanced functionality and reliability and was the most successful so far at traversing our Ajax applications.

A few words about AppScan eXtensions (and in particular PyScan):

For advanced users, AppScan's built-in utilities are nearly on par with the rich suite of tools integrated into WebInspect. Additionally, since version 7.5, AppScan has taken a cue from the popular Firefox browser by allowing users to develop extensions that can integrate into the product. These add-ons reflect the growing popularity of open-source products and communities. In fact, one sample extension is a complete development environment in itself, integrating the popular open-source scripting language Python with the core engine in AppScan.

Much of the value in a scanner stems not just from how accurate it is, or how flexible its reports are, but from how seamlessly it can be incorporated into your existing workflow to provide meaningful and actionable data throughout the development process. Exposing the product via extensions is a great way to allow customers to use AppScan in a way that best fits their particular needs or environment. Take the Pyscan module. An organization might implement custom scans of different branches of an application under development by automatically scripting both scanning and reporting as code is forked for reuse or checked into a source-code repository. Having the simplicity and popularity of Python tied to the scanning engine that makes AppScan tick is a powerful combination. Creative types will discover a variety of potential uses.

Look, I can sit here, and start lashing back at people who keep saying that automated web application scanners are *pure evil*, but as Master Yoda once said:

Fear is the path to the dark side. Fear leads to anger. Anger leads to hate, and Hate leads to suffering

I think Jordan's Rolling Review proved an important point.... AppScan Rocks!

 

 

** Disclaimer: the author of this blog post does not believe that you can completely secure a web application by only running an automated tool. You can read my thoughts on this subject in my award winning blog post Man vs. Machine

Comments

[Ory Segal]

Romain,

According to what you've written, the code in the else block, will never get executed, if your code only calls foo() without any arguments. In that case, any instrumentation of the code, will never reach that part of the code, and hence will miss that link.

BUT - since AppScan has some additional heuristics (e.g. Static JS parsing), it might identify that URL, although I'm not sure myxhr() will be parsed, as it seems to be your own wrapper around XHR, right?

Oh well, nothing is perfect :-)

[dre]

@Ory: Jeremiah and I were recently talking on his blog about "why crawling matters" where I said, "you have situations like GMail/GDocs where you're editing HTML or other content inside the browser. i'd be interested to hear how any web application security scanner solves this sort of problem"

and his response:

"I'd be the first one to tell you that a certain percentage of websites, these examples in particular, just can't be scanned with today's technology. In fact you'd spend more time fighting with your scanner than doing the whole thing by hand. For the sake of our service and business model, we do have to pass on some of these from time to time because there is no way to provide good continuous assessments on them".

I figure that I would give you a chance to respond to this problem and encourage you to join that conversation.

[Ory Segal]

Hi Dre,

Sure - there are all sorts of web applications that are built in such a way that will make life very miserable for an automated crawler. But - as I've said before, I think our research is producing interesting technologies to cope with such technologies, and unlike Jeremiah, we don't give up so easily...

[kingthorin]

"...how do you know the scanner is actually spidering successfully?"

This requires human knowledge of the application. You compare the URL list or site map to your (or the SMEs) knowledge of the site/app.