How fast is your automated web vulnerability scanner? This is most probably the most common question every penetration tester would ask when evaluating an automated scanner. Time is money and for businesses it is very important that a security professional or anyone employed to ensure the security of websites and web applications finishes the penetration tests in the shortest time possible.
There are many factors that affect the duration of a complete automated web application vulnerability scan. And apart from the automated vulnerability scan itself, there are several other factors that determine how long a penetration test can take. For example how long does it take the user to configure the web scanner? How many post scan tasks are required to fully complete the penetration test, such as verifying the scanner findings?
When you look at it from a business owner point of view, all these facts matter; it is not just about the scanner’s speed but it is about the whole picture. In this article we will look into each and every factor that makes up a complete web security scan and what can affect the scan duration, or better the complete process of securing websites and web applications.
The complexity and size of the target web application play a major role. For example an automated web vulnerability scanner will take longer to scan a web application of 10 pages that has 10 inputs on each page rather than to scan a website of 1,000 pages that only has 20 inputs in total. The difference in scan duration is because the scanner attacks inputs, or attack surfaces and static pages do not have any attack surfaces, hence are ignored.
Apart from visible inputs, a website can also have custom 404 error pages implemented, URL rewrite rules and uses DOM. Depending on all these factors and how they are configured the automated scan duration can vary.
Netsparker provides the user the ability to create new Scan Policies and select which type of web application vulnerability checks should be run during an automated security scan. As an example, the scanner will require much less time to finish an automated security scan that scans the target website for SQL injections only, as opposed to scanning it for a wider variety of vulnerability checks.
You should also use the Scan Policies and ensure that the scanner is not performing any redundant checks. For example if your web application is running on PHP and using Apache and MySQL, you can safely disable all ASP.NET, IIS and Microsoft SQL Server security checks from the scan. By doing so you can drastically decrease the scan duration time.
Because of the nature and complexity of vulnerability checks, some vulnerability checks take much longer to complete than others. For example the vulnerability check for DOM based cross-site scripting can take quite a long time to complete because of the way the check is done.
Complimenting with the above points, the web server response time also plays a major role in the duration of an automated web security scan. For instance the number of HTTP requests a scanner sends during an automated scan depends on the complexity and size of the target website and also on the type of vulnerability checks configured. During a typical web security scan the scanner sends thousands of HTTP requests. If the web server response time is very high, i.e. the web server takes a considerable amount of time to respond to the requests being sent by the scanner, then the scan duration is prolonged.
If the web server response time is very high, check the web server’s CPU and memory usage, the load on the database and several other counters that might be contributing to high web server response time.
Irrelevant of how many HTTP requests the automated web vulnerability scanner sends and how fast your web server responds to them, if the internet connection between the scanner and the target web application is slow, then the automated web security scan can take a considerable amount of time to complete.
If the internet connection is a problem, try to launch the security scan from a computer that is on the same network as the web server, thus eliminating a factor that might affect the scan duration.
Many users think that the duration of a web application vulnerability scan only depends on the speed of the scanner, but as we have just seen it depends on several other factors. Of course the speed of the automated security tool you are using will vary the scan duration but most probably it is the least affecting factor. For example Netsparker can be configured to send 25 concurrent HTTP requests to the target web server, but will the web server and web application handle such load?
Technically speaking 25 concurrent connections is like emulating 25 browsers. Though the scanner sends the HTTP requests automatically unlike real visitors, who typically take a longer period of time between one action and the other. So before configuring the number of concurrent connections in the web vulnerability scanner, confirm that the target web server and web application can handle it and that there is enough bandwidth to cater for it.
So far we have only looked into the technicalities of the factors that can affect the duration of an automated scan, but a complete web vulnerability scan is not just about the automated scan. To fully justify the investment a business has made the scan duration should be measured from when the user starts configuring the web vulnerability scanner till when he or she verifies the tool’s findings.
It is a well known fact that most security software is difficult to setup and run. For example because of the wide variety of different web applications being used today, sometimes it can take a considerable amount of time to configure the tool prior to launching a web vulnerability scan. Therefore when evaluating several different web vulnerability scanners, make sure that the one you go for is easy to use and can automate as much of the configuration process for you by auto fine tuning itself.
An easy to use web vulnerability scanner does not only mean you need less time to launch a web security scan, but also means that other people from different departments can use the software. For example if the software requires a lot of details about the target web application, in that case most probably only the developers can use it. But if the software is easy to use and automates most of the configurational tasks, even software testers or quality assurance team members can use the software, thus allowing developers to focus on development and remediation of security issues and enables your business to reduce the costs of securing web applications.
Most probably this is the most lengthy post scan procedure; verifying the vulnerabilities that an automated web vulnerability scanner reported. Apart from being a lengthy and daunting task, manually verifying web vulnerabilities requires a lot of knowledge and skills. Sometimes even the most seasoned web security professionals cannot manually verify some of the scanner’s findings.
The good news is that Netsparker automatically verifies detected vulnerabilities by automatically exploiting them in a safe and read only manner; therefore you can almost eliminating this task and reduce the time you require to complete a web vulnerability scan. There are also several other advantages you can benefit from when using a false positive free web vulnerability scanner because false positives have a very negative impact on web application security.
Last but not least, the computer hardware where you are running the scanner also affects the scan duration and speed. A web vulnerability scanner needs processor power and consumes memory to operate properly, like all other software. Web vulnerability scanners do millions of calculations and store a lot of temporary data during a normal web application security scan (depending on the size of the target website), therefore the more processor power you have, and the more memory you have the faster the security scanner can execute the calculations.
In terms of memory, 2 GB RAM is barely enough to run a modern web vulnerability scanner. 4GB should be much better especially if you are scanning large web applications. In terms of processor, the faster the processor is, the more cores the processor has the faster the web vulnerability scanner can do its calculations. A modern dual core processor should suffice, but like with everything else, the bigger the better.
As we have just seen there are many different factors that might be affecting the duration of an automated web vulnerability scan and while some of them are obvious, most of them are not. Also when evaluating web vulnerability scanners do not just look at it from the technical or developer point of view, look at it from a business owner point of view so you can choose the scanner with the best return of investment which your business can benefit from.