Skip to content

Rewriting Requests Before Attack Replaying

You can modify the requests used by the Wallarm's Active Threat Verification module for attack replay. This can be particularly useful when replacing original authentication data with test data or conducting attack replays on alternative addresses. This guide provides instructions on how to achieve this.

By default, the module retains the original request data, except for stripping specific authentication parameters. The Rewrite attack before active verification rule is used to modify the original request elements before generating test attack set based on them. The following elements can be modified:

Modification of any original request element

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

Creating and applying the rule

To create and apply the Rewrite attack before active verification rule:

  1. Proceed to Wallarm Console → Rules → create the Rewrite attack before active verification rule.

  2. Fill in the rule creation form following the instructions:

    • If request is specifies 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. Ensure this element is present in original requests as original values will be substituted.

      Possible values

      The only acceptable values for the Part of request field are header and uri. No other values are permitted.

  3. Wait for the rule compilation and uploading to the filtering node 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

Replacing original authentication data with test data

Your application's APIs might require authentication. However, since the module strips this data before replaying attacks, vulnerabilities may go undetected. To address this, consider creating specific authentication parameters for active threat verification when this data is passed in request headers. This approach not only grants the necessary access but also lets you control and secure the replay process.

To furnish the replayed requests with necessary authentication details, 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.

For instance, the following is the rule to ensure attacks replayed on example.com carry 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

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 will need to create two separate rules with the action type Rewrite attack before active verification.

For instance, the following rule sets the module for 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