Skip to main content

DAST Essentials authentication methods

Many web applications rely on some login mechanism to authenticate users. A full security scan of the application is usually only valid if you scan the whole application, including all internal areas. This section explains the different authentication methods, such as HTTP basic authentication, parameter-based authentication, OAuth 2, and SAML, to enable a scan of the entire web application.

This page provides guidance on setting up an API for scans.

Simple authentication methods​

DAST Essentials includes the following simple authentication methods.

HTTP basic authentication​

HTTP basic authentication, which is also known as .htaccess protection, is an authentication method where an authorization header with a base64 encoded username and password is sent to the server.

If an HTTP basic authentication protects your web application, use the global authentication setting in your scan target to configure the authentication by adding a username and password valid for your .htaccess form.

Form-based authentication / Standard login form​

If your application uses a standard HTML-based login form, you can use the application authentication table to create a working login for your application. To configure this correctly, you have to follow three simple steps:

  1. Enter the login URL in the Login URL field. The URL should ideally only contain the login form and should be a separate URL; if this is not the case, see the edge cases at the end of this chapter.
  2. Select Create Profile and create a new authentication profile.
  3. Select on the newly created profile on the left. You might have to do a refresh.
  4. Enter the username and password valid for the application.

Authentication use cases​

A collection of edge cases we have previously encountered to make it easier for you to configure the scans. For assistance, contact Veracode Technical Support.

Modal / Pop-up log-in​

  • Ideally, a specific subpage, such as www.example.com/login, contains the login form, or you can make one available. Then, the crawler can more easily log in.
  • If this is not the case, you can run a test, selecting the URL to select the button to open the login. In some cases, the crawler identifies the login correctly, and an authenticated scan can be conducted.
  • In case this is not possible, see parameter authentication

Log-in form is present on the main site​

  • Configure the main page as a login URL and start the scan.
  • If the login occurs in a modal, see the steps mentioned here
  • In case this is not possible, see parameter authentication

If you use a Consent Management Tool like Cookiebot on the application to be tested, either:

  • Disable the Consent Management Tool for the time the scan is running
  • Configure a token in the Global parameter authentication settings that disable the CMT from the pop-up (e.g., consent_cookie=1)

Additional input fields that are required for a login​

The crawler can detect additional input fields on the login form as follows:

  • Checkboxes (e.g., Agreement to T&C) will be checked if they are configured as checkboxes in the code
  • Drop-Down Menus: The Crawler will always select the first choice in a drop-down menu; ensure that the Credentials provided match the selection
  • Free-text fields: Ensure that these are prefilled with correct values when visiting the site. If they are not, the crawler will not fill in any matter, and the login might not be successful. In this case, see parameter authentication

2-Factor authentication​

If your web application uses some 2-factor authentication (e.g., SMS, authenticator app, etc.), DAST Essentials does not perform a login with a second factor. To still use the scanner successfully, you can use the following options:

  • Create a profile with users that do not have 2FA enabled and configure the login accordingly.
  • Disable the 2FA on the test/staging environment or a dedicated pentesting system.
  • For some cases (e.g., token-based authentication), there is potentially a way to bypass the 2FA. For assistance, please contact Veracode Technical Support.

Dynamically changing URLs​

In case your web application creates a dynamic login URL every time a user attempts a login, there are the following options for you to configure the login:

  • Create a page that automatically directs the user to the newly created login site; configure this in the login URL. The scanner follows the redirect and log in with the provided credentials on
  • Create a static login page
  • See parameter authentication

Parameter authentication​

This setting allows you to configure a more advanced authentication and should be used if the form-based authentication does not work. There are three main types of configuration:

  • HTTP Header: If you configure an HTTP header, the header will be sent with each request used for scanning the web application.
  • GET parameter: If you configure a GET parameter, the parameter will be added to each request as GET parameter when scanning the web application.
  • (Session) Cookies: If you configure a cookie, the cookie will be sent with each request used for scanning the web application.

Important points for parameter authentication:

  • Ensure that the lifetime for tokens/cookies is long enough for the scan to run through entirely (at least 24hrs)
  • For Javascript-based applications: Ensure you configure all additional information your application uses to verify authenticated users. This can include
    • Session storage
    • Local storage
    • Custom Cookies / Tokens
  • Depending on your setup, you can configure parameter authentication on a global or per-user profile level. However, do not configure it in the global and user settings, leading to conflicting results.
  • DAST Essentials does not support cookies/tokens/headers to be renewed during the scan. However, they can be generated automatically before every scan (see the next chapter)

Configure parameter authentication​

  1. You choose the parameter type (for an explanation, see above).
  2. You can give the parameter a title/identifier so other users in your team understand its meaning.
  3. Parameter Key: configure the exact key/phrase authentication for your application. For example, this could be "Authorization," "Authentication," or your customer identifier.
  4. Parameter Value: configure the exact value used by your application for the authentication.
    1. An authorization header should usually contain Bearer (unique Identifier).
    2. A cookie should usually contain the attributed session ID.

Advanced authentication methods​

You need to implement the login using a custom script to retrieve the authentication information for the advanced authentication methods, such as a session ID stored in a cookie or a JWT token.

SAML​

SAML (Security Assertion Markup Language) is an XML framework for exchanging authentication and authorization information. When using a SAML workflow, you need a script (CLIENT) to log in using your identity provider (IDP) and generate a session with the application that shall be scanned, the service provider (SP), and the handover of the credentials to DAST Essentials.

When writing your login script, complete the following steps:

  1. The CLIENT visits the IDP login page for the SP.
  2. The CLIENT provides credentials to the IDP.
  3. IDP generates the SAML response and sends it to the CLIENT.
  4. CLIENT posts the SAML response message to the SP.
  5. SP authenticates the user based on the assertion and provides session information (e.g., session cookie)
  6. CLIENT sends a request to DAST Essentials to start a security scan, including the session information

To send the information to DAST Essentials (step 6), you can use webhooks. You can also set the session manually for a target.

OAuth 2​

OAuth 2 (Open Authorization) is a protocol that offers a secure and standardized API authentication. With an OAuth 2.0 workflow, a client gets an access token from an authorization server (AS) used to authenticate with the software that shall be scanned. For OAuth 2, several different authentication flows can be used. A simple one is the Resource Owner Password Credentials Grant flow. Create a login script (CLIENT) that does the following:

  1. CLIENT sends a request to the AS to generate an access token.
  2. AS sends an access token to the CLIENT.
  3. CLIENT sends a request to DAST Essentials to start a security scan, including the access token.

To send the information to DAST Essentials (step 6), see use webhooks. You can also set the session manually for a target.

If you have any questions about SSO authentication, contact Veracode Technical Support.