The rule Disable/Enable request parser allows you to manage the set of parsers applied to the request during its analysis.
By default, when analyzing the request, the WAF node attempts to apply each suitable parser to each request element sequentially. However, certain parsers can be applied mistakenly, causing the WAF node to detect (false) attack signs in the decoded value.
For instance, the WAF node might incorrectly interpret unencoded data as being encoded into Base64, given that Base64 alphabet symbols are frequently found in regular text, token values, UUID values, and other data formats. If the WAF node decodes the unencoded data and identifies signs of attack in the resulting value, a false positive is registered.
To avoid such false positives, the Disable/Enable request parser rule can be used to turn off parsers that are incorrectly used on certain request elements.
The rule can be both created and applied within the Attacks and Rules WAF sections.
To create and apply the rule in the Rules section:
1. Create the rule Disable/Enable request parser in the Rules WAF section. The rule consists of the following components:
2. Wait for the rule creation to be completed.
Suppose the requests to https://example.com/users/
necessitate the authentication header X-AUTHTOKEN
. The header value might include specific combinations of symbols (like '='
at the end) that WAF could potentially decode using the Base64 parser.
You can configure the Disable/Enable request parser rule to prevent false positives in the USER-AGENT values as follows:
The WAF node transmits the following information to the WAF cloud:
Certain information should not be sent outside of the server where it is processed. This generally includes authorization details (like cookies, tokens, and passwords,) personal data, and payment information.
The WAF node can mask data in requests. Using this rule, the original value of the specified request point is removed before the request is sent to the postanalytics module and the WAF Cloud. This approach ensures that sensitive data does not unintentionally leave the secure environment.
This rule can impact the visibility of attacks, the verification of active threats, and the identification of brute-force attacks.
Here's an illustration of such rule creation. First, use the instructions above. The rule applies if the following conditions are specified in the If section:
example.com
PHPSESSID
cookie for user authenticationTo create a data masking rule for this cookie, the following actions should be performed in the Then section:
1. Go to the Rules tab.
2. Find the branch for example.com/**/*.*
and click Add rule.
3. Choose Mask sensitive data.
4. Select the Header parameter and enter its value COOKIE
. Select the cookie
parameter and enter its value PHPSESSID
after in this part of request. Options sequentially selected (if several) in this part of the request should reflect a sequence of parsers that WAF would apply to read the required request element.
5. Click Create.
In certain situations, it's beneficial to add a signature for attack detection manually or create a virtual patch. While WAF doesn't employ regular expressions for attack detection, it does permit users to supplement with additional signatures that are based on regular expressions.
Click the Create regexp-based attack indicator rule and fill in the fields:
Regular expression: This is the signature used. If the value of the subsequent parameter aligns with the expression, the request is identified as an attack. The syntax and specifics of regular expressions are detailed in the instructions for adding rules.
Changing the regular expression specified in the rule: If you alter the regular expression in an existing Create regexp-based attack indicator rule, any Disable regexp-based attack detection rules using the previous expression will be deleted automatically.
Note: To disable attack detection by a new regular expression, create a new Disable regexp-based attack detection rule specifying the new regular expression.
Experimental: Test the trigger of a regular expression securely without blocking requests. Even when the filter node is in blocking mode, requests won't be blocked. These requests will be viewed as attacks detected via the experimental method and will be hidden from the event list by default. They can be found using the search query experimental attacks
.
Attack: The type of attack that will be detected when the parameter value in the request matches the regular expression.
in this part of request: Determines the point in the request where the system should detect corresponding attacks. If multiple options are selected sequentially in in this part of the request, they should represent the order of parsers that WAF would use to read the necessary request element.
Here's an illustration of such a rule. The rule applies if the following conditions are specified in the If section:
example.com
USER-AGENT
headerTo create a rule for rejecting incorrect format tokens, specify the following in the Then section:
1. Go to the Rules tab.
2. Find the branch for example.com/**/*.*
and click Add rule.
3. Select Define as an attack on the basis of a regular expression.
4. Set Regex value as ^Malicious-Actor$
.
5. Choose Virtual patch as the attack type.
6. Set the USER-AGENT header.
7. Click Create.
The rule Ignore certain attack types allows you to disable the detection of specific types of attacks in certain request elements.
By default, if the WAF node detects signs of any type of attack in any element of a request, it labels the request as an attack. However, some requests that contain signs of attacks are actually legitimate. For instance, a request to publish a post on a database administrator forum might contain a description of a malicious SQL command, but it's not an attack.
If the WAF node mistakenly identifies a standard request payload as malicious, a false positive is registered. To avoid such false positives, customize standard attack detection rules by adding custom rules. The Ignore certain attack types rule is an example of such a custom rule.
Here's an illustration of such rule creation. First, use the instructions above.
Let's consider an example where a user confirms the publication of a post on a database administrator forum. The client sends a POST request to the endpoint https://example.com/posts/
. This request has specific properties:
postBody
. This content may incorporate SQL commands that WAF could potentially flag as malicious.application/json
type.Here's an example of a cURL request containing an SQL injection:
curl -H "Content-Type: application/json" -X POST https://example.com/posts -d '{"emailAddress":"johnsmith@example.com", "postHeader":"SQL injections", "postBody":"My post describes the following SQL injection: ?id=1%20select%20version();"}'
To disregard SQL injections in the postBody
parameter of the requests to https://example.com/posts/
, the Ignore certain attack types rule can be configured in the following way:
The rules Allow binary data and Allow certain file types are used to adjust the standard attack detection rules for binary data.
By default, the WAF node analyzes incoming requests for all known attack signs. During the analysis, the WAF node may not consider the attack signs to be regular binary symbols and therefore may mistakenly detect malicious payloads in the binary data.
To adjust the attack detection rules for the binary data passed in the specified request elements, create the rule Allow binary data in the Rules WAF section.
The rule consists of the following components:
To adjust the attack detection rules for certain file types passed in the specified request element, create the rule Allow certain file types in the Rules WAF section. The rule consists of the following components:
Let's consider an example where a user uploads a binary file containing an image using a form on a website. The client sends a POST request of the type multipart/form-data
to https://example.com/uploads/
. The binary file is included in the body parameter fileContents
.
The Allow binary data rule, which fine-tunes attack detection in the fileContents
parameter, is configured as follows:
Was this article helpful?
Discover the all-in-one Web security solution by Gcore