Tenable Web Application Cerdential Scans For Web Appications and APIs – 51 Security

Tenable Web App Scanning provides comprehensive vulnerability scanning for modern web applications. Tenable Web App Scanning’s accurate vulnerability coverage minimizes false positives and false negatives, ensuring that security teams understand the true security risks in their web applications. The product offers safe external scanning that ensures production web applications are not disrupted or delayed, including those built using HTML5 and AJAX frameworks.

For more information on Tenable Web App Scanning architecture and scanning, refer to:

2FA is not supported in Web Application Scanning (WAS). Most 2FA issues can be solved with Cookie Authentication but will require a replacement of the cookie before every scan. There are other possible options depending on the configuration and setup of the web application.

SSO – Single sign-on is supported, depending on the setup. This can be done via Selenium Authentication. However, there are some limitations.

Architecture

Each application is unique. Running scans and analyzing the results reveal techniques that help you run scans most efficiently and ensure coverage of all areas of the application. Depending on the size or complexity of the web application, the scan may finish allowing you to analyze the results for further optimization. Tenable highly recommends that you review the “scan notes” after a scan completes and the attachment to the sitemap plugin regularly.

Scan Objectives:

1. Risk Assessment

2. Compliance Requirements

3. Data Sensitivity

4. Technology Stack

5. Specific Vulnerabilities

Web App Config Audit:

1. Analyzes HTTP Headers

– Missing security content policies

– Missing XSS headers

– Enforced HTTPS?

2. Runs quickly

SSL_TLS Scan

Tenable Web App Overview Scan:

1. Discovery scan for an organization’s web apps

2. Spiders and inventories web pages

3. Results stored in sitemap.csv

4. Little/noexposure analysis

5. Length depends upon size of website and number of pages

Quick Scan – Similar to the config audit scan

Scan

Specific scan – PCI, API, Log4Shell

Features

In Tenable Web App Scanning scans, you can configure credentials settings that allow Tenable Web App Scanning to perform an authenticated scan on a web application. Credentialed scans can perform a wider variety of checks than non-credentialed scans, which can result in more accurate scan results.

Scans in Tenable Web App Scanning use managed credentials. Managed credentials allow you to store credential settings centrally in a credential manager. You can then add those credential settings to multiple scan configurations instead of configuring credential settings for each individual scan.

Tenable Web App Scanning scans support credentials in the following authentication types:

Credentials Category	Authentication Type	Configuration Method
HTTP Server Authentication	–	Use the Tenable Web App Scanning user interface to manually configure credentials settings in scans.
Web Application Authentication	Login Form
	Cookie Authentication
	API Key	Use the Tenable Web App Scanning user interface to manually configure credentials settings in scans.
	Bearer Authentication

Basic Authentication:

username / password
Basic and NTLM supported

Cookie-based Authentication

Use a web browser to sign in
Copy cookie
Name+Content
chrome://settings/siteData
Check limitations (https, NoScript, expiration, etc.)

Form-based Authentication

Manual
Selenium scripting
Tenable extension (chrome)
Plugin ID 98033

Manual Authentication

Login Page
Credentials
Pattern to verify success
Page to verify active
Pattern to verify active
All patterns are regex

Forms Authentication Using Selenium Scripting

Browser automation tools through scripting
Created manually or with tools
Supported in multiple browsers

Selenium IDE Chrome Extension

https://chrome.google.com/webstore
Selenium IDE
Additional details – http://seleniumhq.org

Web Application Authentication document:

https://docs.tenable.com/vulnerability-management/Content/WAS/Scans/WebAppAuthentication.htm

Licensing Tenable Web App Scanning

Tenable Web App Scanning has two versions: a cloud version and an on-premises version. For the

cloud version, Tenable offers a subscription model. For the on-premises version, Tenable offers a

subscription model as well as perpetual and maintenance licenses.

To use Tenable Web App Scanning, you purchase licenses based on your organizational needs and

environmental details. Tenable Web App Scanning then assigns those licenses to assets in your

environment: unique fully qualified domain names (FQDNs). If you only scan IP addresses, the

system licenses those instead.

When your environment expands, so does your asset count, so you purchase more licenses to

account for the change. Tenable licenses use progressive pricing, so the more you purchase, the

