Settings for a web application profile are described below. Specify settings to configure web crawling, sensitive content detection, vulnerability detection, and password brute forcing.
Select settings affecting crawling behavior and overall scan performance during the web application scan.
Select the method to be used by the web crawler to submit requests to forms. The web crawler follows links to form actions that it encounters when the form "method" attribute, as defined in each target form, matches the Form Submission setting you select.
This configuration does not apply to authentication. If an authentication record is selected for the scan, the scanning engine will attempt to authenticate no matter which Form Submission setting you select.
Your options are:
• None. (Default) No requests to forms will be submitted unless application authentication is requested, in which case only the login form will be tested.
• Post. Limits web crawling to POST forms.
• Get. Limits web crawling to GET forms.
• Post & Get. The web crawler submits requests to all forms. When authentication is desired, this option is recommended best practice to ensure maximum vulnerability analysis and the most comprehensive scan results.
The maximum links to crawl during the scan. The default is 300 links. The maximum is 5,000 links.
Select an overall performance level for the web application scan. It's recommended that you keep the default performance level of Medium to get started. Your options are: Maximum, High, Medium (default), Low, and Lowest. Each option represents several scan performance settings. See Scan Performance for details.
The scanning engine has the ability to check for sensitive content in the web application pages it crawls based on known patterns (such as credit card numbers, social security numbers) or based on custom patterns you enter. The expression search mechanism can check for credit card numbers and social security numbers (United States only) while reducing false positives. The service does not collect credit card information or social security information.
You may select one or more types of sensitive content detection. Your options are:
Credit Card Numbers. When selected, the scan checks for sensitive content based on credit card numbers.
Social Security Card Numbers (United States Only). When selected, the scan checks for sensitive content based on United States social security numbers.
Custom. Select if you want the scan to check for sensitive content based on custom patterns you specify. Sensitive content for custom checks may be specified as strings and regular expressions in the field provided. You can enter a maximum of 10 custom checks, where each check appears on a separate line. An entry for a single check must be a minimum of 5 characters and a maximum of 100 characters.
Important: Sensitive content detection will be performed only when you scan for QID 150016. If you select Custom in the Vulnerability Detection section, you must add a search list which includes QID 150016.
When a profile has sensitive content detection enabled and it is applied to a web application scan, the scanning engine performs sensitive content detection for the selected types during the scan. If the scanning engine identifies sensitive content matches, sensitive content QID 150016 is returned in the web application scan results.
Identify the Web Application Vulnerabilities you would like to include in the scan.
In any web application profile you may include any number of any of the web application vulnerabilities (QIDs) in the Knowledgebase. For discovery scans, the service will include information gathered QIDs only (any other QIDs included in the profile will be ignored).
Your options are:
Complete. A complete scan of all web application vulnerabilities (QIDs) in the KnowledgeBase.
Custom. A custom scan for a limited set of web application vulnerabilities (QIDs) as defined in vulnerability search lists. Add up to 10 search lists containing web application vulnerabilities to the web application profile. Note that the search lists you add to this profile must contain only web application vulnerabilities. See Using Search Lists for information on adding search lists to the profile. When the profile is applied to a web application scan, only the QIDs defined in the search lists are included in the scan.
Note: Applies to Vulnerability Scans only.
The scanning engine has the ability to perform password brute forcing to test password security. Password brute forcing will be performed only when you scan for QID 150049. When performed, the scanning engine uses an internal list of common user names and an internal list of common passwords. The passwords list ranks passwords from most common to least common, and you have the option to select some number of the most common passwords to be tested. Email address are collected during the scan and tested as user names when you scan for QID 150054, where the part of the email address before the @ sign is tested as a user name.
Warning! The password brute forcing behavior may trigger lockouts depending on lockout policies you have in place. Please select a level of password brute forcing that is appropriate for your security policies.
To enable this feature, select Perform password brute forcing and a level of password brute forcing. Your options for the level are:
Minimal (empty passwords + UID = password). For each user name, test the empty password and the user name as a password. For example for the user name "jsmith" test the password "jsmith" and the empty password.
Limited (+ 10 most common passwords). For each user name, test these passwords: the user name, the empty password, plus the 10 most common passwords from the internal common passwords list defined by the WAS module.
Standard (+ 20 most common passwords). For each user name, test these passwords: the user name, the empty password, plus the 20 most common passwords from the internal common passwords list defined by the WAS module.
Exhaustive (will increase scan time). For each user name, test these passwords: the user name, the empty password, plus all passwords in the internal common passwords list defined by the WAS module.
Custom: [ ] attempts. Use this option if you have a lockout mechanism for a number of failed attempts.
In the field provided, enter the exact number of attempts to be performed (a number greater than 0). If you have a lockout mechanism, enter the maximum number of guesses allowed.
The passwords tested will include the user name, the empty password, plus common passwords from the internal passwords list defined by the WAS module. For example if you enter 10, the following passwords will be tested: the empty password, the user name, plus the 8 most common passwords in the internal common passwords list defined by the WAS module. If you enter 1, this one password will be tested: the user name. If you enter 2, these two passwords will be tested: the user name and the empty password.
Important: Password brute forcing will be performed only when you scan for QID 150049. If you select Custom in the Vulnerability Detection section, you must add a search list which includes QID 150049. Also, if you want to use email addresses found in the web application HTML as user names for password brute force testing, you must scan for QID 150054.
When a profile has password brute forcing enabled and it is applied to a web application scan, the scanning engine performs password brute forcing according to the selected level during the scan. Logins are attempted using combinations of common user names and passwords based on internal lists of defined by the WAS module. If the scanning engine succeeds in logging into an authentication form, vulnerability QID 150049 is returned in the web application scan results. This QID returns useful information for understanding your security exposure. Note that successful authentication from password brute forcing techniques does not increase the number of vulnerabilities that can be detected by the scanning engine.
When password brute forcing is performed, email address names (local-part) found during the scan are tested as user names (in addition to the internal list of common user names) when vulnerability QID 150054 is included in the scan. As the scanning engine finds email addresses in the web application HTML, it parses the part of the email address before the @ sign and uses this value as a user name for password brute force testing.