How many requests will I see?
Customers are often interested in predicting and forecasting load or traffic seen against their website or service by the AppCheck scanner during testing. This is most frequently motivated by the need to ensure service and operations stability, and to satisfy the requirements of change management for forecasting load, or of capacity management in ensuring that the scans do not cause an outage.
Customers will most frequently be looking for a quantitative metric such as a given number of requests (total) or requests/second (rate). AppCheck does not provide absolute predictive numbers for either of these metrics: rather, this article explains why such numbers can vary, while explaining in detail how the scanner operates.
How Scanning Works and why request volume and rate can vary
AppCheck is highly configurable. Foremost, scanning can be configured at a high level by basing a scan upon one of a number of pre-configured templates. These templates define various scan configuration options including the specific scan plugins that are to be utilised during the scan, as well as the options selected for each plugin. Multiplicatively, there are millions of potential scan configurations, and scan duration can therefore vary by several orders of magnitude.
Additionally, it is possible to configure the scan intensity qualitatively by defining the number of concurrent scan threads.
Finally, the initial crawl phase of a scan may return an initially unknown number of scan entry points for each target, as well as further variance such as number of parameters for each entry point, each of which can be fuzzed. This is explained in further detail in our article at https://appcheck.zendesk.com/hc/en-us/articles/360022904274-Why-does-AppCheck-NG-make-so-many-HTTP-request-to-my-site-or-domain-
Controlling scan intensity/request rate
AppCheck operates a threaded request model, where one or more threads execute in parallel to perform scanning. By configuring the number of threads used in a scan, some qualitative control can be exerted over the scanning intensity in terms of the request rate used during scanning.
It is not possible to tie number of configured threads to exact requests/second seen during scanning, and is a relative or qualitative measure only.
By default a scan will use 10 threads: this means that AppCheck by default will create up to 10 concurrent connections to the scan target. This can be reduced to a minimum intensity of 1 on configuration, which will both reduce scan intensity but also inversely increase scan execution time.
It is worth noting that a scan's request rate is based upon the scan connections completing their assigned requests and analysing the returned responses and so the number of actually active requests in flight at a given moment is variant depending upon response time of the remote server and analysis time within the scanner.
Typically, web applications are designed to handle many thousands of concurrent connections and so a thread count of 10 should be well tolerated. If the remote server has existing performance issues that may be impacted by the scan then you can elect to pre-emptively configure the thread count to a lower value.
Are volumetric attacks used?
It is important to note that AppCheck at no time performs volumetric testing or load testing. All testing performed is therefore entirely functional as outlined above and each request seen is specifically made with a selected and targeted intent of testing for a given vulnerability. You can see more technical information on the types of scanning performed at https://appcheck.zendesk.com/hc/en-us/articles/115001870134-3-Types-of-Scanning-Port-Scanning-Web-Application-Scanning-and-Infrastructure-Scanning
See also:
The following related articles may also assist on this topic:
Comments
0 comments
Please sign in to leave a comment.