There are many factors that can affect the efficiency and duration of a web application security scan as explained in the article how fast is your web application security scanner. One of the factors that most probably have the biggest impact are the security and vulnerability checks that are launched during the security scan, which can be preconfigured in scan policies. For example it is much quicker to scan a web application for cross-site scripting vulnerabilities only rather than for both XSS and SQL Injection vulnerabilities.
Though under the hood things are not that simple. In reality Netsparker Web Application Security Scanner does not only check for a few well known vulnerabilities that are listed in the OWASP Top 10. It also has a number of security checks for the operating system of the web server, for the web server itself, for the web application framework and much more. This article explains how you can fine tune the Netsparker scan policies to reduce the duration of a web application security scan. You can also apply the same concepts on our online web application security scanner Netsparker Cloud. The only difference is that the interface is a bit different from the one shown below.
Why Should You Configure Security Checks in Netsparker?
The easiest way to launch a scan is to enter the URL and accept all the defaults. In a default web application security scan the All Security Checks scan policy is used. This means that the scanner will scan your website for any type of known vulnerability, irrelevant of the technology your website is running on. In most cases such approach should not be a problem, but what if you are pressed for time and have limited resources, especially in terms of hardware, server resources and bandwidth? What if you have a complex website and it is taking you too long to identify all security flaws and vulnerabilities?
In such case you need the web application security scans to be quick, efficient and avoid any possibility of disrupting the service. The best way to optimize web application security scans is to only scan your websites and web applications against threats and vulnerabilities they might be vulnerable to. For example if you are using a Microsoft SQL Server it does not make sense to also launch MySQL server checks. After all such checks will only consume more resources and bandwidth. Let’s dig a bit deeper in this subject and see how you can configure Netsparker to get the best out of it.
Built In Scan Policies in Netsparker
Netsparker has a number of built in scan policies that if used correctly can already give you a head start when it comes to reducing the scan duration. Below is a short introduction about each of the default scan policies:
All Security Checks
This scanning profile contains all the typical security checks. If you are not sure what type of web server and database backends are being used on the target, you can select this scan policy. This means that the target website will be scanned for all types of vulnerabilities. If you know the type of database backend being used you should select one of the below builtin scan policies which are specifically targeted to specific technologies. Therefore they consume less resources and bandwidth and take less time to complete.
All Security Checks (MS SQL)
This contains the same security and vulnerability checks as the All Security Checks scan policy but the SQL Injection checks are only for Microsoft SQL Server.
All Security Checks (MySQL)
This contains the same security and vulnerability checks as the All Security Checks scan policy but the SQL Injection checks are only for MySQL server.
All Security Checks (Oracle)
This contains the same security and vulnerability checks as the All Security Checks scan policy but the SQL Injection checks are only for Oracle database server.
All Security Checks (PostgreSQL)
This contains the same security and vulnerability checks as the All Security Checks scan policy but the SQL Injection checks are only for PostgreSQL database server.
Extensive Security Checks
This scan policy contains all the security checks included in the All Security Checks scan policy and some other attack patterns that are not too common and typically are mostly edge case scenarios. Mainly it includes extra DOM XSS vulnerability and Local File Inclusion checks. Because of the nature of such vulnerability checks, when scanning for these vulnerabilities the scan can take a considerable amount of time.
Fine Tuning Web Application Scan Policies
Although the default scan policies in Netsparker can be used to improve the efficiency of the web application security scans, you can further enhance the scans by creating your own scan policies. By fine tuning the scan policies you can also drastically reduce the time it takes to complete the security scans. To create your own scan policies you can create new policies or clone any of the existing ones as explained in Create Your Own Scan Policies with Netsparker Scan Policy Editor. Below are some examples of how you can tune your Netsparker scan policies.
Operating System Security Checks
If you know the operating system of the target web server you can switch off all the security checks for all other operating systems in the Command Injection, Command Injection (Blind) and Local File Inclusion checks groups. For example if the target web application is using Microsoft SQL Server as database backend and is running on Windows, it is recommend to:
- Make a clone of the default security policy All Security Checks (MS SQL)
- Navigate to the Command Injection checks group and disable all security checks for Linux as highlighted in the screenshot below.
- Do the same in the Command Injection (Blind) and Local File Inclusion checks groups.
- Once finished save the new scan policy and use it to launch your next web application security scan.
Note: Configuring your scan policy for the correct type of database server and operating system is very crucial. These types of security checks make a big difference on the performance and duration of the scan especially if the target website is big and complex. The rest of the optimizations listed below might not make a big impact but can still decrease the web application security scan time.
Scanning Custom Built Web Applications
If you will be scanning a custom built web applications where no off the shelf web application such as WordPress, Drupal and Joomla are being used, disable the group Web App Fingerprinting.
Web Server Security Checks
Netsparker also contains a number of web server security checks to help users identify security issues in web servers. Therefore if you know the type of web server the target web application is running on, for example IIS, you can safely switch off all other web server security checks such as those for Apache and Nginx. You can find web server security checks in the following groups:
- Static Resources
- Signatures
- Mod negotiation (this is a specific Apache security check)
Web Application Framework Security Checks
There are several different web application frameworks available such as PHP and ASP.NET. Netsparker has specific security checks for each of them, hence if you know which web application framework was used to build the target web application you can safely switch off the security checks for all other frameworks. You can find web application frameworks security checks in the following groups:
- Remote File Inclusion (disable this group if target is not using PHP)
- Remote Code Evaluation
- Expression Language Injection (disable this group if target is not using JAVA)
- RoR Code Execution (disable this group if target is not using Ruby on Rails)
- WebDAV (disable this group if target is not using WebDAV)
- Signatures
Other Generic Checks
If you are not familiar with the target web application we do not recommend you to switch off any of the generic checks, but if you are you can also consider disabling the following security checks:
- Backup Files; checks for backup files which could be downloaded from the target
- Common Directories; checks for typical directories in target web application that could potentially expose confidential data, such as admin portals etc
- Signatures; several security checks for web servers and web application frameworks, such as directory listing, version disclosure etc. Browse this group for more details about each check.
Even if you have access to the web server and ability to see the listings of all the files on the target web application I recommend you to keep these checks enabled unless you desperately need to cut down the scan duration time.
The Need to Optimize Web Application Security Scans
With just a bit of homework you can easily optimize the scan policies to benefit from quicker and more efficient web application security scans. If you compare the time it takes you to identify the operating system, web server, database backend and web application framework of a target web application to the time it takes for the scanner to complete all the security checks, you will find out that the latter takes much longer.
Hence I recommend you to spend those five or ten minutes fine tuning the scan policies before scanning a new web application. And since you can save the scan policies, there is no need to do this procedure each time you scan a web application because you can have a scan policy for each web application you are scanning.