More information about target authentication fields and hacks
If your website has areas that require authentication, you may provide the DAST Scanner with credentials to log in to your website. By doing this, you’re enabling the DAST Scanner to run a scan that might reveal any vulnerabilities in deeper parts of your app.
It is recommended that you create a user for the tests since the DAST Scanner will submit forms and click buttons, which might “pollute” the account.
When a scan is started and the target has a login configuration, the first thing the crawler does is log into the application (web target) to obtain a session. Upon successful login, it will start crawling the app. While the crawler is running, it constantly verifies whether the session is still valid. Currently, this check is performed automatically based on the login configuration, but soon we will have the option to configure how the loss of session can be detected.
To enable authentication for a web target, you can go to the target’s Advanced Settings and select either Login Form or Login Sequence.
(applicable when the login form requires a username/email and password, which is a common use case)
To add authentication using a simple login form, go to the target’s Advanced Settings, then toggle on the “Login form” option. To simplify the configuration, we require the Login URL and at least one field name with its respective value.
For example:
https://example.com/ displays the login form, define https://example.com/ as the Login URL.https://example.com/ redirects to https://example.com/login, define either https://example.com/ or https://example.com/login as the Login URL.https://example.com/ or https://example.com/login redirects to a third-party authentication provider (e.g., https://example.auth0.com/?token=xyz), define https://example.com/ or https://example.com/login as the Login URL.We require the names and values of the fields. This refers to the value of the HTML input attribute name and the value that should be entered into the input. For example, for <input type="text" name="username" value="">, the field’s name should be username and you should provide the respective value.
It is now very common to find inputs without the name attribute; however, we also support the use of the id attribute or a CSS selector. For instance, <input type="text" id="username_id" value=""> - the field’s name can be username_id or #username_id.
Sometimes, it is only possible to use CSS selectors. For example, the app uses media queries, and there are multiple forms with the same input names and IDs:
<form name="mobile_login_form" action="/mobile_login_action">
<p>Username: <input type="text" name="username"></p>
<p>Password: <input type="password" name="password"></p>
</form>
<form name="login_form" action="/login_action">
<p>Username: <input type="text" name="username"></p>
<p>Password: <input type="password" name="password"></p>
</form>
In this case, use the CSS selector form[name="login_form"] input[name="username"].
The button to submit the login form is usually detected automatically. However, sometimes it is not clear which one should be clicked due to reasons such as:
<form>tag (a common scenario nowadays).To address this, we offer the option to define the button that should be clicked by adding to the login configuration:
submit_buttonCSS selector of the button> (this must be a CSS selector)check_loggedout<CSS selector of an element only visible when logged out> (e.g., form.login #username) or["CSS selector 1", "CSS selector 2"] (e.g., ["#form.login #username", "form.login #password"])To wait for a login input/element when the target has some unusual behavior while loading the login page, or to click on a button to go to the login page without the need for a login sequence:
1_wait<CSS selector of the element to wait for>2_click<CSS selector of the element to be clicked>(The prefixed number, specifies the order)
<form> tag, and the submit_buttonis not defined.1_wait to wait for a specific input (this issue can be particularly difficult to identify).If your login page does not have all the login credentials inputs in one page, for example, you have to enter an email then click next to enter the password, you can use a login sequence. It will record your actions and replay them during the scan.
To learn more about Cobalt’s Sequence Recorder browser plugin, check the Sequence Recorder page.
Once you have a sequence recorded, go to the target’s Advanced Settings, toggle on the “Login sequence option and then:
You can upload multiple sequences and enable only the one you want to use for the scan.
The DAST Scanner supports APIs with different authentication methods. You can set a fixed API key in a custom header or configure a login endpoint from which you obtain an authentication token.
You can also define custom parameter values that replace those found in the schema. This allows you to override example values or to ensure domain-specific values are properly filled.
To enable API authentication, go to the API target’s Advanced Settings and follow the steps in the form.
application/jsonapplication/x-www-form-urlencodedInstead of using the authentication method, you can also define custom headers to be sent with every request. This is useful when the API requires a fixed API key or other headers.
In this scenario, you have a fixed API key that must be placed in a specific parameter. To configure this option, proceed as follows: