Skip to main content

Scan web applications

Use Dynamic Analysis in the Veracode Platform, or using the REST API, to test the security of your web applications. You can also integrate the analysis with your development pipeline. The scans crawl one or more URLs and analyze all components and assets of the application. The results identify the vulnerabilities you might need to fix.

For an improved experience, we recommend using DAST Essentials. See the quickstart.

Create an analysis​

Create an analysis in the Veracode Platform to specify the URLs to scan. Depending on the authentication requirements for accessing each URL, you can configure the scans as authenticated or unauthenticated. If your application is behind a firewall, and not accessible to the public internet, you must set up Veracode Internal Scanning Management (ISM).

You can also create an analysis using the REST API.

Before you begin:

note

Running Dynamic Analysis scans through a VPN is not supported.

To complete this task:

  1. In the Veracode Platform, select Scans & Analysis > Dynamic Analysis. The All Dynamic Analyses page opens.

  2. Select Scan Web Applications.

  3. Enter a name for the Dynamic Analysis. Use a name that uniquely identifies the analysis within your organization. For example, use the scan name, the team, or business unit responsible for this web application as the name of the Dynamic Analysis.

  4. Enter the URLs using one of the following methods:

    • Upload a CSV file that contains a list of multiple URLs (250 maximum). Download the CSV template, enter all URLs and their respective credentials, save the file, and upload the saved file.
    • Enter the URLs manually (250 maximum). As you enter the URLs, they appear in the URLs to Scan list.

  5. From Actions at the end of each URL row, you can link to an application profile or delete the URL from the Dynamic Analysis.

  6. In the Visibility Settings section, select the teams who can see the results of the analysis. Visibility settings apply to all URL scans in the analysis.

  7. Optionally, in the Organization Information section, select the business unit associated with the applications you are scanning and the name and email address of the person responsible for the applications.

  8. In the Scanning Certification section, you must select the checkbox to confirm that your organization has the right to scan the URLs you have provided.

  9. To configure the analysis, select Configure.

  10. To edit a specific URL configuration or configure authentication methods for accessing each URL, select at the end of URL row. If your analysis has several URLs, use the search box to find the one you want to configure.

  11. To link a URL to an application profile, select . With the results linked, you can access results from multiple scan types for the same application, and review aggregated results from all scans in the Dynamic Analysis Coverage Report.

  12. To create a blocklist of URLs to exclude from scanning, under Dynamic Analysis Blocklist, select Exclude the following URLs. Enter the filepath or directory path of the URLs you want to exclude from this analysis. If you enter a directory path, everything in that directory and its subdirectories are excluded. You must include the slash at the end of the URL for the analysis to consider it a directory instead of a file.

    For example, if you add a blocklist entry of http://example.com/help/, the configuration blocklists the /help directory and anything under it, including:

    • /help/page1.html
    • /help/page2.html
    • /help/more/page3.html
    • /help/more/page4.html

    If you add a blocklist entry of http://example.com/help, the configuration blocklists this single page and nothing else. The URL-level blocklist takes precedence over this analysis-level blocklist, therefore, any additional URLs you enter on the URL-level blocklist during this configuration step are also excluded.

  13. To ensure we can scan the entire application, select Allowlist and add the allowed URLs.

    By default, we scan all subdirectories under the top-level domain. Because we do not automatically scan the subdomains, you can include them in the scope of the scan by adding them on the Allowlist tab. To change the scope of the scan, add a subdirectory to a URL. For example, if you add https://api.example.com/mydir/v1, the subdirectory /mydir/v1 in the subdomain api is now in scope. If you want to scan all subdirectories under api, omit the subdirectory and add https://api.example.com. We recommend that you only add the specific subdirectories that you want to scan instead of adding the entire directory.

  14. Optionally, to configure a user agent that scans using a specific web browser, expand Dynamic Analysis User Agent. The user agent is a string of browser-specific text in the header that the scan engine uses during scanning. The agent string defines which browsers and devices you want to include in the scope of the analysis. If available, select the required browser. If the browser you want is not available, select Custom and enter the custom string. In the User Agent String field, use browser-specific formatting to add any additional custom text to the prepopulated string to identify the browser source.

  15. To schedule the analysis, including whether to run a prescan before running a full scan, select Schedule.

    By default, your Dynamic Analysis is not scheduled. To review the schedule of any Dynamic Analysis, select the clock icon in the row for that Dynamic Analysis on the All Dynamic Analyses page.

    To verify that the scan can successfully reach and, if required, authenticate with each URL, a prescan scans all URLs. You can schedule the analysis to run at a date up to 90 days in the future (60 days for internal scans).

  16. To submit the analysis, select Review and Submit. The analysis starts immediately or runs on the defined schedule.

  17. To see all scans and their statuses, go to the All Dynamic Analyses page.

