Scan Sequence/Steps

When an AppCheck scan is launched, it will step through the following stages in a sequenced manner.

Step One - "Crawling"

In the first step, a browser-based "crawler" navigates the target site or app in a "human-like fashion", using authentication if configured. Crawling involves essentially exploring and building a "map" of a target site, by following hyperlinks on pages from the "starting page" that is set for the scan - if no specific path is set, then the scanner will start navigating at the root "/". The aim here is to produce a map of the website and find out its extent. This should be a very low-activity exercise since the scanner uses 1 browser instance that simulates "clicks" on links, submits forms and interacts with other navigational components via the presented interface. It’s a slow process since the browser waits for background activity to settle before moving on to the next component to avoid missing something which may load synchronously in the background.

It is also worth bearing in mind that during this early phase, the scanner is in no way checking for vulnerabilities, it is simply preparing the way for later scan steps. This means that it is perfectly normal on a large site for a scan to run for some time initially without any vulnerabilities being found. This indicates simply that the scan is significant in size and taking some time to crawl and does not indicate that no vulnerabilities are present.

Step Two - "Page Scraping"

AppCheck will then use a "page scraping" crawler to perform less sophisticated crawling (not making use of a full browser instance and rendering the presented user interface as in the former step) whereby the raw HTML (code) of each page is automatically "scraped" to find links and forms etc in order to discover components. This crawler is less sophisticated but helps discover components that are within the page but aren’t rendered to the user so are invisible to the more sophisticated browser-based crawler.

Step Three - "Forced Browsing" and "Discovery"

In step three “forced browsing”  and search engine-based discovery is performed. In the forced browsing discovery, the scanner will attempt to find areas of the targeted site that are not linked to from other pages but can only be accessed by direct navigation (i.e. requested directly). It will do this by attempting to guess the location of common components such as admin interfaces, and components that may have security flaws but aren’t linked within the application - for example it may be reasonable to check for "hidden" unlinked pages at paths such as "/admin" or "/login" etc. The process iterates through lists of potential directory and file names and tries them against the server. This process will send requests at a higher rate than other stages but should be hitting "404 not found" responses from the target server for the vast majority of requests. A request for a non-existent file should not normally be processed in back end systems or any further than the front end web server: therefore the processing overhead and bandwidth used should be minimal.

Step Four - "Attack"

Components identified in the previous stages are then passed into the "attack" phase. You can see signatures for the unique components in the “Mapped Attack Surface” finding. (See https://appcheck.zendesk.com/hc/en-us/articles/360025620393-How-can-I-see-a-list-of-which-paths-or-URLs-AppCheck-has-scanned-crawled-and-attacked-for-my-web-application- for more details).

This phase is where the main testing process begins, and only at this point may your scan results begin to populate with vulnerabilities that are discovered. Each query string parameter, form, JSON body and in some cases HTTP header is subject to testing. For each test, the value within the parameter is changed to include a test case and then resubmitted to the application in a process known as "fuzzing", which may generate very large numbers of HTTP requests to the target (as many as millions). Please see the following two articles for further details on this point:

• https://appcheck.zendesk.com/hc/en-us/articles/360022904274-Why-does-AppCheck-make-so-many-HTTP-request-to-my-site-or-domain-
• https://appcheck.zendesk.com/hc/en-us/articles/360017595258-How-many-HTTP-requests-or-how-much-traffic-does-AppCheck-make-when-scanning-my-website-or-service- 

The response to each specific request variant is then analysed by the scanner to determine if the test case warrants further investigation based on the response. If so, then further tests are conducted to determine if there is a security flaw. 

The "Attack Phase" - Further Details

AppCheck scans perform between 3 and 6 primary (major) scan phases depending on intensity of scan configured.

These are, by payload type:

Payloads

• Light scans = 1 phase
• Medium scans (Light + XSS2 + Path Traversal)  = 3 phases
• Heavier scans (Light + XSS2 + Path Traversal +SQLi) = 4 phases
• Heavy scans (Light + XSS2 + Path Traversal +SQLi + RCE1 +RCE2)  = 6 phases

For each major scan phase, there are between 1 and 3 sub-phases, again dependent upon configured scan intensity and options. There are bsaed on the targets tested for the payload vulnerability being probed for:

Targets

1. querystring
2. form fields
3. common headers

Combinatorially, you can therefore have up to 6 payload types tested against each of 3 Target types, leading to up to 18 sub-phases of scanning overall.

Earlier phases are lighter and take the lesser amount of time to perform than later scan phases.

How To Configure Scan Type

The scan types can be configured in Settings -> Web Application Scanner Settings -> Plugins