Skip to main content
Version: 7.2402.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

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

  • Usage Constraint: optional, advanced

  • Defines the max. content length per requested content type. A content length rule has the following format: <content type>:<max. length>

    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

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

    A file name rule has the following format: 

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

    If not configured, all file names are allowed.

FileNameWhiteList​

  • Type: list of file name rules

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

    A file name rule has the following format:

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

    If not configured, all file names are allowed.

RequestHeaderRules​

  • Type: list of request header rules
  • Usage Constraint: optional, advanced
  • Defines rules for the header name and value. A header rule has the following format:
[RuleID:<ruleId>:]<header-regexp>:<value-regexp>:<action>:[<log level>:[<status code>]]

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

    note

    It is possible to define an input validation rule depending on the value of some part of the request. As conditions, the same syntax and usage pattern as in the RewriteFilter are used:

    Condition: [<SOURCE>]:<VARIABLE>:<regexp>

    CIDR example: REMOTE_ADDR:CIDR/10.4.12.0/22/

ParameterRules​

  • Type: list of request parameter rules

  • Usage Constraint: optional, advanced, conditions allowed

  • Supported Pragmas: continue (default), break

  • Defines rules for request parameters (body and query parameters). 

    [RuleID:<ruleId>:]<name-regexp>:<value-regexp>allow, required, deny [:log, silent[:<status-code>]]

    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.

    The foollowing RequestFlags are set by default: +NEEDS_PARAMS +NEEDS_GWT_PARSING +NEEDS_FORM_MULTIPARTS

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>]]

MaxHeadersAllowed​

  • Type: Integer
  • Usage Constraint: optional
  • The max. number of HTTP headers allowed in a request. If not configured, an unlimited number is allowed.

MaxQuerySize​

  • Type: Integer
  • Usage Constraint: optional
  • The max. query string length of a request. If not configured, an unlimited length is allowed.

MaxURISize​

  • Type: Integer
  • Usage Constraint: optional
  • The max. URI length of a request. If not configured, an unlimited length is allowed.

MaxBodySize​

  • Type: Integer
  • Usage Constraint: optional
  • The max. size of a request body. If not configured, an unlimited length is allowed.

LimitRequestParameters​

  • Type: Integer
  • Usage Constraint: optional
  • The maximum number of parameters allowed on a request. This number must not be bigger than the number set in the attribute LimitRequestParameters of the navajo.xml file . If the attribute is not configured in the navajo.xml file, then there is no limit here.

QueryBlackList​

  • Type: String
  • Usage Constraint: optional
  • Blacklist for query validation:
[RuleID:<ruleId>:][DecodingRules: <comma-separated list of rules>:]<regexp>

QueryWhiteList​

  • Type: String
  • Usage Constraint: optional
  • Whitelist for query validation:
[RuleID:<ruleId>:][ DecodingRules: <comma-separated list of rules>:]<regexp>

RemoveInvalidHeader​

  • Type: Boolean
  • Usage Constraint: optional
  • Default: false
  • If set to true, nevisProxy will remove headers that are not configured in the AllowedHeaders parameter and process the requests. Otherwise, such requests will be handled as specified in the BlockOnError parameter. This parameter is ignored if the AllowedHeaders parameter is not set.

ShowPlainTextValues​

  • Type: Boolean
  • Usage Constraint: optional, advanced
  • Default: false
  • If set to true, the values of name-value pairs are logged in plain text. For security reasons this attribute should not be set to true in production, but only under development or integration.

StatusCode​

  • Type: Integer
  • Usage Constraint: optional, min: 100, max: 1000
  • Default: 403
  • Permits specification of an HTTP error code to be sent in the response if input validation fails.

URIBlackList​

  • Type: list of URI rules
  • Usage Constraint: optional
  • If an URI (only the path portion) blacklist is configured, validation is successful only if the URI does not match any of the entries in the blacklist. If an URI is found in both the blacklist and the whitelist, validation also fails:
[RuleID:<ruleId>:][ DecodingRules: <comma-separated list of rules>:]<regexp>

URISkippList​

  • Type: list of regexps
  • Usage Constraint: optional, advanced
  • If the URI (only the path portion) matches one of the regexps, the request is passed through without any check. This feature is used to reduce the number of false positives:
[RuleID:<ruleId>:][ DecodingRules: <comma-separated list of rules>:]<regexp>

URIWhiteList​

  • Type: list of URI rules
  • Usage Constraint: optional
  • Defines the rules that the URI (only the path portion) has to fulfill for the request to be passed. A URI rule has the following format:
[RuleID:<ruleId>:][ DecodingRules: <comma separated list of rules>:]<regexp>

If not configured, all URIs are allowed.

AuditLog.FileName​

  • Type: String
  • Usage Constraint: optional, advanced
  • Defines a file name where to audit the received request parameters (in form of a name value pair). The value will be encrypted using the AuditLog.PassPhrase.

AuditLog.RotationPolicy​

  • Type: String
  • Usage Constraint: optional, advanced
  • The rotation policy for the AuditLog.FileName. Possible values:
    • size:<max.filesize in bytes>:<number of versions>
    • time:hourly | daily | monthly

AuditLog.PassPhrase​

  • Type: String
  • Usage Constraint: optional, advanced
  • The key used to encrypt the parameter value received in a request (form submit for example).

RawTypes​

  • Type: String

  • Usage Constraint: optional, advanced

  • A list of newline-separated lines of header fields that expect a Raw-Type body.
    Each line has the following format: <content-type-regex>:<name>

    For each RawType, there will be exactly one name-value pair <name>=<body-content> to which the input validation rules, defined within the ParameterRules parameter of this filter, will be applied. This parameter allows to perform input validation on any type of request not using standard Content-Types.

DisabledRuleIds​

  • Type: List of strings
  • Usage Constraint: optional, advanced
  • Newline separated list of <ruleId> strings defining rules to disable. The validation rules listed here will be disabled despite their presence elsewhere in the configuration.
Last updated on