Configure an analysis​

In the Veracode Platform, you can configure additional settings, such as the authentication methods that the scanners use to access each URL in the analysis.

Before you begin:

You must have created an analysis.

To complete this task:

To open the Configure page for a URL, in the URLs to Scan table, select Configure pencil_icon.png next to a URL.

URL Information​

Enter a starting URL for your scan, including any custom ports. Select the checkbox if you want to include both the http:// and https:// address in the scan.

The scan starts at this webpage and then searches the entire website. Choose a URL that enables the scan to crawl all the pages on the site and adheres to these rules:

  • You must precede URLs with http:// or https://
  • You must end directory names with a slash (/)
  • Acceptable formats are full hostname, such as http://www.example.com, or hostname and directory, such as http://example.com/dir/
  • Do not use wildcards in the target URL
  • You are not allowed to use wildcards in the Allowlist and Exclude URLs fields to include or exclude multiple pages or portions of a site all at one time
  • You can specify a page as a target URL, for example, http://www.example.com/dir/my_page

Directory Restrictions​

Select the dropdown menu to choose how to restrict the scan of the directories at the URL:

  • Directory and Subdirectories: allow the scan to crawl within the specified directory and any subdirectories, but not to crawl up from the starting point.
  • Directory Only: allow the scan to stay within the specified directory and not crawl up or down from it.
  • No Restrictions: allow the scan to crawl up and down from the specified directory.

Authentication​

If the URL doesn't require authentication, ensure Not required is selected (the default). If the URL requires authentication, such as sign in credentials, select Required and an authentication method. To see all authentication methods, expand Additional Authentication Options.

Auto Login​

This method is selected by default as it is the common method for most applications, including simple login forms that have a username, password, and login button. Auto-login also works for browser-generated logins, such as basic authentication and NTLMv2. For NTLMv2, you can include the NetBIOS domain separated from the username with a backslash, for example, DOMAIN\username. You can combine auto-login authentication with basic authentication.

You can use single sign-on (SSO) for this authentication method.

Login Script​

Record and upload a login sequence. The scans use the script to automatically sign in to your application. Use this method for multistep login sequences that contain one or more authentication methods, such as username, password, and PIN. You can also combine login script authentication with basic authentication. This is an advanced option that you only need to configure for complex sites on which auto-login fails.

If you use login script authentication and have uploaded a login script, you can download it at any time to verify its information. Go to the Dynamic Analysis Summary page and select the URL that has the login script. In the URL Configuration section, select the link in the Login Script field to download the file.

note

If you do not use Selenium, the scripts might not work.

An advanced use case you can use is the combination of login-script and basic authentication methods.

If your application uses a customized or complex form for its login, you can add login script authentication to auto-login authentication. You can also replace auto-login authentication with an explicit login script. You must record your login sequence script with Selenium IDE using supported Selenium commands. Save your JSON in the SIDE file format and upload it in the Login Script section. HTML file format is also supported, however, you must upload test suites in the SIDE file format. Optionally, you can also provide a logout script.

You can use single sign-on (SSO) for this authentication method.

Client Certificate​

If you want to scan an application that requires a certificate, upload the certificate and associated password so Veracode can access that application. The certificate file must be in PFX or P12 format, which follows the PKCS#12 standard. This standard stores the private key, leaf certificate, and intermediate certificates in one encrypted, password-protected file.

The PFX or P12 format is a private certificate that contains both the public and private keys required for encryption and secure authentication. You can generate a PFX or P12 file with the openssl pkcs12 -export command using your certificate (.crt or .cer) and private key (.key or .pem), or by using web-based tools.

A PKCS#12 container uses AES-256 encryption for stored keys and certificates (the PBES2 standard), SHA-256 for message authentication codes (MAC), and a high iteration count to strengthen password-based key derivation.

