Skip to content

Customizing the module for active threat verification

Custom ruleset allows changing the following configurations of the Active threat verification module:

  • Disable the module for the whole application or its part (only if the module is enabled for all applications in Wallarm Console → Scanner).

  • Rewrite the request before attack replaying.

Disabling / Enabling the Active threat verification module

Rule overview

The rule Disable/Enable active threat verification is used to change the Active threat verification module mode for the specific applications, domains or URLs if this module is enabled globally in Wallarm Console → Scanner.

Creating and applying the rule

To create and apply the rule:

  1. Create the rule Disable/Enable active threat verification in the Profile & Rules section of Wallarm Console. The rule consists of the following components:

    • Condition describes the endpoints to apply the rule to.
    • Disable / Enable sets the mode of the Active threat verification module for attacks sent to the specified endpoints.

      Please use the mode Enable only to configure exceptions for the rule disabling the module (e.g. to enable the module for https://example.com/module/user/create if it is already disabled for https://example.com/module/user/*).

  2. Wait for the custom ruleset compilation to complete.

Rule example

The rule Disable/Enable active threat verification disabling the Active threat verification module for https://example.com/module/user/* looks as follows:

Example of the rule "Disable/Enable active threat verification"

If the rule above is already configured, the following rule will enable the Active threat verification module for https://example.com/module/user/create:

Example of the rule "Disable/Enable active threat verification"

Rewriting the request before attack replaying

Rule overview

The rule Rewrite attack before active verification is used to modify the original request elements before the attack replaying. The following elements can be modified:

Modification of any original request element

The rule Rewrite attack before active verification allows modifying of only headers (header) and paths (uri) of the original requests. Other request elements cannot be modified or added.

Replacing original authentication data with test data

If authentication parameters were passed in the original request, the module Attack rechecker deletes these parameters and replays the attack without them. If authentication parameters are required to access protected application API, the code 401 or other code will be returned in the response to the replayed attack. Since returned code shows no vulnerability signs, the module Attack rechecker will not detect the vulnerability that could be actually detected with authentication parameters passed in the request.

To replay the original requests with required authentication parameters, you may add test values ​​for these parameters using the Rewrite attack before active verification rule. For example: API key, token, password or other parameters.

Reusing test authentication data

It is recommended to generate test authentication credentials that will only be used by the Wallarm module Attack rechecker.

Modifying the application address for attack replaying

By default, replayed attacks are sent to the application address and path passed in the original request. You may replace the original address and path with other values that will be used when replaying the attack. Values are replaced using the Rewrite attack before active verification rule in the following way:

  • Replace the original value of the header HOST with a different application instance address. For example, a separate application instance could be a staging or test environment.

  • Replace the path of the original request with the path to the test environment or staging, or to the path to the target server to bypass the proxy server when replaying the attack.

To replace both the value of the HOST header and the path of the original request, you'll need to create two separate rules with the action type Rewrite attack before active verification.

Creating and applying the rule

To create and apply the rule:

  1. Create the rule Rewrite attack before active verification in the Profile & Rules section of the Wallarm Console. The rule consists of the following components:

    • Condition describes the endpoints to apply the rule to.
    • Rules sets the new value for the parameter selected in the Part of request field. A set value will be used when replaying the attack.

      The value must be decoded and set using the template language Liquid as follows: placed in double curly braces {{}} and single quotes ''. For example: {{'example.com'}}.

      To replace the path of the original request (uri), you should pass the full value of the new path.

    • Part of request points to the original request element that should be modified before replaying the attack.

      Possible values of the field Part of request

      Possible values of the Part of request field are header (request header) and uri (request path).

  2. Wait for the rule compilation to complete.

To set several conditions for the original request modification or to replace the values of several request elements, you may create several rules.

Rule examples

  • When replaying the attacks sent to example.com, pass the value PHPSESSID=mntdtbgt87j3auaq60iori2i63; security=low in the COOKIE header.

    The format of the header value is {{'PHPSESSID=mntdtbgt87j3auaq60iori2i63; security=low'}}.

    Example of the rule modifying COOKIE

  • Replay attacks originally sent to example.com on the test environment example-test.env.srv.loc.

    The format of the address is {{'example-test.env.srv.loc'}}.

    Example of the rule modyfying HOST