Get Started with Web Application Scanning

There are significant differences between scanning for vulnerabilities in web applications and scanning for traditional vulnerabilities with Nessus, Nessus Agents or Nessus Network Monitor. As a result, Tenable.io Web Application Scanning (WAS) requires a different approach to vulnerability assessment and management.

WAS Application Topology

WAS offers significant improvements over the legacy Nessus-based web application scanning policy:

  • The legacy scanning template for Nessus is incompatible with modern web application frameworks such as Javascript, HTML 5, AJAX, or single page applications (SPA), among others, which can potentially leave you with an incomplete understanding of your web application security posture.

  • WAS provides comprehensive vulnerability scanning for modern web applications. Its accurate vulnerability coverage minimizes false positives and false negatives to ensure that security teams understand the true security risks in their web applications. It offers safe external scanning so that production web applications do not experience disruptions or delays.

  • WAS uses region-specific cloud scanners. There is no need for more scanners if your web application analysis scope includes only publicly available assets. If your web applications are not public, your installation plan depends on where your web applications run and your organization's data storage needs.

Use the following sequence to configure and manage your WAS deployment:

  1. Prepare
  2. Install
  3. Configure Scans
  4. Refine

Prepare

Before you begin, familiarize yourself with Tenable.io Web Application Scanning basics to establish a deployment plan and an analysis workflow for your implementation and configurations.

Types of Web Application Scanning Programs

There are several viable ways to operate a web application scanning program based on dynamic application security testing (DAST) technology. Most programs use some combination of each approach to meet different needs for each site. The following list gives Tenable supported scan templates:

  • Scan: The complete set of available checks which includes all other pre-built templates, except for the API scan.

  • Overview: A simplified version of the “Scan” template without several active tests to lower its impact and speed up the scan.
  • PCI: A special template used as part of the attestation offering that Tenable provides for the payment card industry (PCI) security standard. Only submissions to attestation consume PCI licenses; otherwise, this template is a simplified version of the "Scan" template.
  • SSL/TLS: A health check scan focused on the current state of the web server encryption settings and certificate state (for example, the remaining time on the certificate).

  • Config Audit: A compliance audit that detects externally viewable web server settings that external audit providers commonly review to evaluate the health of a security program.

  • API Scan: A special template requiring more configuration to describe the application programming interface (API), so that the scanner can successfully detect relevant vulnerabilities This includes some similar tests in the “Scan” template but adds others unique to API endpoints.

Quick Surface-level Checks

You typically use the “SSL_TLS” or “Config Audit” scan templates to run a rapid test — often lasting only minutes — on a more regular basis than in-depth scans to give you an overview of surface-level checks such as any certificate-type and encryption-type issues with a given site or commonly exposed configuration parameters that are not best practice.

  • Untuned Detailed Scans: Without requiring tuning or refinement, this approach uses the “Scan” template to optimize detection of most vulnerabilities, and simulates drive-by style attacks that sites commonly experience. These scans deploy quickly and return valuable incremental visibility from the scan target while using basic validation to avoid obvious scan errors. However, this approach may run into timeouts (such as the eight-hour default in Tenable.io), or miss more complex sections of a site that requires authentication or fine-tuning for correct scans. These drawbacks are common with sites that have forums, blogs, large product volume, multiple languages, or a high number of pages.

  • Authenticated Detailed Scans: While similar to the Untuned Detailed scan, this approach uses authentication. You can do this in the scan configuration page or in the Chrome extension from Tenable. In addition to the benefits of an untuned scan, authenticated scans log on as a user to test for potential issues. Tenable recommends that you never log on as an admin user, especially in production (see the "Key Considerations" section). Authentication requires you to create and maintain the test user account and to update any unique site configurations.

  • Tuned Detailed Scans: In addition to authentication, you can use other methods to optimize scans for speed or complexity (see “Key Considerations”). These refinements involve an initial time investment before deployment and may require semi-regular adjustments depending on the frequency of the site updates.

Pre-production Scanning

To limit scanner impact on a production site and maintain 100 percent uptime, you can consider integrating scans using the Tenable.io API to trigger a scan based on a weekly or monthly build, or a pre-production location on a regular schedule. This protects the more exposed production site which may differ from internal builds. This scanning approach works to varying degrees with most mature organizations and often depends on-site criticality and resource availability.

API Scanning

