The deepest level of AppCheck scanning is performed whilst logged in to your applications or infrastructure targets. This enables detection of vulnerabilities which are only found behind your application's authentication barrier, and more accurate detection of software packages on your infrastructure.
This guide will explain how to select credentials for use in your scans, how to store those credentials securely in AppCheck, and how to include them in scans.
- Selecting Which Credentials to Use
- Storing Credentials in AppCheck
- Using Credentials in Scans
- Frequently Asked Questions
Selecting Which Credentials to Use
Web Application and API Scans
When configuring an authenticated 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)
- Random Password
Non-privileged (if scanning in production)
Critical requirement: Scanning a production environment with a privileged account (admin-level, or with access to real users' data) is highly likely to result in unintended modifications to live data, including data loss or corruption.
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.
IMPORTANT! Using a non-privileged account is especially relevant when scanning operational technology (OT) – systems that monitor or control physical processes, such as industrial control systems, building management systems, or utility infrastructure.
However, we recommend against scanning such systems altogether, regardless of the account's privilege level. If the scanning account – or a vulnerability that grants unintended access – provides any pathway to control functions, this could result in unintended commands being sent to physical equipment, with potentially serious safety and operational consequences.
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.
Random Password
There are several reasons to use a randomly generated password. As well as security benefits, there is a feature of AppCheck's scanning that can be affected by a badly chosen password.
The scanner will attempt to identify application components that change or reset the account password and will avoid activating them. If the password is a common word, or the name of the application or organisation, then it may appear in places within the application, and those places may be incorrectly identified as password changing functionality, and will therefore not be scanned.
For example, if your application contains the URL is https://example.com/foo and your password is "foo", then the scanner may avoid that part of your application, since it believes https://example.com/foo is related to password changing.
This functionality can be changed or disabled, but this is not recommended. Instead, we recommend using a randomly generated password (you may choose to use the one suggested by https://ptst.io/generate_random_account).
Infrastructure Scans
Unlike web application and API scans, for infrastructure scan an admin level account is recommended. In this case the scanner will not attempt to perform actions and make changes (the main risk of using an admin account in a web application scan), and the admin level account will expose the most information about the versions of software on the target.
We recommend creating a dedicated user for AppCheck.
See Credentialed Infrastructure Scanning for more information.
Storing Credentials in AppCheck
Credentials are managed in the Credentials Manager, which you'll find in the main menu of your AppCheck portal.
Clicking Add Credentials lets you specify the type of credential (username+password, or key/token), as well as the values and an optional expiration date, for example:
Once the credentials have been saved, you can now select them in a scan configuration, GoScript, or other location within AppCheck where target credentials are used:
This scan is now configured to use the Linda @ AppCheck username and password. Any changes made to Linda @ AppCheck will affect this scan (and any others using these credentials) the next time it starts.
Using Credentials in Scans
Using credentials in scans is as simple as selecting the stored credentials set in your scan configuration.
Credentials are and are linked, rather than copied, to your scan upon import. Any subsequent changes made to your stored Credentials will affect all linked scans the next time they run.
For further instructions on using your credentials in scans consult the guide for the type of scan:
Frequently Asked Questions
What happened to the credentials I had configured directly in my scans before the Credentials Manager was introduced?
These have been automatically converted into Credentials objects. Their names will follow this structure:
<type> from <scan name> at <time>
Can I use multiple Credentials in a single script or scan?
Currently no, a single GoScript or authentication section in a scan can only use a single Credentials object (though you might use one set of credentials for Digest Authentication and another in your GoScript, for example). If you need to include more values within your GoScript you will need to add them as GoScript variables.
Can I use Credentials in API Workspaces?
No, currently API workspaces do not support the Credentials system. You will need to enter your credentials directly in the workspace configuration.
Who can access Credentials?
All Admin users, and Users who have the "manage credentials" permission assigned in a User Group.
Comments
0 comments
Article is closed for comments.