There are many factors which affect scan time. Some information on the most significant factors, and ways you can alter them, are discussed in this article.
- Scan Scope Size
- Application Response Times
- Rate Limiting
- Large and/or Complex Web Application
- Duplicate Scan Targets
- Scan Hub Contention
- UDP Port Scanning
- UDP Port Scan Timings
- Scan Multi-threading
- Platform-Specific Checks for Platforms You Do Not Use
- Complex, Time-Consuming Plugins
- Automatic Passive Web Application Scanning
- Other Scan Settings
Scan Scope Size
Given a large number of targets a scan may face extended scan completion times. Therefore to reduce scan completion times, it is advisable if possible to split a scan up into individual smaller scans scheduled to run at different times.
Application Response Times
Response times can also cause excessive scan times - if an application becomes unresponsive, it can cause a delay of a couple of seconds to every request. For a request that normally takes 200ms, if this then becomes 2.2 seconds there has been a tenfold (1000%) increase in scan times, which will clearly have a significant impact on the scanning time.
Rate Limiting
Some WAFs and IPS devices impose rate limiting which will (by design) slow down the scan to the extent that completing the scan will not be practical. It is important that AppCheck's IP addresses are set to be allowed in such systems - see Allowing AppCheck Access to Your Network or Applications.
Large and/or Complex Web Application
Scanning a web application involves identifying every possible point of attack in the application (building a Mapped Attack Surface), which could be form fields, URL parameters, etc, and then testing every one of those points for every possible type of vulnerability (each of which could involve multiple requests).
Your application may have many or large forms, or accept a large number of parameters, and so on. The more such points of attack exist within the application the more requests will be required to scan it, and the longer the scan will take.
For example, if you are scanning with 100 scanner plugins enabled, each of which uses 10 requests to complete its tests (this is a hypothetical number, in reality it is not deterministic), then the scanner will need to send 1,000 requests to each point in the attack surface. If the attack surface is a single path with no parameters, no request body, etc, then the scan requires simply 1,000 requests. If the attack surface includes 10 parameters and 50 form fields then the scan requires at least 60,000 requests.
Duplicate Scan Targets
It is possible to configure your scan targets in such a way as to scan the same application multiple times within one scan. See this article for an explanation:
Scan Hub Contention
The amount of load on the scan hub running your scan can affect the speed of the scan.
In the case of scans running on AppCheck's public scan hubs you will not be able to control the overall level of contention. If you wish you could try scheduling your scans for a different time but generally we would advise to let us worry about that and just schedule your scans in accordance with your own needs.
In the case of scans running from your own private scan hub then contention is likely to come into play as you run multiple scans, and you should schedule these to run at different times as much as possible (or use multiple private hubs).
UDP Port Scanning
If an infrastructure scan is configured to scan all 65k UDP ports then this will take some time due to the way that UDP works - there is no state mechanism so the sender has in the event of no response being received to wait for a timeout and then perform retries in case the packets were lost. For more details, see also Port scanning - things to consider
UDP Port Scan Timings
If UDP port scanning is enabled, this option controls how long to wait for a response before assuming the port is dead and moving on, longer timings should lead to more accurate results but the scan will take longer to complete. More aggressive timings will mean a scan completes faster but there is a chance of missing some services if no response is received in time.
Scan Multi-threading
The web application scanner is multi-threaded, with each thread making requests to your application and analysing the results. By increasing the maximum allowed number of such threads for your scan you can decrease the time taken, at the expense of more concurrent load on your application and infrastructure.
There is not quite a 1-to-1 relationship between threads and requests (and therefore with time taken, and load on your application), but increasing the number of threads can significantly reduce the time required (and reducing the number of threads can significantly reduce load on your application).
This setting can be found in your scan configuration at:
Web Application Scanner Settings
-> Advanced Settings
-> Max Threads
Platform-Specific Checks for Platforms You Do Not Use
The AppCheck scanner includes plugins aimed at specific platforms, such as certain types of database (MySQL, Postgres, etc) or CMS (eg WordPress, Umbraco, etc). These can be found in:
Web Application Scanner Settings
-> Plugins
Running these plugins can involve a lot of requests and substantially increase the time it takes to complete your scan. If you are certain that a platform does not exist within your environment then you can disable checks aimed solely at that platform.
SQL Databases & SQL Injection
In the case of SQL Injection detection there is one plugin which can be configured with options for various database platforms. This is called SQL & XPath Injection and is found within the Injection category.
Do not click the tick-box to disable the plugin unless your environment contains no SQL databases at all. Instead, you'll usually want to configure the plugin to select which database platforms it should target. Click the name of the plugin to open its settings panel, then the "Configuration" tab, then click the down arrow net to "Supported Database Platforms". Here you can untick any that you do not use. Finally, close the settings panel and don't forget to save the scan. Make sure you only untick platforms that you definitely do not use - sometimes there can be a communication chain starting with your application which reaches other parts of your environment and interacts with database platforms you might not immediately think of when considering your one application in isolation.
NOTE: Remember to review this list if you add to or change the platforms in your environment in the future. You may wish to add a point to your change management policy etc to help with remembering this.
Content Management Systems
There are a numbers plugins aimed at various CMS platforms in the "Content Management Systems" section of the Plugins table. You can simply untick the plugins for platforms you definitely do not use. Again, do no forget to save your scan after doing so.
Complex, Time-Consuming Plugins
AppCheck prioritises accuracy over scan time. Some plugins are inherently time-consuming and cannot be accelerated without reducing accuracy. In this case you may wish to disable these plugins, or use them only in a less frequently run scan. For example you may have a weekly scan with these plugins disabled, and a monthly scan with them enabled.
Category: Injection
Plugin: SQL & XPath Injection
SQL Injection vulnerabilities are common and high impact, but the plugin to detect them is time-consuming. While disabling them completely would be unwise unless you're certain you have no vulnerable systems, saving them for a less frequently run scan could substantially accelerate your more frequent scans. Also see Platform-Specific Checks for Platforms You Do Not Use and disable checks for platforms you are certain you do not have.
Plugin: Command Injection
This is a time-consuming plugin to detect a rare vulnerability, it is therefore a logical choice to move to a less frequently run scan or even remove.
Path Traversal
This detects a type of vulnerability that is more common than Command Injection but does take a substantial amount of time. You may therefore wish to reserve this for less frequent scans.
Category: Build and Configuration Review
Plugin: JavaScript Library Validation
This plugin reports on out-dated JavaScript libraries. Those libraries may contain vulnerabilities so knowing about them is important, but this is a time-consuming process which may be best in a less frequently run scan.
Category: HTML5
This category contains a number of plugins relating to PostMessage and WebSocket. These plugins can be time consuming and detect vulnerabilities which are both rare and low to medium impact. You may therefore wish to reserve these plugins for less frequent scans or disable them entirely.
Automatic Passive Web Application Scanning
The option to "automatically perform a passive web app scan against any discovered web applications" is an optional stage during infrastructure scanning which is enabled by default. It is designed to give some coverage of web applications that you might not have thought to scan explicitly. The scanner looks for signs of web applications running on various ports on the scanned hosts and for any it finds it runs a short web application scan without active attack payloads. This takes just a few minutes per discovered application and so is generally fine if you are scanning a small number of hosts, but if you scan a range of hundreds of hosts the time taken quickly adds up.
This option can be disabled in the scan settings:
Infrastructure Scanner Settings
-> Vulnerability Scanner
-> Options
-> Advanced Settings
-> Automatically perform a passive web app scan against any discovered web applications.
Other Scan Settings
Other scan settings can have an impact on scan time. By eliminating some of these checks and avoiding edge cases, the scan time can be improved upon.
Forced discovery
This option controls if the scanner is to attempt to discover resources
that would not normally be discovered during in crawl, looking for potentially hidden
dangerous paths such as .git and .svn repositories
DOM XSS checks
This option tells AppCheck-NG to use a real browsers to detect and confirm XSS vulnerabilities. These checks can be very expensive, increasing the scan time and disabling this is not recommend but by switching this option off scan time can be decreased.
Scan REST paths
With this option enabled AppCheck-NG will scan the URL paths for vulnerabilities, this is only applicable when using a routing system for an application and if paths are confined to actual folders it isn't required.
Scan parameter names
This option instructs AppCheck-NG to scan the names of parameters for vulnerabilities and not just the values. With this option enabled the attack surface of all parameters is doubled.
Scan referrer headers
With this option enabled AppCheck-NG will attack the referrer header of an application.
Scan Cookie headers
With this option enabled AppCheck-NG will attack the cookie header of an application.
Scan user agent headers
With this option enabled AppCheck-NG will attack the user agent header of an application.
Scan all other headers
With this option enabled AppCheck-NG will test every header of an application.
Comments
0 comments
Article is closed for comments.