Invalid Request Handler
Purpose
The Invalid Request Handler checks requests for invalid specifications of:
- HTTP method
- URI
- Argument
- Parameter
- Header
- Body
If a request matches one of your given patterns, vWAF denies the request with a configurable error code.
For more information regarding adding and editing Handlers, see Editing Handlers.
Severity
Events triggered by this handler are given the severity: high. (For details on severity levels, see Severity of Events Triggered by Handlers).
Recommendations for use
The Invalid Request Handler is primarily intended to be configured by some Wizards, such as the Vulnerability description Import Wizard. There are a number of specialized handlers that run similar checks, but mostly provide a broader scope of functions. You should prefer these handlers if you configure handlers manually.
- The answer to the question which handler is executed first, depends on the sequence in which the handlers are listed on the tabs Global Handlers / Handler Templates / Handlers of the administration interface. Handlers listed on top are always executed first. The order is preconfigured and can’t be changed.
- A special characteristic of the Invalid Request Handler is that you can add a comment to each specified pattern and that you can disable individual patterns temporarily without having to delete them. Also you can exclude requests with a minimum content size from the check.
Attributes
Attribute | Meaning |
|---|---|
max variable size | Checking requests with a variable size of more than about 10KB can have a negative impact on performance. For this reason, max variable size defines an 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. The value must be entered in Bytes, the default is 2048. |
reject if oversize | When this option is enabled, vWAF denies a request if its variable size is bigger than max variable size. |
reject if oversize exception | Optional; only has an effect if reject if oversize is enabled: When the option reject if oversize is enabled, vWAF denies a request if its variable size is bigger than max variable size. reject if oversize exception allows you define a list of keys for which this does not happen. A typical scenario, for example, is to exclude big uploads from the check. ATTENTION To make the optimum choice here, requires some good knowledge of your specific web application. Before you actually activate your ruleset in protection mode, we recommend that you first run it for some time in detection mode and evaluate the log files whether actually no wanted requests are denied. |
case insensitive | Enable this option if you want the regular expressions entered below to be case insensitive. This can simplify the expressions if you want to handle capital letters and lower case letters identically. |
patterns | Here you can enter additional, individual patterns for which vWAF should deny all requests with the specified error code. The input field initially displayed is used for comments only. Here you can give each pattern a descriptive name and document why you've added the pattern. To edit a pattern:
To enable / disable a pattern: Click the traffic light symbol next to the input field for the pattern description to toggle the status. A green light indicates an enabled pattern, a red light a disabled one. vWAF only checks for enabled patterns. |
error code | HTTP error code that vWAF returns when the request matches one of the specified patterns. (For an overview of possible error codes, see HTTP Error Codes.) |
usertext | Optional: Here you can specify some text that vWAF adds to the log file entries created by this handler. You can use this, for example, to document why you've added the handler to your configuration, and how the handler is intended to behave. |
enable logging | Disable this option if you do not want vWAF to create a log file entry when the handler is executed. This can be useful to keep log files smaller in case the handler creates a large number of entries but you don't need these entries. When in detection mode, disabling logging de facto makes the handler ineffective. Disabling logging also prevents the actions of the handler from being taken into account for the Top-10 lists in Attack Analysis, and from being listed in Reports. To decrease the size of the log files, also consider to enable reduced logging, which excludes all non-handler-related information from the log files (see Editing Applications). |
For details regarding entries added to the log file by this handler, see the relevant section in Entries in Application-Specific Log Files.