Required Header Field Handler
Purpose
You can specify a list of HTTP headers that must be present in each request. You can use this to differentiate simple scripts from “real” browsers, for example.
If one or more of the specified headers is missing, or if a header doesn’t match any valid header pattern, or if a header matches an invalid header pattern, vWAF denies the request with a configurable error code
ATTENTION To create anonymity, some proxies have a host header filter function, which garbles or removes HTTP header fields such as browser string (User Agent). A Required Header Field Handler with a definition that’s too restrictive may exclude users who access your web application using proxies of this type.
ATTENTION The Required Header Field Handler can’t offer completely full protection due to the nature of the HTTP protocol. A skilled attacker can simulate the behavior of a legitimate user by modifying the HTTP header accordingly. The Required Header Field Handler is therefore appropriate primarily for protecting against slightly less sophisticated attacks or to prevent undesirable access attempts by known spiders.
For more information regarding adding and editing Handlers, see Editing Handlers.
Severity
Events triggered by this handler are given the severity: low. (For details on severity levels, see Severity of Events Triggered by Handlers).
Recommendations for use
To simplify configuration you can also carry out the basic setting in the Anti Spider Wizard initially. The minimum headers required are already preconfigured there. Then edit the Required Header Field Handler for the specific path if required.
Attributes
Attribute | Meaning |
|---|---|
headers | List of required headers. |
case sensitive | When enabled, the entries that you specify for invalid header pattern and for valid header pattern are case sensitive. Usually, this is not needed but only makes your regular expressions more complicated. So, by default case-sensitivity is not enabled. |
invalid header pattern | Blacklist of regular expressions describing the pattern of invalid header fields. For example, you could use this to exclude certain content types. (For details on the syntax, see Regular Expressions.) For details on priority and internal processing, see How Blacklists, Whitelists, and Graylists Are Processed. |
valid header pattern | Whitelist of regular expressions describing the pattern of valid header fields. For details on priority and internal processing, see How Blacklists, Whitelists, and Graylists Are Processed. Examples:
(For details on the syntax, see Regular Expressions.) |
error code | HTTP error code that vWAF returns if:
(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.