Organizations are increasingly adopting APIs to power web applications, B2B transactions, mobile applications, and automation scenarios. You can assess these potential exposures by using the API scanning template within WAS to provide critical visibility into more cyber risks. In general, high risk and exposure are drivers for mature programs or organizations to scan APIs more frequently. Ultimately, as the security program develops, many organizations proactively identify all vulnerable locations to ensure full coverage. This type of scan can require more input from development staff and rely on an OpenAPI file to provide the endpoint definitions for the scanner to communicate to the API itself.

Decide Which WAS Program to Use

Most programs start with a few scans based on the “SSL_TLS” or “Config Audit” templates to familiarize vulnerability managers with how to establish scans and review results. Then, they progress into running an untuned scan using the WAS scan template.

Timeouts are common when you first build out your program. The default scan completion timeout in Tenable.io is eight hours, and extending this may not “complete” the scan; this may only be achievable via tuning for greater speed.

It is viable to run a program based on untuned scans while accepting the timeout. As many web application vulnerabilities span multiple pages containing the same vulnerability, it is likely that a scan automatically detects a significant proportion of vulnerabilities within the first several hours. Tenable's own monitoring can confirm this. Tuned scans typically improve scan efficiency and accuracy by only a small degree and cost more time to refine the scan configuration.

Most mature organizations tune scans on their most critical sites, which involve 10-20 minutes of effort per site and improves with operator experience. An organization’s level of knowledge and resource availability can determine the percentage of sites that undergo detailed tuning. It is rare to see all sites tuned, especially in organizations with many websites. This is due partly to the dynamic nature of websites; they often expand or change significantly every few years, and this requires a review of scan settings to adapt to the development pace of the test site.

  • Focus on the process first: Start with the WAS “Scan” (a complete set of checks) or an “Overview” scan (fewer checks but lower impact) templates. Familiarize yourself with the scanner output and work with your teams to incorporate the findings into your workflows. Develop your mitigation and resolution programs.

  • Dig deeper into critical areas: Once you have established some of the baseline procedures and identified the right owners within your organization for the output from the scanner, start investing time in more advanced-tuned scans to gain better visibility into your most important sites.

  • Take action: The scans return a significant amount of data to drive organizational action. Consider the potential consumers of the data. Developers want details to identify necessary fixes and improve over time. Management must know which sites contribute the greatest risk to the business, and thereby allocate resources. Security leadership needs general category information such as the OWASP vulnerability categories for all sites to focus on a specific classification of vulnerabilities.

Note: Tenable Professional Services offers a highly recommended quick-start program for new users of WAS scanning to help establish the mechanics of developing a new program. Also, the ProServe team runs a Cyber Exposure workshop to establish the internal processes and initial goals of developing a broader vulnerability management program. These services help organizations get a solid foundation and understanding of effective cybersecurity programs and familiarization with the product. Contact your Tenable sales representative at

