SOOS currently supports 5 ways to run an authenticated DAST scan. Always make sure to properly protect the credentials used to authenticate by ensuring they are stored in a secure key store.

The examples below are specific to calling the Docker script directly, review the SOOS CI/CD system documentation for specific CI/CD system parameters.

OAuth token URL

If you are performing a DAST scan against an OAuth application use the following to allow SOOS to perform a request to get the access_token before executing the analysis.

Example:

--oauthTokenUrl="https://example.com/token" 
--oauthParameters="client_id:value, client_secret:value, grant_type:value"

Use a Bearer Token

If your application uses a bearer token to authenticate you can pass a valid bearer token using the bearerToken parameter. This will pass “Authorization: Bearer <token>” on each request. Note: do not include the “Bearer” text, only the token value.

Example:

--bearerToken="<my-bearer-token>"


Pass Custom Headers

If your application uses a non-bearer token authentication value or custom authentication header/value, you can pass a custom header using the requestHeaders parameter.

Example (one header):

--requestHeaders="'authorization:<my-auth-key>'"


Example (multiple headers):

--requestHeaders="'authorization:<my-auth-key>, custom-header:<my-value>'"


Set Cookies

If your application relies on cookies for authorization, you can pass cookies using the requestCookies parameter.

Example (one cookie):

--requestCookies="'my-cookie:my-cookie-value'"


Example (multiple cookies):

--requestCookies="'my-cookie:my-cookie-value, my-second-cookie:my-second-cookie-value'"


Login using a Form

If your application does not have a long running auth token or cookie that you can rely on, you can opt to configure the script to fill out and submit a login form before each test is performed.

For this type of authentication we support 3 different variants of login forms that can be configured through the parameter authFormType.  Please note that forms that use a captcha are not supported.

  1. simple - All login related fields are displayed at once, on one form
  2. wait_for_password - The password field is only displayed once the username is filled
  3. multi_page - The password field is only displayed after the username has been entered and submit/next button has been clicked to navigate to a second form.

Parameters:

  • authLoginURL - the URL to the login page

  • authFormType - simple, wait_for_password, or multi_page

  • authUsername - the username that will be used to login (it will be used to populate the form field identified by authUsernameField

  • authUsernameField - the form field that will be populated with the authUsername value

  • authPassword - the password that will be used to login (it will be used to populate the form field identified by authPasswordField

  • authPasswordField - the form field that will be populated with the authPassword value

  • authSubmitField - the form element name/ID which is used to submit the form.

  • authSecondSubmitField - Second submit button ID to use in auth apps (use with authFormType multi_page)

  • authDelayTime - Delay time, in seconds, to wait for the page to load after performing actions in the form. (use with authFormType wait_for_password and multi_page)

Example:

--authLoginURL="https://example.com/login"
--authFormType="wait_for_password"
--authUsername="my-user"
--authPassword="my-password"
--authUsernameField="userName"
--authPasswordField="password"
--authDelayTime="7"
--authSubmitField="login"