Generate a PFX or P12 file with OpenSSL​

The following method is common for command-line users and uses the OpenSSL utility.

To complete this task:

  1. Locate your certificate and key files. Make sure you have:

    • Certificate file (<filename>.crt or <filename>.cer)
    • Private key file (<filename>.key or <filename>.pem)

  2. Navigate to your OpenSSL installation directory if needed, then open a command prompt (or an OpenSSL command prompt).

  3. To generate the file, run:

    openssl pkcs12 -export -out <file-name>.pfx -inkey <path-to-private-key> -in <path-to-certificate>

  4. Enter and confirm a password when prompted for your PFX or P12 file.

Basic Authentication (Browser Generated)​

The basic authentication method provides information for a site that uses basic or browser-generated authentication where the browser prompts you for credentials in its own popup window. Enter the username and password you want Veracode to use. Optionally, you can enter the domain name. You can use this method alone or in combination with the auto-login or login script methods.

If your site uses both site uses both web page-based login (auto-login) and a browser-generated login (basic authentication/NTLMv2), but with different credentials for each method, you can use a combination of auto-login and basic authentication methods. This advanced use case is not typical. Veracode uses the username and password you enter for auto-login for web page-based login, and the username, password, and domain you provide for basic authentication is for browser-generated logins and NTLMv2.

You can use single sign-on (SSO) for this authentication method.

Custom HTTP Header​

HTTP headers enable the client to pass additional information with each HTTP request to the server. An HTTP header consists of its case-insensitive name followed by a colon (:) and by its value. The server ignores any whitespace before the value.

If your scan requires a specific HTTP header key-value pair to authenticate or correctly view the pages of your website, you can specify custom headers. Each custom header must contain a header name and a header value. You can specify any header name except header names that are forbidden to be specified programmatically, such as the cookie or host header.

The following header names are forbidden:

  • Accept-Charset
  • Accept-Encoding
  • Access-Control-Request-Headers
  • Access-Control-Request-Method
  • Connection
  • Content-Length
  • Cookie
  • Cookie2
  • Date
  • DNT
  • Expect
  • Feature-Policy
  • Host
  • Keep-Alive
  • Origin
  • Proxy-
  • Sec-
  • Referer
  • TE
  • Trailer
  • Transfer-Encoding
  • Upgrade
  • Via

If you specify a URL for matching purposes, the scan only sends the header to URLs and their subdirectories that match this specified URL. If you do not specify a URL, Veracode sends the header to the target URL listed in the Dynamic Analysis and any of its subdirectories.

You can use wildcards in the URL. For example:

  • https://www.veracode.com matches https://www.veracode.com/home, but not http://www.veracode.com or https://veracode.com
  • https://*.veracode.com matches both https://api.veracode.com and https://veracode.com

Add one or more HTTP cookies that the scanner can use to authenticate with the target URL. For Cookie, enter the cookie data. For example, mycookie=chocolate; domain=veracode.com. To add additional cookies, select Add Another.

Scanner Variables​

Configure scanner variables in the Veracode Platform to define information that you can reference in your login scripts for web application scans. The variables consist of a reference key and value. You typically create scanner variables that define sign in credentials you want to keep safe and reuse in multiple scripts.

To indicate that the variable defines a time-based one-time password (TOTP) secret for multifactor authentication, select TOTP seed. For more information, see Configure scanner variables.

Scan Controls​

Configure various settings for customizing scans for your applications.

Number of Concurrent Browsers​

In the Browsers field, enter the maximum number of browsers that can run Dynamic Analysis scan processes at the same time. The scan processes include crawling and auditing the URLs for your web applications. The value range is 1 to 12 and the default is 4.

note

Reducing the number of concurrent browsers can significantly increase the time for scans to complete.

Similarity Threshold​

Select a threshold to control which web pages the analysis ignores based on the similarity of the content on each page. Ignoring similar pages excludes them from the analysis results. The scanner compares each web page with the other pages it previously scanned to identify pages with similar content. It uses the selected threshold to determine which similar pages to ignore during the analysis.

For example, if the web application contains several similar pages, and you select Most Strict, the analysis is more likely to include these pages. If you select Least Strict, the analysis is more likely to ignore these similar pages and exclude them from the results. Depending on the number of pages and their size, an analysis with a more strict threshold might take longer to complete.

