Docs
These docs are for v1.1. Click to read the latest docs for v1.2.

Configuring Form Authentication

Suggest Edits

❗️

Deprecation notice

The Form authentication type is deprecated. Your existing authentication objects of this type are currently working, and later will be converted in to the Custom API authentication objects automatically.

You can use the form authentication if the login-protected resources within the application you want to scan use
the application/x-www-form-urlencoded content type of the HTTP requests.

The form authentication type is set by default when you create an authentication object in the Bright app.

📘

Note

This topic describes only how to fill in fields specific for form authentication (the Setup tab). For general steps, see Creating Authentication.

📘

Note

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 the Repeater.

From the Authentication type dropdown list, select Form authentication, and then proceed to the authentication setup.

Authentication setup

In this section, set up a valid authentication request to be sent to the end-point API by completing the provided fields.

1402
Field Guidelines
URL Enter the relevant URL for the HTTP request. The POST method is set by default for the form authentication.

Pro Tips:
  • This is not the URL where the login form resides, but the URL where the form request is sent to. The form host URL can be the same as the request URL, but can be different as well. You can get the Request URL in the Headers section of the relevant login request.
  • Form login type will encode any URL-encoded values as required by the protocol, this means that values (user, pass) should be entered without encoding to avoid double encoding issues.
Parameter name Enter the form parameters from the request body. For example, username and password.
Parameter value Enter the values of the form parameters (credentials) from the request bodies.
Maximum number of redirects to follow Enter the maximum number of redirects that the 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.
Additional headers (Optional) Select an additional header you need to use for each request and enter its value. For example, additional cookies that might be needed for the authentication such as host-related metadata.
To replace or append the selected header before sending each request, select the corresponding option from the Merge strategy dropdown list.

Pro Tips:
  • Make sure that the values you use for the additional headers are static and must not be changed between scans.
  • If your application uses cookies that are set via the Set-Cookie header in the response, then you do not need to extract and reuse the cookies. Any Set-Cookie header will be automatically used during authentication.
  • There are cases when MFA is required ONLY on initial IP login. This means that our scan IP can be validated once and will not require any further MFA validations. For that case, you need to identify which cookie supports the completed MFA/2FA and include a valid cookie as a part of your authentication object, typically using the Additional Headers field.
  • You can add as many parameters as you need by clicking + Add item at the bottom of the Parameter Name & Value section.
  • To delete a parameter, click next to the corresponding parameter field.

Valid authentication response

In this section, select the options you want to use during the application scanning to determine that the authenticated resource has been reached. The options define how the application responds in case a full authentication flow passes successfully.

1556
Field Guidelines
<Detect using Response STATUS Enter the HTTP response status that will tell you about the authentication success.
Detect using Response HEADER pattern Enter the header name and Regex pattern that will help you identify the authentication success.
Detect using Response BODY pattern Enter the body pattern that will help you identify the authentication success.

Authentication triggers

In this section, select the options you want to use 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.

1410
Field Guidelines
Detect using Response patterns Select if your application explicitly indicates the authentication session expiration in the body or headers, or using status codes.
  • Detect using Response STATUS
 Enter the HTTP response status that will tell you about the authentication failure.
  • Detect using Response HEADER pattern
 Enter the header name and Regex pattern that will help you identify the authentication failure.
  • Detect using Response BODY pattern
 Enter the body pattern that will help you identify the authentication failure.
Detect using Request patterns Select if your application does not provide any explicit indication in the body or headers when the session expires, but the client-side code redirects you to the login page, for example, based on absence of cookies or cookies expiration. In this case the only way to detect the re-login requirement is by detecting the redirect to the login URL.
  • Detect using Request URL pattern
 Enter the URL pattern that will help you identify the authentication failure.

📘

Note

Bright allows testing a scan before saving it. For details, see the Testing Authentication.

Updated over 1 year ago

What’s Next