Creating Authentication

Suggest Edits

📘

Before following the instructions below, ensure that your application and authenticated resources are accessible to the Bright engine, either directly from the Internet or via a Repeater.

Configuring authentication

  1. From the menu in the left pane of the Bright app, select Authentications.
  2. In the Authentications pane, click + Create Authentication.

  1. In the Create authentication dialog, fill in the fields as described below.
  2. After filling in all the necessary fields, in the right-bottom corner of the Create Authentication dialog, click Create.

📘

Note:

  • The Create authentication window contains three tabs: Details, Setup, and Logout Indicators. Use the menu in the right pane of the dialog to switch between the tabs.
  • All mandatory fields are marked with an asterisk (*).
  • Bright allows testing a scan before saving it. For details, see the Testing Authentication section below.

📘

Note:

To target all the requests/responses for the authentication flow regardless of the total number of stages or redirects, use theany_stage reference.

For example, {{ auth_object.any_stage.headers | get: 'test_name' | match: /sid=(.+)/ : 1 }}will allows Bright app to go all over the requests of the authnetication flow, including redirects and will return the last match.

The Details tab

Details

Specify the details of the Authentication Object you want to create.

FieldGuidelines
Authentication nameEnter the authentication object name
DescriptionEnter the authentication object description. For example, you can specify the application type or other information that helps you distinguish your created object.
ProjectSelect the project to attach an Authentication Object

Protected resource details

Provide the details of the authentication-protected resource.

FieldGuidelines
ProtocolFrom the dropdown list, select the HTTPS or WebSockets (currently under development) protocol to be used for authentication
MethodSelect the HTTP method of an active tester end-point (authenticated resource)
Validation URLEnter the URL of the authenticated (protected) resource to test if the authentication scenario is configured correctly. The validation URL should be different from the authentication URL.
Merge StrategySelect whether the specified header must be replaced or appended with the provided value before sending each request
NameSelect an additional header to be replaced or appended before sending each request, for example, Authorization
ValueEnter the header value
BodyEnter the HTTP request body to be sent in the request sent, for example: {“user”: “foo”, “pass”: “bar”}
Maximum number of redirects to followEnter the maximum number of redirections that Bright should follow during the authentication process

Pro Tips: Select the checkbox Change redirected method to get for the redirects with code 302, where the server expects the following methods to always be GET during redirects and not the original method that triggered the redirect
WebSocket frame payload extractor regexPattern to extract the correct payload object, such as JSON, out of WebSocket frames that may contain some auxiliary service data (such as prefix, suffix, etc.). The regex pattern must be specific to extract ONLY the actual payload object.
XPath to the request identifier fieldXPath to the request identifier field (e.g. correlationId)
RepeaterIf you use a local Repeater to reach the scan target, select it from the dropdown list to connect it to the scan.

The Auth flow setup tab

This tab allows setting authentication details.

From the Authentication type dropdown list, select the necessary authentication type, and then proceed to the authentication details. For information on how to fill in the fields for the selected authentication type, follow the relevant link below.

Valid authentication types

Deprecated authentication types

For more information on each authentication type, see Authentication Types.

The Re-auth triggers tab

This section contains the options to be used during the application scanning to determine if the authentication flow is no longer valid and the authenticated resources cannot be reached. The options define how the application responds in case the authentication flow fails.

FieldGuidelines
Response statusSelect the checkbox and then enter the HTTP response status that will tell you about the authentication failure.
Header patternSelect the checkbox and then enter the header name and Regex pattern that will help you identify the authentication failure. For example, you can use a simple Regex pattern, such as index.
Bode patternSelect the checkbox and then enter the body pattern that will help you identify the authentication failure. For example, this Regex pattern detects a body looking for a UUID in a sessionId parameter: sessionId: \"\\b(uuid:){0,1}\\s_([a-f0-9\\-]_){1}\\s\*\".
Page patternSelect the checkbox and then specify CSS selector(s) or inner text selector(s) that match page element(s) to be used as logout indicator(s).
Request URL patternSelect the checkbox and then enter the URL pattern that will help you identify the authentication failure.

The Advanced tab

This tab is created to configure OTP-generation settings. OTP is a reliable way to increase the security of an application by adding one-time passwords. It is often used in combination with a regular password as an additional tool for user authorization. Bright provides the possibility to use a Time-Based One-Time Password (TOTP) and a Hash-Based One-Time Password (HOTP) in the authentication flow.

📘

Note:

This tab is only available for Browser-Based Form Authentication and Custom API authentication flow.

To configure an OTP correctly, follow the steps below:

  1. Create an Authentication Object using Browser-Based Form Authentication or Custom API authentication flow
  2. Open the Auth flow setup tab and insert the {{otpToken}} to all places needed. The Bright engine will interpret this placeholder into an existing token.
    1. Bright allows users to add this token to the following fields:
      1. URL
      2. Body
      3. Header Value
    2. For BBAO it is allowed to put the {{otpToken}} into the Value field. The Name field should match your example.

      📘

      Note:

      The case, spelling, and curly braces are all significant and required — the correct notation is {{otpToken}}.

  1. Go to the Advanced tab and select one of the OTP options:

  1. No OTP - no OTP is selected, set by default
  2. Time-based one-time password (TOTP) - a temporary passcode generated by an algorithm that uses the current time of day as one of its authentication factors
  3. Hash-based one-time password (HOTP) - Hash-based message authentication code, based on a counter. See the Troubleshooting page to learn how to adjust the HOTP server.
  4. Google Authenticator (TOTP) - time-based one-time password is a time-based OTP, the most popular algorithm used by Google Authenticator.
  5. Enter the following parameters to continue:

  1. Secret key - a key that is provided by the target website and used to generate the OTP

    📘

    Note:

    When configuring the Google Authenticator OTP, the input key is often separeted by spaces. These spaces must be deleted before inserting the key in the Secret key field.

  2. Number of digits - a number of digits (from 1 to 8) used to generate the OTP's length
  3. Token duration - a time (in seconds) after which an OTP is regenerated (this option is only available when TOTP is selected)
  4. Algorithm - an encryption algorithm, that contains three types of the cryptographic hash function, which produces a 160-bit, 256-bit, and 512-bit hash value accordingly.

Once everything is done, click on Test OTP generation to check everything is set up correctly. Generated code can be used for OTP adjustment on a target site/service.

Testing authentication

Preliminary authentication testing helps you verify if the authentication object has been configured correctly. This allows you to reveal the configuration issues timely, before running a scan.

To test your authentication object, at the bottom of the Create authentication dialog, click Test authentication.

The application displays the test results in a separate Test results tab.

  • A valid authentication object returns three success messages indicated in the relevant Test results sections:
    • Test Authentication Triggers provides the test request and response data.
    • Authentication call (fillForm #) provides a screenshot of the form filled by the engine per stage.
    • Authentication call (submitForm #) provides a screenshot of the authenticated page as evidence of the successful login.
    • Authentication call (Check Post-Login URL) provides a screenshot of the post-login URL as evidence of the successful login.
    • Access Protected Resource provides the test request and response data.

In this case, you can save the configured object and add it to your scans.

  • If the test results include a failure message, go back to the object configurations and verify their correctness. Use the test request/response data to find a certain failure and fix it.

📘

Note:

The Bright engine only supports the set-cookie headers that are less than 4097 bytes. If the received header exceeds this limit, the engine will ignore the header and will not include it in the request/response data. Breaking the limit may also cause authentication object failure.

Updated about 1 month ago