Protect Form Handler
Purpose
The Protect Form Handler only has an effect when the Session Handler is also active. In detection mode, the Protect Form Handler is ignored.
The arguments of input fields are frequently used to launch attacks, e.g. for SQL Injection. The Protect Form Handler provides a simple, automated way to prevent manipulated arguments from reaching your web application at all.
To do this, the Protect Form Handler automatically scans all responses for hidden and protected form fields. By doing this, the handler automatically learns what these fields usually contain. It signs all fields so that it can verify their contents. If the handler later detects any suspicious discrepancy in a request, it denies this request with a configurable HTTP error code or redirects to a preset page.
To be able to work, the Protect Form Handler automatically inserts a special hidden protected form field into the web application. The handler then uses this form field to validate the output of the web application. For details regarding encrypting form variables in POST requests, see Virtualize Form Field Handler.
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 Protect Form Handler if you want to add basic automated protection to your forms.
Advanced configuration options for protecting input fields of forms are also provided by the Invalid Args Handler and by the Simple Form Protection Handler
Attributes
Attribute | Meaning |
|---|---|
content types | Specify the content types of requests that vWAF should check against the learned behavior. |
unique id | Key for the hidden protected form field vWAF inserts into the web application. You can change this if you want it to meet your specific conventions, usually, however, you can keep the default, which is _UNIQUE_ID_. |
redirect on deny | Enable this option if you don't want vWAF to deny a request if it finds an unprotected form field, but instead to redirect the user to the page stated under mainpage. |
mainpage | Page to which the user is redirected when the option redirect on deny is enabled. It's sufficient to specify the subdirectory here. Example: / |
error code | HTTP error code vWAF returns when it denies a request. |
max forms | Maximum number of protected forms and URLs per page. You can limit this number in order to prevent the internal session storage of vWAF from growing too large. You should only change the default of 1024 if you encounter any problems. |
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.