The challenge of parameter-based navigation sites

An explanation of the configuration changes needed to scan a site in which the navigation is parameter-based.

By default, AppScan has a Redundant Path Limit of 5 (the maximum number of time a request can be sent to the same URL, see Explore options view). In regular sites this prevents repeating tests unnecessarily. However, when site navigation is parameter-based, this low limit will effectively prevent AppScan® from scanning the site thoroughly, and a scan run using the Regular Scan template will discover and test hardly any of the site.

Increasing the Redundant Path Limit, or disabling it altogether, does not alone solve the problem. In fact it may throw AppScan® into an infinite loop, or at least create a scan with so many tests that AppScan® runs out of memory. There are two reasons for this:
  1. During the Explore stage, when hashing a request, AppScan® will include all the parameters and cookies it finds in the request. With the redundant path limit gone, all combinations of these values will be taken into consideration.

    Let's say for example that each page from a section of the site contains hundreds of links to a script that retrieves information from the database about an item available for sale. These links contain a parameter named item_id which is of no importance in generating new pages, and is used only to retrieve information about the item. AppScan® will end up requesting thousand of instances of this item info page unless item_id can be excluded from the hash.

  2. In the Test stage the problem becomes more severe. Let's say that a request contains two parameters par1 and par2, and AppScan® encounters four links that include these parameters:
    http: // site.com/content.aspx?par1=a&par2=c
http: // site.com/content.aspx?par1=a&par2=d
http: // site.com/content.aspx?par1=b&par2=c
http: // site.com/content.aspx?par1=b&par2=d

    If there are 400 tests applicable to each parameter, AppScan® will send 1600 tests in total (800 on par1 when par2=c and par2=d and 800 on par2 when par1=a and par1=b )! Therefore, in addition to excluding these parameters from the Explore hash, we must tell AppScan® to test each parameter only once: 400 tests on par1 and 400 tests on par2.

The principles derived from the above for scanning a site with parameter-based navigation are therefore:
  1. Explore stage: Ignore the values of all parameters except navigational parameters.
  2. Test stage: Do not create new tests when the value of a parameter changes, except for navigational parameters.

See also:

Sites that use parameter-based navigation

The Paramater-Based Navigation template