Plugin Highlight - Web Application Tests : Load Estimation (ID 33817)

Web application testing with automated scanners can be tricky business. While testing various target web servers, I found that some targets seemed to finish in a relatively short period, while others took days - or never seemed to complete at all. This occurred despite the fact that I often used identical test settings and relatively conservative scan settings for the different targets.

While troubleshooting this apparent disparity, I came across a useful plugin that helped me see a little of what was going on in the background. The plugin is Nessus Plugin ID 33817 “Web Application Tests : Load Estimation”.

Here is the plugin synopsis/description:

Synopsis

Load estimation for web application tests.

Description

This script computes the maximum number of requests that would be done by the generic web tests, depending on miscellaneous options. It does not perform any test by itself.

The results can be used to estimate the duration of these tests, or the complexity of additional manual tests.Note that the script does not try to compute this duration based on external factors such as the network and web servers loads.

A useful trick that I found was running two scans for each web application test. In the first scan, I would enable only plugin 33817, along with some related settings described in the table below, so I could get a feel for the best possible scan settings along with the approximate time required for the actual scan. After running the estimation scan, I could then run the full scan with reasonable expectation of the amount of time it would take.

Here’s sample output from a typical “Load Estimation” scan of a web server running Mutillidae:

Plugin Output

Here are the estimated number of requests in miscellaneous modes for the GET method only:

[Single / Some Pairs / All Pairs / Some Combinations / All Combinations]

arbitrary command execution  :  S=5350       SP=487550     AP=16772900   SC=>2G       AC=>2G

format string                :  S=428        SP=39004      AP=1341832    SC=>2G       AC=>2G

header injection             :  S=428        SP=39004      AP=1341832    SC=>2G       AC=>2G

SSI injection                :  S=642        SP=58506      AP=2012748    SC=>2G       AC=>2G

unseen parameters            :  S=7490       SP=682570     AP=23482060   SC=>2G       AC=>2G

RS                           :  S=1712       SP=156016     AP=5367328    SC=>2G       AC=>2G

blind SQL injection          :  S=2568       SP=234024     AP=8050992    SC=>2G       AC=>2G

SQL injection                :  S=5778       SP=526554     AP=18114732   SC=>2G       AC=>2G

directory traversal (extended test):  S=10272      SP=936096     AP=32203968   SC=>2G       AC=>2G

directory traversal          :  S=6206       SP=565558     AP=19456564   SC=>2G       AC=>2G

directory traversal (write access):  S=428        SP=39004      AP=1341832    SC=>2G       AC=>2G

local file inclusion         :  S=856        SP=78008      AP=2683664    SC=>2G       AC=>2G

web code injection           :  S=214        SP=19502      AP=670916     SC=>2G       AC=>2G

DOM XSS                      :  S=214        SP=19502      AP=670916     SC=>2G       AC=>2G

persistent XSS               :  S=856        SP=78008      AP=2683664    SC=>2G       AC=>2G

cross-site scripting (quick test):  S=4280       SP=390040     AP=13418320   SC=>2G       AC=>2G

XML injection                :  S=214        SP=19502      AP=670916     SC=>2G       AC=>2G

Here are the estimated number of requests in miscellaneous modes for both methods (GET & POST):

[Single / Some Pairs / All Pairs / Some Combinations / All Combinations]

arbitrary command execution  :  S=245000     SP=27754600   AP=966198400  SC=>2G       AC=>2G

format string                :  S=19600      SP=2220368    AP=77295872   SC=>2G       AC=>2G

header injection             :  S=19600      SP=2220368    AP=77295872   SC=>2G       AC=>2G

SSI injection                :  S=29400      SP=3330552    AP=115943808  SC=>2G       AC=>2G

unseen parameters            :  S=343000     SP=38856440   AP=1352677760  SC=>2G       AC=>2G

RS                           :  S=78400      SP=8881472    AP=309183488  SC=>2G       AC=>2G

blind SQL injection          :  S=117600     SP=13322208   AP=463775232  SC=>2G       AC=>2G

SQL injection                :  S=264600     SP=29974968   AP=1043494272  SC=>2G       AC=>2G

directory traversal (extended test):  S=470400     SP=53288832   AP=1855100928  SC=>2G       AC=>2G

directory traversal          :  S=284200     SP=32195336   AP=1120790144  SC=>2G       AC=>2G

directory traversal (write access):  S=19600      SP=2220368    AP=77295872   SC=>2G       AC=>2G

local file inclusion         :  S=39200      SP=4440736    AP=154591744  SC=>2G       AC=>2G

web code injection           :  S=9800       SP=1110184    AP=38647936   SC=>2G       AC=>2G

DOM XSS                      :  S=9800       SP=1110184    AP=38647936   SC=>2G       AC=>2G

persistent XSS               :  S=39200      SP=4440736    AP=154591744  SC=>2G       AC=>2G

cross-site scripting (quick test):  S=196000     SP=22203680   AP=772958720  SC=>2G       AC=>2G

XML injection                :  S=9800       SP=1110184    AP=38647936   SC=>2G       AC=>2G

Your mode : single, GET only, thorough tests.

As noted in the output, this plugin doesn’t actually perform any vulnerability checks. Instead, it takes the “Web mirroring (10662)” plugin results in conjunction with other web application scan settings (such as thorough tests and experimental scripts) and performs a calculation of the maximum number of checks (GET or GET/POST requests) that would be required if the scan was actually going to be performed.

In the output above, S (Single) and SP (Some Pairs) generally had a reasonable number of checks, while the SC (Some Combinations) and AC (All Combinations) each ran approximately two billion checks per category. AP (All Pairs) was somewhere in the middle, ranging from 670 thousand to almost 2 billion checks per category.

Based on this output, I would likely choose “Single” or “Some Pairs” if I needed a relatively quick web application scan or “All Pairs” if I had more time to let the scan complete (about 24 hours in this case). Running scans in either “Some Combinations” or “All Combinations” mode is simply not practical based on the number of checks per category. Further tweaking of the web mirroring or web application test settings specified in the table below could reduce the number of checks. The table below lists both required and optional settings for a “Load Estimation” scan.

Web App Load Estimation Settings	Description
Required Settings – must be set for load estimation output to work properly
Web Application Test Settings (Plugin 3941)	Plugins -> Settings
Enable web application tests checkbox	Preferences -> Web Application Tests Settings
Web Application Tests: Load Estimation (Plugin 33817)	Plugins -> CGI abuses category
Web mirroring (Plugin 10662)	Plugins -> Web Servers. Configure the desired web mirroring settings in the Preferences -> Web mirroring section. For more guidance, see this blog or the Nessus documentation available on the Tenable Support Portal.
Test SSL based services	Preferences -> Service Detection. Set this to “All” where your web application listens over SSL on non-standard ports.
Optional Settings – not required, but could affect the load estimation output
Thorough Tests	Preferences -> Global variable settings
Enable Experimental Scripts	Preferences -> Global variable settings
Test Embedded Web Servers	Preferences -> Web Application Tests Settings

In conclusion, it makes sense to analyze and optimize your Nessus settings before kicking off any web application scan. Knowing what a scan is going to do before the scan actually occurs is the key to this process. The “Load Estimation” plugin will help you on your path to web application testing “Zen”.