lower the per-unit price. For prices, contact your Tenable representative.

Tenable Web App Scanning determines your licensed asset count by scanning resources in your

environment to identify FQDNs. FQDNs that have been scanned for vulnerabilities in the past 90

days count towards your license.

Tenable Web App Scanning reclaims licenses from deleted assets within 24 hours. In addition, it reclaims licenses from assets which are not scanned for 90 days or a period you specify.

To allow for usage spikes due to sudden environment growth or unanticipated threats, Tenable Web

App Scanning licenses are elastic by 10%. However, when you scan more assets than you have

licensed, Tenable clearly communicates the overage and then reduces functionality in three stages.

Tenable Web App Scanning Deployment Options

Tenable offers many deployment options for Tenable Web App Scanning. For more information,

refer to the following product pages:

Tenable Core + Web App Scanning – You can use the Tenable Core operating system to run an instance of Tenable Web App Scanning in your environment. After you deploy Tenable Core + Tenable Web App Scanning, you can monitor and manage your Tenable Web App Scanning processes through the secure Tenable Core platform.
Tenable Web App Scanning in Tenable Nessus Expert – Tenable Web App Scanning in Tenable Nessus Expert allows you to scan and address web application vulnerabilities that traditional Tenable Nessus scanners, Tenable Nessus Agents, or Tenable Nessus Network Monitor cannot scan.
Tenable Web App Scanning Docker Image – You can deploy Tenable Web App Scanning as a Docker image to run on a container. The base image is an Oracle Linux 8 instance of Tenable Web App Scanning. You can set up your Tenable Web App Scanning instance with environment variables to deploy the Docker image with configuration settings automatically. Once the Docker image is deployed, you can also update it, or collect scanner logs.
Tenable Web App Scanning CI/CD Application Scan – You can deploy the Tenable Web App Scanning Docker image as a continuous integration and continuous delivery/continuous deployment (CI/CD) tool to run Tenable Web App Scanning scans on software before merging it. Scanning your CI/CD applications and services at any point in your application’s lifecycle can greatly improve your security stance by finding vulnerabilities as early as possible.

Web application scanning (WAS) is available in Tenable Nessus Expert. Web application scanning in Tenable Nessus allows you to scan and address web application vulnerabilities that traditional Tenable Nessus scanners, Tenable Nessus Agents, or Tenable Nessus Network Monitor cannot scan.

Tenable Web App Scanning (WAS) Scan Workflow

Note: When you launch a scan, the time the scanner takes to complete the scan varies depending on the system load. To prevent lengthy scan times, avoid launching an excessive number of scans simultaneously. Excessive numbers of concurrent scans may exhaust the system’s scanning capacity. If necessary, Tenable Web App Scanning automatically staggers concurrent scans to ensure consistent scanning performance.

Note: Tenable Web App Scanning aborts scans that remain in pending status for more than four hours. If Tenable Web App Scanning aborts a scan, modify your scan schedules to reduce the number of overlapping scans. If you still have issues, contact Tenable Support.

In Nessus Web app scanning, you will only be able to launch one WAS scanning instance.

API Scan

A scan that checks an API for vulnerabilities. This scan analyzes RESTful APIs described via an OpenAPI (Swagger) specification (file upload or URL of the file location). File attachment size is limited to 1 MB.

Tip: If the API you want to scan requires keys or a token for authentication, you can add the expected custom headers in the Advanced settings in the HTTP Settings section.

Note: API scans support only one target at a time.

Steps to launch a API scan:

Select the API scan template.

In the Settings section of the Create a Scan – API Scan page, populate the mininmum required settings: name, scanner and target

In the Scope section, add the OpenAPI (Swagger) file for the API you are scanning in one of

the following ways:

Enter the URL of your OpenAPI (Swagger) file:

Select URL in the drop-down list
Enter the URL of your OpenAPI (Swagger) file in the text box.

Upload an OpenAPI (Swagger) file.
(Optional) Enter any URLs that you want to exclude from your scan in the Regex for excluded URLs textbox.

Note: The RESTful API file should be OpenAPI Specification (v2 or v3) compliant and represented in

either JSON or YAML format.

Note: Attaching an OpenAPI (Swagger) file larger than 1 MB to an API scan, results in an error

