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:
-
Header with the request authentication data to replace original authentication data with test data.
-
Header
HOST
. For example, the headerHOST
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 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:
-
Proceed to Wallarm Console → Rules → create the Rewrite attack before active verification rule.
-
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
anduri
. No other values are permitted.
-
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'}}
.
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'}}
.