Netsparker 5.3 – Scan Performance Upgrades

Netsparker can now find vulnerabilities significantly faster (up to 150%). This blog post explains these latest, significant performance upgrades, using some real world benchmarks.

Scan Performance in Netsparker Standard

Prior to the 5.3 release, Netsparker Standard ran six concurrent activities by default to perform tasks for each activity type, such as crawling and attacking for example. Users were able to control the number of concurrent activities using the slider on the right-hand side of the Progress pane in the Scan Summary Dashboard.

The number of concurrent activities could also be controlled using the Concurrent Connections slider in the Scan Policy Editor dialog.

Along with controlling the concurrent activities count, these same sliders could also be used as a Concurrent Connection setting. This determined how many Transmission Control Protocol (TCP) connections would be kept open while conducting requests to the target website.

What Are The New Performance Upgrades in 5.3?

With the 5.3 release, these sliders have been changed to a new setting, Requests per second (RPS). This is the throughput of the requests sent per second. The Concurrent Connection setting has been moved into the Scan Policy Editor dialog. This is what the Requests per second setting looks like in the Progress pane.

This is what it looks like in the Scan Policy Editor dialog.

The number of concurrent activities is now controlled dynamically throughout the scan, as Netsparker depends on the RPS values in each timeframe.

How Do The Performance Changes Work?

Prior to these changes, there would have been times where activities were waiting for each other to continue executing the scan.

Let's look at an example, illustrated below.

One good example involves DOM simulation tasks. To be able to keep the CPU and Memory usage low, a maximum of three concurrent DOM simulations (illustrated in t0 in the diagram) are conducted at any given time. If there were already three active DOM simulations, a request was sent from an activity to check for an XSS vulnerability would occupy a task slot, remain static and wait its turn. So, if there were three active and three inactive XSS tasks at time-zero (t0), only three of them would actually be active.

If an XSS activity finishes at t1, as illustrated, one of the inactive XSS activities will now be allowed to continue executing. Since the total number of running activities is now five, an SQL Injection would be accepted to run as the sixth activity at t2.

With the new performance changes, activities that line up for DOM simulation, or some other task that limits the concurrent execution, are now considered to be in a 'Paused' state. (See the yellow elements illustrated in the screenshot.) Instead of holding an unnecessary activity slot, Netsparker Standard will now allow the execution of other tasks in the waiting line as shown at t2.

• At t3, an XSS activity and the SQL Injection activity finishes. Now, one of the paused XSS activities can take the place of the finished XSS activity. Meanwhile, another activity from the activity queue is allowed to run for the other empty slot, as only three XSS activities can be active at a time.
• At t4, all activity slots are filled with active tasks, while two XSS activities are paused.

As well as these changes in activity queuing, Netsparker will now dynamically allow more tasks to run than the former default limit of six. This is another way that the performance improvements will keep the number of activities high enough to reach the required RPS value.

Do The Performance Upgrades Increase the Scan Speed?

Netsparker ran benchmark tests on both our test sites: http://php.testsparker.com and http://aspnet.testsparker.com, with Netsparker Standard 5.1, 5.2 and 5.3. Results are shown in average Scan Durations, taken from three different scans performed with default configurations.

The performance changes affect some websites more than others. Websites with large amounts of content, or large numbers of CSRF token uses, are more likely to benefit more from the performance improvements as we observed with the aspnet test site.

Scan Durations may vary based on Netsparker configurations and server loads. But our benchmark tests demonstrate a performance gain in scan speed that is very significant, ranging from 27-55%.

We know that these latest upgrades in the Netsparker Standard 5.3 release will mean faster scans, leading to more efficient security teams and therefore increasingly secure web applications.