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
- Scan Hub Contention
- Application Response Times
- Extensive Web Application Footprint
- Duplicate Scan Targets
- UDP Port Scanning
- UDP Port Scan Timings
- Scan Multi-threading
- Platform-Specific Checks for Platforms You Do Not Use
- 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.
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).
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.
In addition to the application itself being slow to respond, some WAF and IDS devices can cause a requesting IP to back off request rates, further slowing scans.
Extensive Web Application Footprint
For a large web application, the generated leaf graph (attack surface) will be significant, and some checks may need to execute on every leaf discovered. This can lead to a significant number of HTTP calls needing to be made.
If you wish to artificially restrict the scope then you can try a few different things:
- Limit the crawling by time, by setting the config flag 30_min_crawl in your scan settings
- Turn off "brute force discovery" to turn off brute force guessing of paths and rely on crawling via measures such as site navigation/response parsing and robots.txt examination.
- In extreme situations, you can turn off default crawling and replace it with just a number of defined GoSCript seeded journeys only.
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:
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.
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. Then 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.
This is one of the biggest savings on scan time. Even if you do use relational SQL databases, you could consider running a scan with and without this plugin, I sometimes run a “SQLi only” and “All except SQLi”. The nature of SQLi detection to the accuracy we do it means that its just slow by nature, there’s no way around that without risking missed cases.
Command Injection
This is a rare vulnerability but an expensive plugin. I’d consider disabling this and then running it in a separate longer running scan if that suits the objectives. If not then of course leave it enabled.
Path Traversal
As above. This is more common but its long running, you could cut this out and run it within a slower scan that perhaps runs less frequent.
HTML5 Category
Disabling all of the PostMessage and Websocket checks will help speed up the scan. This is another rare finding with a maximum cvss of 4.3
Content Management Systems
You'll find plugins aimed at various CMS platforms in the "Content Management Systems" section. You can simply untick the plugins for platforms you definitely do not use. Again, do no forget to save your scan after doing so.
Build and Configuration Review Category.
The “JavaScript Library Validation” plugin reports on out dated JavaScript libraires. It uses a browser which is has an overhead. If you don’t need to know about outdated jQuery etc in every scan then this one can be disabled for a speed bump.
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
Please sign in to leave a comment.