message. For more information on this limit, see the Knowledge Article. For more information

on Swagger specification files. see OpenAPI (Swagger) Specification.

Creating a script in Selenium

Install Selenium Chrome Extension

start extension

recording

Stop recording

Use the script in a Credentialed Scan

Credentialed Scans without a Script using Policy Config

Create a new Web Application Authentication:

Manual Credentialed Web Application Scan:

MFA / 2FA and SSO

2FA is not supported in WAS. This is because one of the major reasons for using 2FA is to stop automated platforms authenticating. There are however, many ways to work-around this kind of issue. Here are just some examples:

Contact the primary developer/team of the site. They have many more options available to them to support these scenarios.
Contact the vendor for the 2FA. The 2FA vendor may have a method they recommend to support scanning.
For the specific account created for WAS, create a “static token” that allows one specific account to use the same token/digits over and over again. We recommend changing this token periodically or based on your organization’s policy.
Create a “bypass” policy in whatever tools you’re using for 2FA. For example, if the scan comes from IP range xx-yy, then bypass SMS auth. This can also be done as a combination of “headers authentication”. (i.e. put something in the headers such as a long string (token) that is unique to that IP range. This prevents a second user on Tenable.io from scanning the same site as well.)
Login to the web application, proceed with the authentication, and capture the session token used (cookie). Put the token into the scan properties (cookie authentication). It should work for that one scan. This option would require manual intervention each time a new scan is run.

Single sign-on is supported, depending on the web application configuration, through Selenium Authentication. However, if the application requires two-factor authentication where the second factor is something like an SMS pin, Web Application Scanning (WAS) cannot work around that. Cookie authentication would be required.

Workaround for 2FA / MFA / SSO related issue:

Note: https://community.tenable.com/s/article/Does-WAS-support-2FA-and-SSO?language=en_US

Example of Scanning WordPress site

WordPress Form:

{“pwd”:”admin1234!”,”log”:”admin”}

You might get Login Form Authentication Failed Message.

Double click in this Login Form Authentication Failed finding, you will get this suggestion:

“Check the output of the plugin to get an explanation of the issue encountered by the scan.“

Export the scanning report into PDF or HTML, you can find further information:

OUTPUT
The scanner was unable to login to the web application using the credentials provided.
Login form with fields ‘admin’ could not be found in URL ‘https://itprosec.com/wp-login.php?redirect_to=https%3A%2F%
2Fitprosec.com%2Fwp-admin%2F&reauth=1′; however, 2 forms have been identified on this page:
– Form #1: 6 fields identified: (name: log, id: user_login), (name: pwd, id: user_pass), (name: rememberme, id:
rememberme), (name: wp-submit, id: wp-submit), (name: redirect_to, id: ), (name: testcookie, id: )
– Form #2: 3 fields identified: (name: wp_lang, id: language-switcher-locales), (name: redirect_to, id: ), (name: , id:
)
Source code of the forms are available in the attachments.
Verify that you have specified the login form fields correctly. Specify either the ‘name’ attribute if set, otherwise
the ‘id’ attribute. Do not specify the input field if neither attribute is available.
If your application does not use the form element for authentication or the form cannot be processed correctly, please
try using the ‘Selenium Authentication’ method.

Basically, the credential was not set up correctly. Based on the output, I changed the credentials to following format. log is used for username, pwd is used for password.

If the configuration is wrong, you will be getting an error with following output in the findings:

