Web application scanners often fail crawling

tate@ClearNetSec.com (Tate Hansen) — Sun, 05 Feb 2006 23:37:00 -0700

I attended a webinar Friday hosted by Watchfire which covered their web application scanner titled AppScan 6.0. The two big competitors I've run across in this space are Watchfire (formerly Sanctum) and SPI Dynamics. SPI Dynamics' web application scanner is titled WebInspect.

These scanners are great at capturing all the low-hanging fruit (i.e. vulnerabilities) if they can successfully crawl the target website. The problem, one the can cause a consultant considerable pain, is when you hit a site which uses technology that 'builds' URLs dynamically (e.g. JavaScript).

A JavaScript Example:
<script language="JavaScript">
function goToPage(element_name) {
  window.location = "http://www.mysite.com?tracking=" + getelementbyname(element_name).value;
}
</script>

As you can read above, the complete URL is generated using the value of a variable.

Let's take a quick look at a recent feature comparison from a September 2005 review of web application scanners by Secure Enterprise (link to the article)

If you look at the chart, it says all three of these scanners perform JavaScript parsing. Have you ever wondered why they don't seem to discover all the possible links in a web application? There is kind of a trick word here; can you guess which it is? It is the word 'parsing'. This is the word which makes us think these scanners can blaze through dynamic web applications. What they really mean by this is they can search through all the code and locate static URL paths like http://www.mysite.com. But, if the target site builds their entire menu system, or navigation, or forms, or whatever via JavaScript (or VBScript), then you are likely out of luck. Execution is what is needed, not just parsing. The scanner must execute code (e.g. window.location = "http://www.mysite.com?tracking=" + getelementbyname(element_name).value;) to generate all the potentially valid URL paths within an application.

Now all of these web application scanners support a work-around - what do you think that is? Here is a hint: You better have an excellent idea of how the site works and what all the application can do. The work-around is you must crawl the entire site for the scanner. No problem you say? Well, that may be true, but our experience often results in pain. Like the time we were covering for another consultant and realized we had to manually enumerate one of the largest web-based business performance management (BPM) systems on the market in two days. It was one of those types of experiences you grow stronger from.

So, if you are unfamiliar with all the different views a web application can generate and you are counting on a commericial web application scanner to do most of the heavy lifting, then be cautious. The time it would take to really do a good job may easily be 10x longer than you estimated.

Note: To be fair, WatchFire did say in their webinar they would be adding execution capabilities in their next release in 9 to 12 months. It'll be interesting to see how much they execute.

Update 2/22/2006: The release notes for the new WebInspect version 5.8 says: "Support for Advanced Asynchronous JavaScript and XML (AJAX) Applications. Improvements to the JavaScript and Audit engines now allow WebInspect to crawl and audit AJAX-based applications."

ClearNet Security: Tag vulnarability

Web application scanners often fail crawling