Simple Form Protection Handler

Purpose

The arguments of input boxes are frequently used to launch a security attack, e.g. for SQL Injection. The Simple Form Protection Handler prevents manipulated arguments from reaching your web application at all.

To do this, the Simple Form Protection Handler checks the attributes of the request (both in the URL and in an HTTP POST Request). An argument is only valid if it matches a predefined regular expression and at the same time does not match any of the regular expressions given under blacklist args.

If an argument is invalid, vWAF denies the request with a configurable HTTP error code.

ATTENTION
After configuring and activating the Simple Form Protection Handler, test the function of the input forms in your web application thoroughly once more to rule out unintended effects due to possible imprecise specifications.

- The Virtualize Form Field Handler performs a similar function but using a different method.
- 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

Use the Simple Form Protection Handler as a simple way to validate inputs. It can be used to protect email fields very easily, for example.

Advanced configuration options for protecting input fields are also provided by the Invalid Args Handler. A simplified alternative to protect form fields is also provided by the Protect Form Handler.

Attributes

Attribute Meaning

protected form fields

Here, enter the input fields that you want vWAF to monitor and the arguments that are permissible:

  1. In the left-hand column, select which methods are permissible: GET, POST, or both.
  2. In the center column, specify the exact name of the input field.
  3. In the right-hand column, select the type of input field: A field for entering an email address (email field), a field for entering numbers (numbers), a one-line, free text input field (single line input) or any other type of input field (other).

Each of the preconfigured types is based internally on a specific regular expression, against which vWAF checks the requests (for the syntax, see Regular Expressions):

  • other:

    .*

  • single line input:

    [ -~äöü]*

  • numbers:

    \d+

  • email field:

    *[_A-Za-z0-9-]+(\\[_A-Za-z0-9-]+)*@[A-Za-z0-9-]+(\\[A-Za-z0-9-]+)* *

protected form fields custom regex

In the same way as under protected form fields, here you can specify other form fields that can't be assigned to one of the preconfigured types (other, single line input, numbers, email field).

In this case, however, you need to create a regular expression yourself to clearly describe the input values.

blacklist args

Here you can specify a blacklist, in the form of regular expression, of which input values vWAF should always deny. This always relates to all entry fields, even to those that aren't explicitly specified in this handler.

If at the same time a specific character string is permitted according to the specifications under protected form fields or protected form fields custom regex, the blacklist has priority in any case of doubt, which means that vWAF denies a request of this type.

all other form fields

Here you enter which rules are to apply to all entry fields not given under protected form fields and protected form fields custom regex.

error code

HTTP error code that vWAF returns if it denies a request on the basis of the rules stored.

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