Configure Browser-Based Form Authentication

You can grant NeuraLegion access to the login-protected parts of your application by specifying the form fields as you see them on a web page and the credentials you need to enter in the relevant fields. Using this data, NeuraLegion can fill in the browser form the same way you would do that and get access to the protected pages automatically.

The browser-based form authentication is only applicable to the application/x-www-form-urlencoded content type of the HTTP requests.

Prerequisites

  • You are an active user in the NeuraLegion App.
  • Your application and authenticated resources are accessible to the NeuraLegion engine, either directly from the Internet or via a Repeater.

Step-by-Step Guide

  1. Go to the NeuraLegion App.
  2. In the left pane, select Authentications.
  1. On the My Authentications page, click + Create Authentication.
  1. In the CREATE & TEST AUTHENTICATION dialog box, complete the fields of the following configuration sections.

Authentication Details

In this section, specify the details of the authentication object you want to create.

Field Guidelines
Authentication name Enter the authentication object name.
Description (Optional) Enter the authentication object description. For example, you can specify the application type or other information that helps you distinguish your created object.
Authentication type From the Authentication type drop-down list, select Browser-based form authentication.

Authentication Setup

In this section, set up a valid authentication request to be sent to the end-point API. For that, complete the Authentication Setup fields.

Field Guidelines
Form page URL Enter the URL of the page where the form is located.
Field labels Enter the labels of the fields as they are given on the form page. For example, email and password.
Values Enter the values of the form parameters (credentials).
Maximum number of redirects to follow Enter the maximum number of redirections that the Nexploit 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 to each request, select the relative button below.

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.
  • For some parameters, you can add more fields by clicking at the upper-right of the relevant setup section.
  • To delete a parameter, click next to the relevant Value field.

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.

Field Guidelines
Detect using response status Enter the HTTP response that will tell you about the authentication failure.
Detect using header pattern Enter the header and Regex pattern that will tell about the authentication failure.
Detect using body pattern Enter the body pattern that will tell you about the authentication failure.

Valid Session Tester

The preliminary testing helps you verify if the authentication object has been configured correctly.

Field Guidelines
Protocol From the drop-down list, select the HTTPS or WebSockets protocol to be used for authentication.
Method Select the HTTP method of an active tester end-point (authenticated resource).
Validation URL Enter 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.
Header name Select an additional header to be appended to the request sent to the tester end-point.
Header value Enter the template of the expected value (interpolation string) created using the String Interpolation Syntax.
Body Enter the HTTP request body to be appended to the request sent to the tester end-point, for example:{“user”: “foo”, “pass”: “bar”}’. You can interpolate the body using the String Interpolation Syntax.
Maximum number of redirects to follow Enter the maximum number of redirections that Nexploit 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.
Repeater If you use a local Repeater to reach the scan target, select it from the drop-down list to connect it to the scan.

Once you have completed the Valid Session Tester fields, click Test Authentication.

  • A valid authentication object returns four 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.
    • Authentication call(submitForm) provides a screenshot of the authenticated page after a 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.

Did this page help you?