During a WAS scan, HTTP requests are sent over the wire from the WAS scanning engine to the web application server. For the scanner to crawl and test the web application that you would like to scan, the scanner has to make various requests to collect the links and then test the links in order to check for various vulnerabilities. The requests the scanner makes to collect and test the links of the web application constitute the HTTP request.
Good to Know |
|
Then you can increase the intensity if you determine that there is minimal impact. You can measure impact by reviewing the web access logs and comparing the volume of logged entries with the WAS scan at various intensity settings. |
|
WAS scanning is highly automated and the interpretation of results is almost instantaneous. Even the Lowest scan intensity setting moves very quickly. If the web application has only two pages and two easy selections, then users may be able to move as fast as the scanner at Lowest intensity with a short pause between requests. If the application has 20 input fields per page on average, the scanner will probably work 5 to 15 times faster than a user because it can populate the fields instantly without pausing to think. At higher intensity settings the scan would be even faster. |
|
WAS tracks average response time from the web application during scanning. When WAS detects at trend showing the average response time is becoming slower (response time is increasing), it will slow down the requests, regardless of the scan intensity setting. |
|
For WAS scans it's not possible to limit the number of packets that are sent. |
Pre-defined scan intensity settings |
Maximum - Scan performance is configured to finish in the fastest time possible. Important This setting is recommended for internal scans (web application inside your LAN) and high performance, public web sites. Scans may be faster to complete but may overload your network, web server or database. Scanning a web application with limited resources may result in an unresponsive host or web application. How many requests?How many requests? 10 simultaneous HTTP requests with 0 artificial sleep time introduced between each request. So what this means is that a maximum of 10 requests can be on the wire at any given time. Now keep in mind that there is network delay in both the request and response, plus any delay induced by the scanner for processing the response. |
High - Scan performance is optimized for high bandwidth use. How many requests?How many requests? 7 simultaneous HTTP requests with 0 artificial sleep time introduced. |
Medium - Scan performance is optimized for medium bandwidth use. How many requests?How many requests? 5 simultaneous HTTP requests with 0 artificial sleep time introduced. |
Low - Scan performance is optimized for low bandwidth use. How many requests?How many requests? 2 simultaneous HTTP requests with 0 artificial sleep time introduced. |
Lowest - Scan performance is optimized for the lowest possible bandwidth use. How many requests?How many requests? 1 simultaneous HTTP request with 0 artificial sleep time introduced. |
|
Maximum |
High |
Medium |
Low |
Lowest |
Number of HTTP threads used to scan each host (applies to vulnerability scan only) |
10 |
7 |
5 |
2 |
1 |
Delay between requests |
0.0 |
0.0 |
0.0 |
0.0 |
0.0 |
The maximum number of requests that WAS can have live on the wire is 10 requests. This means that a single request can only spend 25 milliseconds between any network delay, target delays in processing the request and generating a response, as well as any processing of the response that occurs within WAS.
Using a tool like http://tools.pingdom.com to measure the time it takes to load a page, you will find that even sites like https://www.google.com, which are highly optimized, take over 700 milliseconds to fully load due to the different analytic packages that are also being loaded by this single page.