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 Set mode of 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 → Vulnerabilities → Configure.

Creating and applying the rule¶

To create and apply the rule:

Create the rule Set mode of active threat verification in the 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/*).
Wait for the custom ruleset compilation to complete.

Rule example¶

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

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

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:

Header with the request authentication data to replace original authentication data with test data.
Header HOST. For example, the header HOST could be modified to replay the attack on staging or test environment.
Path to rewrite the application address used for the attack replaying.

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¶

You can create and apply the rule both in the Attacks and Rules sections of Wallarm Console.

In the Attacks section, rules are created with a pre-filled description of endpoints to apply the rule to. The endpoint description corresponds to the request you clicked the Rule button for.

To complete the rule setup, just select the rule action type and make sure all rule components are configured correctly.
In the Rules section, all rule components must be filled in manually.

To create and apply the rule in the Rules section:

Create the rule Rewrite attack before active verification in the Rules section of 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).
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'}}.
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'}}.