OUTPUT
The scanner was unable to login to the web application using the credentials provided.
Login form with fields ‘pwd’, ‘log’ has been found on URL ‘https://itprosec.com/wp-login.php?redirect_to=https%3A%2F%
2Fitprosec.com%2Fwp-admin%2F&reauth=1′, but when submitting it the response did not contain the pattern or text
‘Dashboard’ expected if login is successful.
Check the response provided as an attachment and verify what text can be used to check if the login process was
successful.
If the response indicates that login was not successful or not attempted, check the reason provided and update the
login form options accordingly.
Following cookie(s) have been set for this session:
– cf_clearance=FyARnfTW.smSUrXduuW7WYx_HCmAhTFnGMz1sCLepxk-1724640104-1.2.1.1-8o.
91Wj1kJl4CMATTbNvRFHe65KYCzEDDkQF4TUOYKa_HpEl0bQ2BdhRc33V5i3OeFg8EpHeCfL9L1MIdJOKFqqjv87gksHrUCYdmt0qM4n3NDs_XAeXit907Bnb21YPXDcY0d2HiY0sF2T3inxcYmScKLu9WXX6yzQ6DkzNV8SrdPygq9YN2DKCzrdLHIzBGt2AA2OhhAfS56QD6JlDNRxlUkvBa9yV.
mpRjfgsF_mAedHPuo2A4kaHZznlQ9ExuhTeOU5BLhaH33t_i94QS4XhsLhegbp3KgveBt0gzrgKq17zurNoijPnJVbzB2xUjwrnNS35wEcCnzYKImrrG2tpF0no6PGXR6QBqgIpWYmSc2ZrnK.
Wf_FzXpn3n_jM
– wordpress_test_cookie=WP Cookie check

If it is successful, you should be able to get following output:

Following cookie(s) have been set for this session:

– wp-settings-time-1618=1729629509

– cf_clearance=ua1SfOrrZEnBoisX2oyBqFCYbBKnD7_8NCbYGQR0I8U-1729629364-1.2.1.1-g.35KrDX7hs30EkIetQ1lRL.H4l8gliaPvUpnYwzADO2gmyq55AAsGhEuTNAW4WbFiorVysZfMeQF.SC0Wl_UhdqbkXkhNwNoc1u9Ad9Y7kb1PIYpI5LgtKWBHKQgcBCMhPfN3O83ToErdKgjVj33nAzckS1FaAOjHR4NguhgWu2N5_ZkiFc3ljkuBw4vNCwxA5ABlfgwgrwTtwzw0HnVf_b.X77dQeuRRblj5GCBCp3ytb_Slz.ronSMW15PNr8XmKB9R7MqJm35siYkUWVIp03GPFZL8uKbd8nULW_HCbZf8t51iWhGm2POLYc42Nvq7CAqGPIqO0EAqnjOV.7iAUhljfH9dRLlrHXWqV2Ag77Cm7wmZ0u7GuibK0SC

– wordpress_logged_in_43a808301508d09aba219a865ae484=admin|1729802176|lIg9Ct6h7Tc1AesngMVoLHdFBWckfrGjF5KnNXZg45p|d7496d3cc25498cd14de6d2c79cbfd7f17cf889dddaee1a3eef1b05d4b3f471

– cf_clearance=ua1SfOrrZEnBoisX2oyBqFCYbBKnD7_8NCbYGQR0I8U-1729629364-1.2.1.1-g.35KrDX7hs30EkIetQ1lRL.H4l8gliaPvUpnYwzADO2gmyq55AAsGhEuTNAW4WbFiorVysZfMeQF.SC0Wl_UhdqbkXkhNwNoc1u9Ad9Y7kb1PIYpI5LgtKWBHKQgcBCMhfN3O83ToErdKgjVj33nAzckS1FaAOjHR4NguhgWu2N5_ZkiFc3ljkuBw4vNCwxaA5ABlfgwgrwTtwzw0HnVf_b.X77dQeuRRblj5GCBCp3ytb_Slz.rohMnSMW15PNr8XmKB9R7MqJm35siYkUWVIp03GPFZL8uKbd8nULW_HCbZf8t51iWhGm2POLYc42Nvq7CAqGPIqO0EAqnjOV.7iAUhljfH9dRLlrHXWqV2Ag77Cm7wmZ0u7GuibK0SC

– wordpress_test_cookie=WP Cookie check

– wordpress_sec_43a808301508d09aba2e919a865ae484=admin|1729802176|lIg9Ct6h7Tc1AesngMVoLHdFBWckfrGjF5KnNXZg45p|1251994f5c9af5118ecda712c6fee9b7f8162d6cec76f55228788f88b48b2e

The scanner has determined the cookie: ‘wordpress_sec_43a808301508d09aba2e919a865e484’ to be the session token.

The session was verified via a regular expression check.

Another Web App Authentication Sample from Tenable doc:

https://community.tenable.com/s/article/How-to-Configure-Web-Application-Authentication-in-Tenable-io-WAS?language=en_US

Comments

Leave a Reply Cancel reply