For Browser Based Form Authentication, if a stage is still executing, the prior one doesn't immediately start

Cause

An intermediary stage can be added to allow the prior stage to fully complete before initiating the following stage.

Workaround

For example, if Stage 1 takes twenty seconds to complete, you can add an intermediary WAIT-stage after Stage 1 before proceeding to Stage 3. In the Auth Flow Setup, at the end of any Stage, click Add Stage → Standby → Wait for ... Seconds

Recording created with Google Chrome recorder is not replayed with the Evaluation failed error

When replaying the recording, an error appears: Evaluation failed. TypeError: Failed to execute ‘observe’ on ‘IntersectionObserver’: parameter 1 is not type ‘Element’…

Cause

Google Chrome cannot find the element by one of the selectors.

Workaround

1. Expand the step where the error appears.
2. Click “-” against the affected selector to delete it.

3. Replay the recording.

4. If the replay is encountering the same errors, repeat steps 1-2 till the replay is successful.

Recording created with Google Chrome recorder is not replayed because UID was changed

Some web applications specify a UID in the element name. Since web applications are frequently releasing new features, UID might change, which will cause the authentication object not working.

Solution

Remove the UID from the recording to create a generic authentication object that would work even if a new web application is released.

1. Expand the step containing UID.
2. Delete the UID.

📘

Note

For creating recording, see Configuring Recorded Browser-Based Form Authentication.

Surface discovery

• Response statuses include:
  • NexPloit::Session::AuthFlow::Error
  • 401
  • 405
• Percentage of problematic statuses out of the total responses >10%

• The authentication object is configured incorrectly.
• The wrong authentication object is selected for the scan.
• The scan requires more than one type of authentication object.
• Some specific entry points may need different authentication parameters (like HMAC headers).

• Create an authentication object that follows the design and flow of authorization within your web application. Bright has different types of authentication objects that can be used in scans. For detailed information, see our documentation - Authentication Types.
• Check the configuration of the exiting authentication object. For example, if you are using a Custom API Authentication object, check the validity of the regex and validate if your authorization data is correct. You can find more about regex in our documentation - String Interpolation Syntax.
• Check if there is a need for an HMAC script for additional authorization (if more headers are needed). In the Repeater script, you should specify how exactly the server calculates the HMAC code to allow Bright to provide a valid HMAC token. Bright can reach targets ONLY after a successful HMAC authorization with the relative server. For more information, see our documentation - Using Repeater Scripts.

📘

Note

If you need help with this issue, contact our support at [email protected] or via Intercom at the bottom right of the Bright app.

An authorization flow can not be done successfully

While adjusting the TOTP in the authorization flow, sometimes the process can not be done successfully. An error will be shown at the step with OTP.

Solution

Try to change the type to Google Authenticator or vice versa.

How to set up the HOTP server counter

While using HOTP, a configured authentication server that will not increase the number of HOTP counters after each successful one-time iteration is needed.

Solution

To do this, the start counter on the server must be 0. Thus, the counter will increase by 1 after creating the first code and binding it to the server. Next generated codes will use the counter value = 1 on both the server and the Auth object.