Baseline Protection Handler

This helps protect your application against null byte injection attacks (where injection of null byte characters can alter user-supplied data and gain unauthorized access to system files). If enabled, arguments that include a zero byte are rejected.

This check is applied for each decoding step, if 'multiple decoding' is enabled (see below).

The keys specified here are excluded from the Baseline Protection Handler ruleset. This allows you to exclude specific keys from the baseline check, such as a user-defined text field for example.

Regular Expressions can be used.

To remove a key, delete the entry in the Regex column. The key is removed when you save the handler updates.

If a request is denied, vWAF logs the pattern (of the attack). This option instructs vWAF to continue to check the request against other attacks, despite identify an attack already.

This option is not required or recommended in general. However, it maybe useful when testing a new application to check which rules produce false positives. During this testing phase, you may accept a trade performance at the expense of logging more results, to review and eliminate false positives.

This determines whether or not arguments are treated as case insensitive or case sensitive. It is a global setting and applies to all arguments. Unless your baseline protection ruleset includes case sensitive arguments, it is recommended that this is set to case insensitive. However, if you require support for case sensitive arguments, you need to set this option to case sensitive.

By default, the Baseline Protection Handler checks the values of requests for the patterns given under rules, but not the keys. For example, if you have a request such as http://host/foobar?key1=value1&key2=value2, the Baseline Protection Handler checks value1 and value2.

If you enable the option apply patterns to keys, the handler checks both values and keys. This may be important, for example, where a web application processes requests in the form: http://host/foobar?something. In this example, something is not recognized as a value but as a key; therefore, apply patterns to keys must be enabled to ensure something is checked.

By default, the Baseline Protection Handler does not check URL parameters, such as PARAMETER in the URL http://host.domain/path1;PARAMATER/path2?foo=bar. If you enable the option apply patterns to url parameter, the handler checks URL parameters.

This option is only required if your application uses URL parameters. If you do not use URL parameters, it is recommended that the option is disabled.

This determines the upper limit for the variable size. If the variable size of a request is greater than this value, vWAF does not check the request for the given patterns.

Checking requests with a variable size of more than 10KB can have a negative impact on performance.

The value is entered in Bytes and the default is 2048.

If enabled, vWAF denies a request if its variable is bigger than max variable size.

Optional: This is only applicable if reject if oversize is enabled.

If reject if oversize is enabled, vWAF denies a request if its variable is bigger than max variable size. However, the oversize key exclusion list allows you to specify keys that are exempt from the max variable size limit. This may be required to allow specific large uploads, for example.

Regular Expressions can be used.

If configuring these options, it is recommended that before you activate your ruleset in protection mode you first run the application in detection mode to gather enough information to evaluate the log files and to confirm that the settings are not denying valid requests.

To remove an entry, delete the entry from the edit field. The entry is removed when you save the handler updates.

vWAF is able to detect multiple encoding evasion attempts. The values specified in the Decoding Steps column determine how many times vWAF attempts to decode the specified arguments, headers, and URIs requests. After each decoding, vWAF applies the rules once more.

The check continues until one of the rules match or when the handler has processed all Decoding Steps without finding a match.

If the Reject option is enabled, vWAF attempts to decode one more time. If decoding is possible and the decoded data differs from previous attempts, vWAF denies the request (without further checks).

The more decoding steps, the more processing time is required. To avoid a negative impact on performance, only specify the maximum number of steps required for your web application.

Determines the maximum amount of time (in milliseconds) that vWAF processes each rule. If pattern matching takes longer than the specified time, vWAF aborts the check.

The default value is 100 ms.

If a check is aborted due to exceeding the match timeout time, the next action depends on the attribute reject if match timeout settings:

• If the option reject-if-match-timeout is enabled, vWAF denies the request.
• If the option reject-if-match-timeout is disabled, vWAF continues by matching the request to the pattern of the next rule.

Determines whether requests are denied if pattern matching takes longer than the match timeout allows.

Defines the types of attacks that are covered by baseline protection. Each baseline rule belongs to one of these categories.

In order to simplify the ruleset and to optimize performance, you can disable a category provided your web application is not vulnerable to this kind of attack, or you configured other handlers to provide adequate protection.

Depending on your category selections, particular rules are automatically removed from the rules list.

If your web application does not use a particular technology, you can select the relevant tag to remove all rules that are specific the particular technology. This simplifies the ruleset and optimizes performance; the appropriate rules are automatically removed from the rules list.

Before disabling an entry ensure that the application does not use the corresponding technology.

Rules are added automatically by vWAF when you run the Baseline Protection Wizard or when you enable additional options for categories and tags.

If a request matches one of the rules, vWAF denies the request with the specified error code.

You can enable and disable rules and view rule details. However, you are not able to change individual parameters.

To view rule details, click the arrow icon.

To enable/disable a rule, click the traffic light symbol to toggle the status. A green light indicates the rule is enabled, a red light indicates the rule is disabled. vWAF only checks requests for the patterns of enabled rules.

You can view and if applicable reset the inheritance for each rule. Rules are configured by the Baseline Protection Wizard. However, it is possible to disable rules individually using the Baseline Protection Handler. If a rule is disabled using the Handler, the rule inheritance state changes from Inherited to Local.

If your web application does not use a particular technology, you can use the tags attribute to remove all rules that are specific the particular technology. This is more efficient than disabling rules individually. Similarly, if your web application is not vulnerable to particular kind of attack, you can use the categories attribute to remove the corresponding rules.

Defines the HTTP error code that vWAF returns when a request matches one of the patterns specified by the rules. (For an overview of possible error codes, see HTTP Error Codes.)

Optional:

You can specify text to be appended to log file entries created by this handler. For example, you could provide a brief description explaining how this handler is utilized in your deployment.