Selecting an Account for your Authenticated Web Application Scan

When configuring an authenticated web application scan one of the first decisions you need to make is what user account the scan should log in with.

As discussed in Minimising Risk of Web Application Scanning, the account you select should be:

• Non-privileged (if scanning in production)
• Only used for scanning
• Unique
• Controlled by AppCheck (Optional)

Non-privileged (if scanning in production)

With a few exceptions, the scanner will follow every link and click every button in can find.  While there is some protection in place to prevent things like changing passwords or deleting items this protection is not perfect and such functions may be triggered if available.  Therefore do not use an account that has access to do anything you don't want done.  To scan sensitive areas with a privileged account use a non-production environment.

This is particularly important when scanning things like control systems for industrial machinery, but scanning these is probably a bad idea with any account, in case said account has access (or a vulnerability grants access) to controls it isn't meant to have, which could have dangerous effects.

Only used for scanning

This is primarily to avoid interfering with data that may affect real-world users, but also avoids the slight risk of real-world users altering data mid-scan that may affect the scanner's ability to detect certain vulnerabilities.

For example, some vulnerability detections involving injecting data on one page, then later in the scan seeing that data presented elsewhere in the application.  If a human user (or, indeed, another scan, see Unique, below) were to alter or delete that data while the scan is running then that vulnerability may not be found.

Unique

If the scan triggers an unexpected behaviour in your application, you will know exactly which scan was responsible, and finding relevant log lines will be easier.

In this context "unique per scan" means per saved scan configuration, you do not need to create a new user each time the scan runs.

Controlled By AppCheck

If the account's email address is controlled by AppCheck, then the scanner can make use of emails sent to it, for example:

• As part of Multi-Factor Authentication
• To test password-reset functionality for vulnerabilities

AppCheck provides a tool for generating a unique email address on a domain we control and which can be accessed by the scanner.  You can use the following link to generate a new address:

https://ptst.io/generate_random_account

The password generated here is merely a suggestion, it is not used to access the emails

To view the latest email sent to your randomly generated @ptst.io address, use this link, with your new email address on the end, after the =

https://ptst.io/latest_email_by_to?to=

These emails are publicly accessible (though if you have used a unique address then only yourselves and AppCheck will know the URL, and only the latest email is accessible).  Do not send confidential information to these addresses.