Product
Pricing
Resources
Docs
Product
Pricing
Resources
Docs

Setting up dynamic testing

The method for configuring the authentication of the test site can differ from test tool to test tool. Some test tools allow you to set up a profile on the tool itself that handles authentication - for example, some tools allow you to log into the tool, record a 'macro' that lets the tool log into the site, and then allow that macro to be replayed during automated testing by specifying the recorded profile. Other tools will ask for more details, such as the login page, test usernames and passwords, and allow you to set default headers, etc.

At the very least, the Uleska Platform will request you complete the 'Version Name' and 'Url' configurations for dynamic testing.

It should be noted that the security tool industry does not have a common way to feed URL, authentication, and other important information into security tools. There are efforts underway in the industry to fix this, but until such a standard comes about and is adopted by all dynamic tools, wrapping dynamic testing into automation will always require a bit of setup and trial and error.

If you wish to create a version (testing stage) that is to run DAST (Dynamic Application Security Testing) tools, then you can configure this in the Uleska Platform.

  • Go to your Application, click to Edit the Version. This will take you to the 'Version' tab. If you do not have a version configure yet, then go to your Application and click 'Add Version'.
  • Start by giving your version a 'Version Name' that will be meaningful and can be used to reference this version (testing stage) in the UI, API, and CLI.
  • Configure the 'Url' to be the main URL of the website or service that is going to be tested. Include scheme, host & domain name, and any specific ports, such as "https://mytest.server.com:8080". If the service is running on the default ports (i.e. port 80 for http schema, or port 443 for https schema, then a port does not need to be specified).

DynConn

The Uleska Platform then allows you to configure a number of authentication modes and technical details to facilitate security tools conducting authenticated security scans of your sites.

There are three forms of authentication modes currently supported in the Uleska Platform. As mentioned other tools may also facilitate authentication through their profiles and recorded macros.

Basic (or Form Based) Authentication

To configure your security scanning stage for Form-Based Authentication:

  • Select the 'Basic Authentication / Form'
  • If not on the default page for your site, enter the 'Login Path' where login details are actually sent. For example, a user is presented with the login form (i.e. username, password fields) on [https://my.site.com/mainpage/](https://my.site.com/mainpage/) and their entered credentials are then sent to [https://my.site.com/login/](https://my.site.com/login/) then enter "/login/" for the 'Login Path'
  • Many form-based logins differ in the format of the POST body they send. Some are simple, others use JSON, and other formats exist. To let the security tools know how to pass the username and password to the site, enter the 'Login Template'. For example, if your site sends the form based credentials as "username=JohnDoe@sample.com&password=mypassword" then enter "username=<<username>>&password=<<password>>" for the Login Template. The values wrapped in << >> will be replaced by the Uleska Platform later with credential values.
  • Some websites require certain headers to be passed to allow requests to be processed. Many dynamic security tools allow you to configure those headers to facilitate successful testing. You can add these to the Uleska Platform (which subsequently passes them onto the dynamic tools) by entering them into the 'Required Headers' field. The entries here are header names and values, separated by new lines.
  • As an alternative to authentication credentials, if the target site uses cookies for session management and your testing setup can use pre-ready cookies (either from one-off testing where you have already logged in on a test account, or during automation where a stage previous to the call for Uleska testing has such session cookies) then these cookies can be supplied in the 'Required Headers' field and you can set "Force Cookies' to Yes which will tell the Uleska Platform to run dynamic testing tools without login, but with the existing session information. This is where the dynamic testing tool supports such functionality.

basicauth

Google Toolkit

Alternatively, you can use Google Toolkit authentication if that is what the target site uses.

  • Set the 'Authentication Mode' to "Google Toolkit"
  • Then enter the client key in the 'Authentication Key' field. This is supported using the Uleska Platform UI and API, however this mode of authentication is not currently supported in the CLI.

Googleauth

Key Cloak

If the target site is using Key Cloak for authentication then:

  • Set the 'Authentication Mode' to "Key Cloak"
  • Enter the path to the Key Cloak token issuer endpoint
  • Enter the Client Id used for the Key Cloak system

keycloadauth

Configuring Credentials

If your authentication mode requires login usernames and passwords to be passed, these can be set under the 'Roles and Users' tab. In this tab you can set credentials for multiple roles, which facilitates the Uleska Platform to call dynamic tools multiple times (once per role).

The reason for doing this is if your dynamic site has varying pages or functionality available to different roles. Think of a system that has standard user roles and an admin role. Typically the admin role would see very different pages and functionality from the standard roles. Testing with one role would not provide coverage of all the endpoints of the site and may leave vulnerabilities undiscovered.

  • Enter a descriptive name for the 'Role Name'
  • Enter a description that will help communicate what type of role this is.
  • Enter the 'Username' that will be passed to the authentication credentials of the site.
  • Enter a 'Password' for the site. Note this will typically be a test user account, on a non-production instance of the target being tested.
  • Click on 'Save Role'
  • Enter another role configuration if required. Once all needed roles and credentials are entered, click 'Save' to save all roles.

roles