AppCheck web application scans work by making requests to your web application across the internet using HTTP. It does this using a real web browser session, in the same way as one of your customers - or a remote attacker - might interact with the site.

In order to detect vulnerabilities, the scanner must make requests both at a high rate (in order to complete testing in a reasonable period) and using requests that may cause data submission  (eg via HTML forms on your website). Where a vulnerability is present in your web application, this MAY in some circumstances risk causing data modification or entry in back-end data stores such as databases, server downtime or outage, excessive logs being written to disks, or consumption of resources via backend APIs (eg postcode lookup services) with a cost impact.

This guide therefore aims to provide guidance on how you can safely configure AppCheck, and your web application, to ensure that the likelihood of any disruption from AppCheck's operation is kept to a minimum, and your risk appropriately managed.

 

Table of Contents

• Backup (and restore)
• Logging
• Crawling Volume
• Attack Payload Scan Intensity
• Plugins Selection
• Authentication
• Test Environment
• Monitoring scans and scan windows
• Active Scanning
• Email Notifications
• Scanning Templates

Backup (and restore)

Most web applications will have a back-end data store of some sort, such as a MSSQL database, or a MongoDB document store. It is important, regardless of whether you use AppCheck or not, to back up this data regularly, and to test restoration of those backups periodically. Without this protection, any changes made to data by AppCheck (or an attacker), or in the event of server or disk failure, cannot be undone. Ensure that all systems scanned by AppCheck are confirmed to be backed up and those backups are routinely tested for restoration.

Logging

Web applications typically log entries on the server in special logfiles, recording activity, sometimes up to hundreds of lines are generated for each HTTP request, recording the date and time and the exact action performed, as well as code paths followed and data requested or updated. At higher log levels (eg "INFO" or "DEBUG") this can lead to high disk usage and sometimes to disks running out of space. It is important to check that the log level of all applications (and databases) is appropriate for production use and that logging is not verbose where not needed.

Crawling Volume

In order for AppCheck to be able to map out the entire structure of the website that you want to scan, it will analyze your website. By default, the web application scanner will use a mix of Bruteforce Discovery (trying lots of different paths) as well as crawling (requesting one page and then parsing the response for links to other pages that it could request– in the same manner as having a user click on every link on your site. With each link that is crawled, new pages are discovered), and requesting sitemaps etc in order to build up a list of webpages that it needs to check for vulnerabilities.

If your web application server is not massively scaled, these high number of requests may cause your server to become sluggish or even unresponsive. There are various things that you can look at on a small webserver to limit the chance of this happening:

1. Rather than relying on Bruteforce Discovery, you can disable this option and rely on crawling only, in Advanced Settings.
2. You can also narrow down the number of pages even further if needed by only scanning pages on certain key journeys defined in AppCheck's GoScripts (see A Guide to GoScript).

Attack Payload Scan Intensity

Additionally, once crawled, a web application may see thousands of requests to each page or form, as detailed at Why does AppCheck make so many HTTP request to my site or domain?

On a smaller or less scaled web application you can limit the scan intensity using rate limiting and throttling built into AppCheck by setting a lower maximum thread count.  This setting can be found at:

  Web Application Scanner Settings

  -> Advanced Settings

  -> Max Threads

Plugins Selection

AppCheck is a very powerful scanner that has a large number of plugins enabled by default in order to find the broadest range of vulnerabilities. However, if you understand the tech stack of your web application well, you can likely identify plugins that are not needed - for example if your database is MongoDB, you likely do not need to scan for MySQL vulnerabilities. Disabling these unneeded plugins in your scan settings will allow scans to complete faster, cause less spurious logging, and reduce the chance of unexpected behaviour by your application.

Authentication

For Authenticated scanning (where the scanner logs in as a user in order to access portions of the website that is only available to logged-in users, in order to evaluate them for vulnerabilities), it is highly recommended to ensure that a specific account is set up unique to AppCheck - the account should not be a real user's account, and should not be shared with any other system. This ensures that, if user data is altered by scanning, it is likely that only AppCheck's own account data is altered.

For Authenticated scanning, it is also important in the majority of cases to make sure that the user is a non-privileged user account rather than an administrative account. Admin rights being granted to the account that AppCheck is authorising with might cause problems with certain links on your web application. AppCheck will try and avoid URLs that is sees as dangerous - for example anything with "delete" in the action name - if the plugin is not disabled. But AppCheck cannot know the purpose given links or URLs with absolute certainty, so caution should be used.

Test Environment

If a web application is particularly critical and/or no disruption to service whatsoever can be tolerated, then we would advise customers in these circumstances to target a test or staging instance of their web application instead of the live/production instance, either instead of or as a smoke-test prior to scanning production environment. In most cases we would always advise scanning the production instance if possible (even if test is scanned first) since some vulnerabilities may be environment-specific, however the risk in doing so should be understood.

Monitoring scans and scan windows

It is advisable to monitor the progress of scans, and the website being scanned during web application scanning if possible so that a scan can be halted if needed. Scans can be configured to only execute during certain days and times under Settings ->  Scanning Window Settings. Many organisations will seek to only scan sites out of regular business hours, but this in fact makes it less likely that a scan will be suitably monitored by staff or can be halted in the event of any issue being observed.

Active Scanning

Some vulnerabilities, such as Injection vulnerabilities (eg XSS and SQLi) can only be tested via active scanning (that is by actively attempting to exploit vulnerabilities, in the same way as an attacker would). While every effort is made to ensure that active scanning is performed with little or no impact, this cannot be absolutely guaranteed, depending on the application. For web applications where unsanitised data entry via forms etc may cause either unexpected data alteration or high-volume email notifications etc, the following options can be set:

1. You can Disable Active Scans - By disabling active scanning, AppCheck will enter passive scanning mode and not attempt to find any vulnerabilities which may require intrusive detection. Fewer vulnerabilities will be spotted, but the scan will be much less likely to cause issues.
2. You can Disable Scan Forms or enable Avoid Contact Forms to limit the POSTing of data via forms. It is worth noting that forms can be one of the most vulnerable elements on a web application, so disabling them in AppCheck may simply mask vulnerabilities with them, whilst leaving them open and vulnerable to malicious attackers.
3. You can Restrict access to known paths that are unsafe to scan using Settings -> Denied Targets

Email Notifications

During scans, you will receive emails from scan@just-a-scan.com wherever a contact form or email field is found in a form. Where this triggers your server to send an email, you may therefore create thousands of such emails during scanning. You may wish to set up mailbox rules to filter emails to or from the above address, in to avoid your main inbox being swamped by these or emails being sent to internal or external parties by your server.

Scanning Templates

AppCheck includes a scanning template named “Sensitive Production Infrastructure”. This template disables Dynamic Application Security Testing (DAST) modules that operate by recording and replaying application requests. Instead, this template focuses on vulnerabilities that are most likely to occur between different environments such as; HTTP Request Smuggling, Cache Poisoning, CVE scanning, Web server configuration and Build scanning and other infrastructure level vulnerabilities.

The recommended way to use this template is to perform a full scan of the pre-production environment and supplement that with a Sensitive Production Infrastructure scan of the production environment. The latter would typically be an unauthenticated scan and is designed to be run regularly.