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:

  • ^.*$

    permits everything

  • ^Key:\s*value$

    permits a specific key/value pattern

  • ^Content-type:\s*text/html$

    permits this specific content type

  • ^Cache-Control:\s*no-store$

    Ensures that the cache (mostly of a proxy) doesn't store a document after passing it on (useful for confidential information and all session data, e.g.)

(For details on the syntax, see Regular Expressions.)

error code

HTTP error code that vWAF returns if:

  • one or more of the header specified for the attribute headers are missing
  • a header doesn't match any valid header pattern
  • a header does match a valid header pattern but does also match an invalid header pattern

(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.