URL-Specific Blocklist and Allowlist​

Exclude URLs that you do not want the Dynamic Analysis to scan. You can also change the scope of the blocklist by excluding the HTTP or HTTPS versions.

By default, the Dynamic Analysis scan engine scans all subdirectories under the top-level domain. Because Veracode does not automatically scan the subdomains, you can include them in the scope of the scan by specifying them in the Allowlist tab. You can also change the scope of the URL scan by excluding the HTTP or HTTPS versions.

Crawl Script​

To ensure a comprehensive scan, you can upload a login script as an HTML file or SIDE (JSON format) file (<5 MB) containing a single script or test suite.

Internal Scanning​

If scanning an internal web application behind a firewall, select the ISM gateway and the associated endpoint that can access the URL.

If you select a gateway that is not associated with an accessible ISM endpoint, or the endpoint isn't ready for scanning, or you select an endpoint that is not reachable by the URL, the Dynamic Analysis fails.

Endpoints are identified as Ready, Pending, or Offline.

Gateway​

Select the gateway associated with an endpoint that can access the URL. If you select a gateway that is not associated with an accessible endpoint or is not ready for scanning, the Dynamic Analysis fails.

Endpoint​

Select an endpoint that can access the URL. If you select an endpoint that is not reachable by the URL or is not ready for scanning, the Dynamic Analysis fails. The scan identifies the endpoints as Ready, Pending, or Offline.

note

All of your configured gateways and endpoints are available for selection. If you do not know which gateways and endpoints are reachable by the URL, work with your ISM administrators to identify them.

Advanced Options​

On the Configure page for a URL, expand Advanced Options to see the following options.

User Agent​

Enter customized details of your browser to ensure the scan crawls for known vulnerabilities for that specific browser and returns information specific to the respective environment.

Custom Host​

If you do not want Veracode to perform a DNS lookup to obtain the IP address for the target host of your scan or if your target host does not have a DNS entry, you can enter one or more custom host-to-IP resolutions. Wildcards, slashes, or filepaths are not permitted. Private or internal IP addresses are only allowed if you have selected a gateway and endpoint in the Internal Scanning section.

Veracode can use several authentication methods to access your web application for Dynamic Analysis scanning. You can configure the following authentication methods in the Veracode Platform.

Use single sign-on for web application scans​

Veracode Dynamic Analysis supports single sign-on (SSO) systems using HTTP basic access authentication and HTML forms-based authentication.

Dynamic Analysis can support any SSO system, such as SAML and OAuth, that uses a browser-viewable, forms-based, or HTTP basic login method.

Single sign-on using HTTP basic access login​

Dynamic Analysis supports HTTP basic access authentication if Veracode can load the authentication URI without additional navigation, such as a popup window in a browser tab.

We recommend the following modifications to your default configurations:

  • Ensure that your target URL uses the URL for the SSO server, for example, sso.authserver.com, instead of the domain of the target application, for example, domain.com. This setting requests Veracode to test sso.authserver.com for any application layer software vulnerabilities.
  • Enter credentials in the Dynamic Analysis Basic Authentication tab.
  • Provide a crawl script that loads the domain of the target application, for example, domain.com.
  • Add the domain of the target application as an allowed host.

Single sign-on using forms-based login​

SSO systems generally prompt users using an HTML forms-based method, which is suitable for login scripting. Typically, the SSO system resides on a different domain than the target web application. For example, the SSO system resides on sso.company.com, and the target web application resides on domain.com.

We recommend the following modifications to your default configurations:

  • Use the domain of the target application as the target URL, for example, domain.com.
  • Add the SSO domain, for example, sso.company.com, under Allowed Hosts only if you also plan to include that domain in the scope for auditing.
  • Configure a login script to direct Veracode Dynamic Analysis from the target URL to the input login credentials on the SSO domain.
  • Add valid credentials.
  • Add a verification URL and verification text. We recommend using the HTML text found on the verification URL as the verification text.
  • If using Single-Page App (SPA) mode, configure a logout script that instructs Veracode Dynamic Analysis to log out of the customer web application.
note

We recommend that you do not include third-party authentication websites, such as Facebook Connect, Yahoo! ID, Twitter, and LinkedIn, in your Allowed Hosts.

Last updated on