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.
- simple - All login related fields are displayed at once, on one form
- wait_for_password - The password field is only displayed once the username is filled
- 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 byauthUsernameField
-
authUsernameField
- the form field that will be populated with theauthUsername
value -
authPassword
- the password that will be used to login (it will be used to populate the form field identified byauthPasswordField
-
authPasswordField
- the form field that will be populated with theauthPassword
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 withauthFormType
multi_page) -
authDelayTime
- Delay time, in seconds, to wait for the page to load after performing actions in the form. (use withauthFormType
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"