Version: 8.2411.x.x RR

InputValidationFilter

The task of the InputValidationFilter is to perform a validation of the incoming requests. This validation is done on the HTTP layers; namely the HTTP headers and the HTTP body can be checked. The InputValidationFilter therefore provides mechanisms to perform the checks according to configurable rules.

As the InputValidationFilter outgrew itself in complexity, we recommend using separate filters for the same functionalities:

For the most common OWASP attacks, you can use the ModsecurityFilter.
For request and response header validation, you can use the HeaderValidationFilter.
For parameter validation, you can use the ParameterValidationFilter.

If it is possible to solve a given use case with one of the filters mentioned above, it is strongly recommended doing so (instead of using the InputValidationFilter).

A configuration rule has the following format:

[RuleID:<ruleId>:][ DecodingRules: <comma-separated list of rules>:<regexp>

The RuleID allows defining a unique id for the rule. This ID will be traced in the log file when there is a match. This allows an easy correlation between a configured rule and the log file.

The DecodingRules configure a chain of decoding functions which is applied to the pattern prior to matching.

The regexp part is the rule itself. Check Regular expressions for more information.

While normally new-line and white-space delimiters are supported, the following attributes only support new-line delimiters.

ContentTypesAndLengths
FileNameBlackList
FileNameWhiteList
HeaderBlackList
HeaderWhiteList
QueryBlackList
QueryWhiteList
URIBlackList
URIWhiteList

Classname

ch::nevis::isiweb4::filter::validation::InputValidationFilter

Library

libInputValidationFilter.so.1

Default RequestFlags

+NEEDS_PARAMS +NEEDS_FORM_MULTIPARTS +NEEDS_GWT_PARSING

Configuration

AllowedHeaders

Type: Colon separated list of Strings
Usage Constraint: optional`

A colon separated list of permitted header fields. If a request contains a header that is not in this list, it gets blocked. If nothing is configured, all header fields are allowed.

AllowedMethods

Type: Colon separated list of Strings
Usage Constraint: optional

Defines the allowed HTTP methods (GET, POST, HEAD, ...). If not configured, all HTTP methods are allowed.

BlockOnError

Type: Boolean
Usage Constraint: optional
Default: true

Defines whether a request is blocked (answers with an HTTP 403 Access forbidden response) if a configured rule has been broken. Otherwise, a message is traced. The parameter RemoveInvalidHeader can override this parameter for header validation. For more details see the description of the RemoveInvalidHeader parameter further below.

MaxBlockedPerSession

Type: Integer
Usage Constraint: optional, advanced

This parameter allows to define a maximum number of requests blocked by the InputValidationFilter during a session. If the maximum is reached, the user session will be invalidated.

CaseSensitiveRegexps

Type: Boolean
Usage Constraint: optional
Default: false

Makes the regular expressions used in this filter match case sensitive.

CheckAlphanumericInput

Type: Boolean
Usage Constraint: optional, advanced
Default: false

If this attribute is set to true, blacklists will only be applied if the input string is alphanumeric.

ContentTypesAndLengths

Type: list of content length rules
Syntax: <content type>:<max. length>
Usage Constraint: optional, advanced

Defines the max. content length per requested content type. If not configured, an unlimited length is allowed.

DecodingRules

Type: list of decoding rules
Usage Constraint: optional, advanced

Supports configuration of a newline-separated list of decoding rules. A decoding rule consists of several decoding configurations separated by whitespace or , or ;. If DecodingRules is not configured, every blacklist regexp rule is executed against the respective part of the request (called test string). In the case of a match, the request is blocked. If DecodingRules is configured, the test string is first decoded with the first configured decoding and the regexp rules are then executed against the new test string. If several decodings are configured in on rule, the output from the first rule is the input for the second rule. The following decodings are supported:

HTML_decode (see http://en.wikipedia.org/wiki/Character_encodings_in_HTML)
URL_decode (see http://java.sun.com/j2se/1.4.2/docs/api/java/net/URLEncoder.html)
URL_decode_unicode: Same as urlDecoding, but also handles encoded Unicode characters and IIS unicode encoding.
BASE64_decode: base64 decoding of the input.
lowercase: Lowercase the input.
compress_whitespace: Convert tab, newline, carriage return and form feed characters to spaces, and then converts multiple consecutive spaces to a single space character.
replace_comments: Replace C-style comments with a single space character. Non closed comments will also be replaced with a whitespace.
normalisePath: Replace multiple forward slashes with a single forward slash and removes directory self-references.
jsDecode: Decode JavaScript escape sequences.
removeNulls: Remove null bytes from the string.
removeWhitespace: Remove all whitespace characters from the string.
cssDecode: Decode CSS-encoded characters.
If a decoding chain has been configured on the rule itself, the input parameter will be ignored (overwritten) for the said rule. This attribute configures the default value for the rules not defining a decoding chain.

DefaultDecodingRule

Type: String
Usage Constraint: optional, advanced
Default: URL_decode

This parameter allows to configure a decoding function which is always applied first (before the decodings defined in DecodingRules). If none is configured, no default decoding is applied.

FileNameBlackList

Type: list of file name rules
Syntax: [RuleID:<ruleId>:][ DecodingRules:] <comma-separated list of rules>:<regexp>
Usage Constraint: optional, advanced

Specifies which patterns in file names will cause the request to be blocked in case of a file upload by a POST request.
If not configured, all file names are allowed.

FileNameWhiteList

Type: list of file name rules
Syntax: [RuleID:<ruleId>:][ DecodingRules: <comma-separated list of rules>:<regexp>]
Usage Constraint: optional, advanced

Defines the rules that file names have to comply with in case of a file upload by a POST request for the request to be passed. If not configured, all file names are allowed.

RequestHeaderRules

Type: list of request header rules
Syntax: [RuleID:<ruleId>:]<header-regexp>:<value-regexp>:<action>:[<log level>:[<status code>]]
Usage Constraint: optional, conditional, advanced

Defines rules for the header name and value. A header rule has the following format:

<action>:
- allow: allow the header value for the matching header names.
- required: a header with the configured name and value must be in the request.
- drop: drop the headers matching.
- deny: block the requests containing matching headers.
<log level> (optional, default: allowed headers are logged silently, the others as log):
- log: allowed and dropped headers are logged as NOTICE. Required and denied headers are logged as ERROR.
- silent: allowed headers are logged as DEBUG_LOW. Dropped headers are logged as INFO. Required and denied headers are logged as INFO.
<status code>: (optional, default: 403): status code returned if a request is blocked.

ParameterRules

Type: list of request parameter rules
Syntax: [RuleID:<ruleId>:]<name-regexp>:<value-regexp>allow, required, deny [:log, silent[:<status-code>]]
Usage Constraint: optional, advanced, conditions allowed
Supported Pragmas: continue (default), break

Defines rules for request parameters (body and query parameters). Only the first match will be executed per parameter. Other matching rules will be silently dropped. If a parameter does not match any rule, the parameter will by silently allowed. Parameters are extracted from the request to name-value pairs.

The following Content-Types are supported:

application/x-www-form-urlencoded: the name and value are defined within the request itself. The RequestFlag NEEDS_PARAMS has to be set.
application/json: the structure path of each json element is used as name. The RequestFlag NEEDS_JSON_PARSING has to be set.
text/x-gwt-rpc: gwt.[i] is allocated as name for each different value sent in the request. The RequestFlag NEEDS_GWT_PARSING has to be set.
multipart/form-data: the name and value are defined within the request itself. The RequestFlag NEEDS_FORM_MULTIPARTS has to be set.

ResponseHeaderRules

Type: list of response header rules
Usage Constraint: optional, advanced

Defines rules for the header name and value. The same syntax and options as for the input parameter "RequestHeaderRules" can be used.

ResponseCookieRules

Type: list of response cookie rules
Usage Constraint: optional, advanced

The rules that new Cookies (i.e., "Set-Cookie" headers) have to fulfill for the response to be passed, dropped or blocked:

[Condition: [<SOURCE>]:<VARIABLE>:<regexp>]`  
[RuleID:<ruleId>:]<cookie-name-regexp>:<cookie-value-regexp>:allow, required, drop, deny [:log, silent[:<status-code>]]