Key Considerations to Optimize Your Scan Results

  1. Identify where the location of the web application:

    • Public Websites

      You can scan external websites from Tenable.io using the internet-based Web Application Scanner or an on-premises scanner.

    • Private Websites

      You can scan internal or intranet web applications from Tenable.io using an on-premises Web Application Scanner.
  2. Ensure that the scanner has a network route to the target:

    If the scanner cannot reach the web application, or cannot deliver an input and retrieve results, scanning fails. Network constraints such as latency can affect scanning or network controls (for example, host-based firewalls, network firewalls, network segregation, etc.). Always include internal web application scanners on your "allow" list.

  3. Scanner location can impact latency or server response times

    If there are too many timeouts during a scan, the session terminates. Choose a scanner located as close as possible to the targets. Review the sitemap plugin attachments to check for long page load times or timeouts. This can occur with too many concurrent tests on a slower server, a scanner that’s not close enough to the web application (such as scanning Australia from a US scanner), or the site setup that may lead to longer load times. Changing your scanner location can help to prevent readjustments for advanced settings that slow the scanner down. Counter-intuitively, slowing the scan speed settings can speed up results on a site that responds slowly, by lowering the rate of queries and adding less variability to the returned queries.

  4. The scanner acts as a user:

    The scanner can follow links, press buttons, and simulate the actions of a user based on what it can access. There can be undesired interaction on the site as a result of its site discovery phase. For example, if a user can send an email, the scanner can fill out forms and press the “send email” button potentially more than once. The scanner has no context for any specific button action, unless you teach it or exclude either the whole page or page element to prevent it from pressing a button unintentionally. (For more information, view our documentation on Scope Settings.) Keep in mind that excluding page elements to prevent such actions lowers the accuracy of the scan, so consider plans to scan sites like this in pre-production on a regular schedule.

  5. The scanner acts as many users:

    With its default settings, the scanner can operate as several users navigating the website at the same time. On servers with good capacity, there is typically minimal impact from this activity. However, if the state of the server is unknown, you can de-tune the speed of the scan — at least for the first test — to alert to any potential site impact from simultaneous sessions. For more details on configuring such a test, see Advanced Settings.

  6. Customize tuning for each site; it requires effort, but it is optional.

    Customized tuning generally applies to most websites because each web application is different. There are unique structures, sitemaps, third-party libraries, components, and custom code working together. Your investment in tuned scans depends on resource availability, criticality of the site, and impact to the business.

  7. When tuning for authentication, never run a WAS scan as a web site administrator in production – only in test or pre-production environments.

    Running a web application scan with administrator credentials could create or delete users, or perform other undesired administrative functions.

  8. When tuning for speed, a rudimentary understanding of your sites can help accelerate DAST scans.

    1. Review the sitemap plugin and associated file attachment.
    2. Configure your settings: Increase “Network Timeout,” or lower “Max Simultaneous Requests” and “Requests per Second,” if you experience significant page timeouts, or discover higher than five-second average page response times in the sitemap attachment.

    3. Consider speeding up your scan settings if you obtain sub one-second responses and only minimal impact to the web server.

    4. Deduplicate site content: The scanner does not test site text, image, and video content — only input fields and interactions. If you have redundant pages, such as a site that uses multiple languages but has the same underlying code, you only need to test one language version of the site.

    5. Add more binary exclusions: WAS does not “test” text, images, or videos and decide which file extensions to exclude. The scan scope section provides a default set that you can adapt for a specific site.

    6. Prioritize critical URLs: Identify the critical portions of the application, such as those ones forms that can return sensitive data. Add those URLs to the scope of your testing, either via “include” in the scan scope section or through manual crawl script. You can also consider whether these sites require testing in pre-production.

  9. When tuning for complexity, use session recordings to train the scanner.

    You can do this either by using the Tenable Chrome extension or Selenium IDE, and adding within the scope section of a scan configuration. With this process, you can perform manual crawling to ensure that the scanner can test a highly complex location within a site. For example, a site can require a specific series of button presses and a specific set of correct input values to reach a page that isn’t available any other way. You can record the steps to enable the scanner to play it back.

  10. Map out whether there is a web application firewall (WAF), web proxy, or load balancer between the scanner and the target:

    Som network devices can interfere with the scanning or completely invalidate the results. You may think it’s sufficient to receive only the “remote” view of results filtered by the firewall; however, it’s possible the WAF’s built-in protections only prevent one or two methods of executing the flaw. Gaining a full picture of the true state of the site is imperative to make risk-based decisions. Configure your WAF to support bypass functionality to allow specific IPs or a combination of IP and agent header strings to prove and authorize the incoming scan. A list of Tenable scanner IP ranges is available here.

  11. Some sites can require specific browser identities:

    Check whether the application is compatible with the default user agent (configured as “WAS/%v” by default). If not, it may need a specific or commonly available header from a standard browser, such as Mozilla/5.0. Some server-side protections or a web application firewall can require a specific set of results. In this case, you can copy the user agent string from a known browser that can access the site successfully.

  12. Target critical sites with greater care at the outset:

    Is the target site production-facing, or in any other way critical? What is the business impact if the web application scanner causes a service disruption? Always perform the first scan of a site in a controlled manner, either with staff on-hand or within a pre-production environment. Once you understand the nature of the site, you can begin full automation.

For more information and guided product walk-throughs, visit our Tenable Product Education YouTube channel. These short, instructional videos explain how to make the best use of WAS, including the authentication and tuning procedures mentioned above to help you secure your vulnerable web applications.

Install

  1. Preparation for Deployment

    1. Confirm requisite access to the Tenable.io platform and WAS application. Create users with appropriate access to Tenable.io Web Application Scanning for scanning and viewing of results. You can configure Role-Based Access Control (RBAC) to allow user access. You must have Administrative credentials for configuration.

    2. Determine whether you need a local scanner. You can deploy local or cloud-based scanners and connect them to Tenable.io. You can use these scanners on internet-facing web applications and development or pre-production environments (if suitable firewall rules apply).

      The Tenable Core + WAS scanner supports installation on VMware (.ova), Hyper-V (.zip), or a physical machine (.ISO). You can deploy it locally on-premises or within a cloud-based development environment to scan non-internet-facing web applications.

      You can download the local scanner here. Check that you have the following:

      • Outbound access to https://cloud.tenable.com via port 443 to communicate with Tenable.io.
      • Inbound access via HTTPS on port 8000 for browser access to the management interface.
  2. Identification and Planning

    1. Define the security objectives. Why are we scanning, what do we hope to achieve, and what does success look like?

    2. Determine scanning priorities. Identify which target web applications are within the scope of quick scanning and which require more detailed scanning.

    3. Ensure full coverage. Determine whether there are any other (possibly unidentified) web servers, services, or applications that you need to scan, and how to find them.

  3. Scanning, Tuning and Optimization

    1. Establish a baseline. Configure some quick scans to provide a high-level assessment of the target regarding component vulnerabilities, configuration audits, SSL/TLS templates, and web application vulnerabilities. For information, see Create a Scan.

    2. Achieve a more detailed view. Run a scan based on either the “Overview” or “Scan” template to get results that provide you with more detailed insight. Use this first scan to help tune if that’s part of your program:

      • Analyze the findings.

      • Use the sitemap crawled as an input to detailed scanning, tuning and optimization, reviewing for page timeouts, length of time to access a page, errors, or opportunities to remove repetitive content.

      • Review the “Scan notes” for any higher priority concerns, which may provide suggestions for scan improvement.

    3. Experiment with advanced settings. Perform scan tuning in a few locations based on the data gathered in the previous step. You can then update and deploy the scan for the targeted web applications. Click on the following relevant topic for further information on scan settings:

    4. Consider further custom adjustments. 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 complete and you can 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.

  4. Documentation

    1. Track everything. Produce and manage documentation that captures full details of the deployment requirements, deployed scanner resources (if applicable), web applications identified for scanning, and the tuning you applied to the scans with an accompanying rationale.
    2. Communicate your findings. Establish reporting requirements to identify: the recipients, the level of detail, and the frequency of the reports distribution. Developers may need PDFs, while ticketing systems require vulnerability details. Management often prefers a higher-level summary of overall exposure and risk reduction.

Configure Scans

After you prepare your analysis workflow and determine the scope of the web application assets, you can configure and run scans on those assets.

Tenable recommends that you first run high-level overview scans to help you determine the settings to configure for more in-depth scans.

Note: With a Tenable.io Web Application Scanning trial license, you can run up to five scans concurrently using your cloud scanners. You can run any number of scans concurrently using on-premises scanners.

To configure and run overview scans:

  1. Do one of the following:

    • To perform an overview scan to determine which web application targets Tenable.io Web Application Scanning scans by default, create a scan using the Overview scan template.
    • To perform an overview scan to determine if your web application is compliant with common security industry standards, create a scan using the Config Audit scan template.

    Note: The Tenable-provided scan templates for overview scans do not require authentication. However, the plugin results from these scans can help you identify the types of credentials your web applications require for more in-depth scans.

  2. Review the scan results, along with your scanning strategy, and determine which configuration settings you want to adjust when you run your standard web application scans.

To configure and run standard scans:

  1. Create a scan using the template that best matches your assessment needs:
    • To perform a comprehensive vulnerabilities scan, select the Scan template.
    • To perform a scan to determine if your web application appropriately implements SSL/TLS public key encryption, select the SSL TLS template.
  2. (Optional) Configure your scan settings, including user permissions, and plugin settings.

    Note: You can also configure your credentials options in standard scans. However, you need to add credentials only if your web application requires them for authentication.

  3. Launch the scan.
  4. Monitor the scan status.
  5. View and analyze your scan results.

Refine

Configure other features, if necessary, and refine your existing configurations.

To configure and refine your configurations:

  1. Further adjust your current scan settings, including user permissions and plugin settings.
  2. To add credentials to your scan, add the appropriate credentials type:
  3. To change basic scan settings, including the schedule, scanner used, or user permissions, adjust the Basic Settings in WAS Scans in the scan configuration.
  4. To widen or narrow the scope of URL targets your scan crawls, adjust the Scope Settings in WAS Scans in the scan configuration.
  5. To increase or decrease your scan intensity, adjust the Assessment Settings in WAS Scans in the scan configuration.
  6. To improve your scan performance, adjust the Advanced Settings in WAS Scans in the scan configuration.