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
- FormNameBlackList
- FormNameWhiteList
- FormNameValueBlackList
- FormNameValueWhiteList
- FormValueBlackList
- FormValueWhiteList
- HeaderBlackList
- HeaderWhiteList
- QueryBlackList
- QueryWhiteList
- URIBlackList
- URIWhiteList
Classname
ch::nevis::isiweb4::filter::validation::InputValidationFilter
Library
libInputValidationFilter.so.1
Profiles
| Name | Description |
|---|---|
| HTTP-Validation | Checks for HTTP protocol validations. |
| HTTP-Validation-Strict | Whitelist patterns for HTTP request headers. |
| HTTP-Validation-Length | Whitelist patterns for HTTP request headers length. |
| HTTP-Limitations | Enforces limits on HTTP requests (1KB URI, 12KB query, 100KB input forms, 6MB file uploads). |
| HTTP-ResponseHeaders | Whitelist pattern for HTTP response headers. |
| ModSecurity-Generic | Deprecated This profile is deprecated. Use the ModSecurityFilter with CRS instead.Ruleset part of the OWASP Core ModSecurity Rule Set. This profile contains rules to prevent several generic types of attacks. |
| ModSecurity-SQLInjections | Deprecated This profile is deprecated. Use the ModSecurityFilter with CRS instead.Ruleset part of the OWASP Core ModSecurity Rule Set. This profile contains rules to prevent SQL-injection attacks. |
| ModSecurity-XSSAttacks | Deprecated This profile is deprecated. Use the ModSecurityFilter with CRS instead.Ruleset part of the OWASP Core ModSecurity Rule Set. This profile contains rules to prevent XSS attacks. |
| ModSecurityExtended-Generic | Deprecated This profile is deprecated. Use the ModSecurityFilter with CRS instead.Ruleset for checking the URI part of requests, generated from OWASP Core ModSecurity Rules targeting argument names. The actual version of ModSecurity Rule Set does not contain explicit rules for checking the URI part; so these rules may be used optionally to prevent generic types of attacks in the URI. |
| ModSecurityExtended-SQLInjections | Deprecated This profile is deprecated. Use the ModSecurityFilter with CRS instead.Ruleset for checking the URI part of requests, generated from OWASP Core ModSecurity Rules targeting argument names. The actual version of ModSecurity Rule Set does not contain explicit rules for checking the URI part; so these rules may be used optionally to prevent SQL-injection attacks in the URI. |
| ModSecurityExtended-XSSAttacks | Deprecated This profile is deprecated. Use the ModSecurityFilter with CRS instead.Ruleset for checking the URI part of requests, generated from OWASP Core ModSecurity Rules targeting argument names. The actual version of ModSecurity Rule Set does not contain explicit rules for checking the URI part; so these rules may be used optionally to prevent XSS attacks in the URI. |
These pre-defined profiles are updated on a regular basis. We recommend copying the profile you are going to use and to define a new name for the new profile to avoid interference with the application's configuration when updating to a newer version of nevisProxy. This allows you to migrate the updated profile in a controlled and secure way whenever you want.
It is possible to aggregate profiles, as long as they do not overlap (that is, as long as a property is not used in both profiles). However, it is strongly recommended that you use one profile per filter.
See the chapter Configuration profiles for an example how to use profiles.
Configuration
| Name | Type, Usage Constraints, Defaults | Description |
|---|---|---|
| AllowedHeaders | string array optional, basicdefault: allow all | A 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 | string array optional, basicdefault: allow all | Defines the allowed HTTP methods (GET, POST, HEAD, ...). If not configured, all HTTP methods are allowed. |
| BlockOnError | boolean optional, basicdefault: 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 in this table. |
| MaxBlockedPerSession | integer optional, advanced default: not set | 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 | boolean optional, basicdefault: false | Makes the regular expressions used in this filter match case sensitive. |
| CheckAlphanumericInput | boolean optional, advanced default: false | If this attribute is set to true, blacklists will only be applied if the input string is alphanumeric. With the profile PHP-MAX, the configuration attribute CheckAlphanumericInput is set to true. |
| ContentTypesAndLengths | list of content length rules optional, advanced default: unlimited for all | 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 | list of decoding rules optional, advanced default: not configured | 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 cha-racters from the string. cssDecode: Decode CSS-encoded characters. Each one of these decoding rule correspond to a input normalization function in the PHP-IDS project. 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 | string 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 | list of file name rules optional, advanced default: allow all | 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 | list of file name rules optional, advanced default: allow all | 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. |
| FormNameBlackList | list of form parameter name rules optional, advanced default: allow all | Deprecated This parameter is deprecated. Use the parameter ParameterRules instead.Blacklist for form parameter names:[RuleID:<ruleId>:]``[ DecodingRules: <comma-separated list of rules>:<regexp> |
| FormNameWhiteList | list of form parameter name rules optional, advanced default: allow all | Deprecated This parameter is deprecated. Use the parameter ParameterRules instead.Whitelist for form parameter names:[RuleID:<ruleId>:]``[ DecodingRules: <comma-separated list of rules>:<regexp> |
| FormNameValueBlackList | list of form content rules optional, advanced default: allow all | Deprecated This parameter is deprecated. Use the parameter ParameterRules instead.Defines the forbidden values per form parameter name. A form content rule has the following format:[RuleID:<ruleId>:]``[ DecodingRules: <comma-separated list of rules>:]name:<regexp> |
| FormNameValueWhiteList | list of form content rules optional, advanced default: allow all | Deprecated This parameter is deprecated. Use the parameter ParameterRules instead.Defines the allowed values per form parameter name. A form content rule has the following format:[RuleID:<ruleId>:]``[ DecodingRules: <comma-separated list of rules>:]name:<regexp> |
| FormValueBlackList | list of form value rules optional, advanced default: allow all | Deprecated This parameter is deprecated. Use the parameter ParameterRules instead.Defines the rules for form values that must be fulfilled for the request to be blocked. A content form value rule has the following format:[RuleID:<ruleId>:]``[ DecodingRules: <comma-separated list of rules>:<regexp>If not configured, all form values are allowed. |
| FormValueWhiteList | list of form value rules optional, advanced default: allow all | Deprecated This parameter is deprecated. Use the parameter ParameterRules instead.Defines the rules for form values in order for the request to be passed. A content form value rule has the following format: [RuleID:<ruleId>:]``[ DecodingRules: <comma-separated list of rules>:<regexp> If not configured, all form values are allowed. |
| FormNameSkipList | list of form names optional, advanced default: none | Deprecated This parameter is deprecated. Use the parameter ParameterRules instead.Defines a "skip" list of given names for all Form** rules. Skip rules have the following format: <parameter-name-regex>[(:<ruleId>)] ruleIds are optional, if none are specified, the form name is skipped for all Form* rules. If ruleIds are specified, the given parameter is skipped only for rules with the defined ruleId*. |
| RequestHeaderRules | list of request header rules optional, advanced default: allow all | 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> ) are used: Condition: :<VARIABLE>:<regexp> *CIDR example: REMOTE_ADDR:CIDR/10.4.12.0/22/ |
| ParameterRules | list of request parameter rules optional, advanced default: allow allsupported Pragmas: continue (default), break | Defines rules for request parameters (body and query parameters). This parameter uses the following syntax:[Condition: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. application/json: the structure path of each json element is used as name. text/x-gwt-rpc: gwt.[i] is allocated as name for each different value sent in the request. * multipart/form-data |
| ResponseHeaderRules | list of response header rules optional, advanced default: allow all | Defines rules for the header name and value. The same syntax and options as for the input parameter "RequestHeaderRules" can be used. |
| ResponseCookieRules | list of response cookie rules optional, advanced default: allow all | The rules that new Cookies (i.e., "Set-Cookie" headers) have to fulfill for the response to be passed, dropped or blocked.*[Condition: |
| MaxHeadersAllowed | integer optional, security/troubleshooting default: unlimited | The max. number of HTTP headers allowed in a request. If not configured, an unlimited number is allowed. |
| MaxQuerySize | integer optional, security/troubleshooting default: unlimited | The max. query string length of a request. If not configured, an unlimited length is allowed. |
| MaxURISize | integer optional, security/troubleshooting default: unlimited | The max. URI length of a request. If not configured, an unlimited length is allowed. |
| MaxBodySize | integer optional, security/troubleshooting default: unlimited | The max. size of a request body. If not configured, an unlimited length is allowed. |
| LimitRequestParameters | integer optional default: unlimited | The maximum number of parameters allowed on a request. This number must not be bigger than the number set in the attributeLimitRequestParametersof thenavajo.xmlfile . If the attribute is not configured in thenavajo.xmlfile, then there is no limit here. |
| QueryBlackList | string optional | Blacklist for query validation:[RuleID:<ruleId>:]``[ DecodingRules: <comma-separated list of rules>:]<regexp> |
| QueryWhiteList | string optional | Whitelist for query validation:[RuleID:<ruleId>:]``[ DecodingRules: <comma-separated list of rules>:]<regexp> |
| ReadLineSize | integer optional, security/troubleshooting default: 1024 | The maximum size of embedded headers of a multipart request. An error will result if a longer line occurs. |
| RemoveInvalidHeader | boolean optional default: false | If set to "true", nevisProxy will remove headers that are not configured in theAllowedHeadersparameter and process the requests. Otherwise, such requests will be handled as specified in theBlockOnErrorparameter.This parameter is ignored if theAllowedHeadersparameter is not set. |
| ShowPlainTextValues | boolean advanced default: false | If set to true, the values of name-value pairs are logged in plaintext. For security reasons this attribute should not be set to true in production, but only under development or integration. |
| StatusCode | string 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 | list of URI rules optional, basic | 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 | list of regexps optional, advanced default: not specified | 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 | list of URI rules optional, basicdefault: allow all | 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 | string 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.Key'. |
| AuditLog.RotationPolicy | string optional, advanced | The rotation policy for the AuditLog.FileName. Possible values: size:<max.filesize in bytes>:<number of versions> time:hourly |
| AuditLog.Key | string optional, advanced | The key used to encrypt the parameter value received in a request (form submit for example). The key has the following syntax: plain:<key> : a plain text key pipe://<command> : get the key via a pipe (external program) |
| RawTypes | string 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 | list of strings optional, advanced default: not specified | 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. |
Instead of using the deprecated Form** parameters of the InputValidationFilter, you can now use the ParameterRules* attribute. In the following examples you can see some simple examples that can be used instead of the deprecated parameters.
To block a parameter value from a submitted form, instead of configuring the deprecated FormValueBlackList:
<init-param>
<param-name>FormValueBlackList</param-name>
<param-value>
.*foo
</param-value>
</init-param>
You can achieve the same behavior via ParameterRules:
<init-param>
<param-name>ParameterRules</param-name>
<param-value>
^.*:.*foo:deny
</param-value>
</init-param>
This blocks all incoming requests if any parameter value contains foo.
To allow given parameters to have the previously blocked value, instead of using the deprecated FormNameSkipList and FormValueBlackList:
<init-param>
<param-name>FormNameSkipList</param-name>
<param-value>
parameter1
parameter4
</param-value>
</init-param>
You can achieve the same with ParameterRules:
<init-param>
<param-name>ParameterRules</param-name>
<param-value>
^parameter1$:.*:allow
^parameter4$:.*:allow
.*:.*foo.*:deny
</param-value>
</init-param>
This will allow the requests to pass through, even if parameter1 or parameter4 contains the value foo.
To allow parameters to have a given value, instead of configuring FormValueWhitelist:
<init-param>
<param-name>FormValueWhiteList</param-name>
<param-value>
bagafoo
</param-value>
</init-param>
You could achieve the same with:
<init-param>
<param-name>ParameterRules</param-name>
<param-value>
^parameter1$:.*:allow
^parameter4$:.*:allow
^.*:bagafoo:allow
^.*:.*foo:deny
</param-value>
</init-param>
To block a request because one of the Form parameter names, instead of FormNameBlackList:
<init-param>
<param-name>FormNameBlackList</param-name>
<param-value>
exec
action
</param-value>
</init-param>
You could achieve the same with ParameterRules:
<init-param>
<param-name>ParameterRules</param-name>
<param-value>
^exec$:.*:deny
^action$:.*:deny
</param-value>
</init-param>
To allow only given characters in the Form names, instead of using FormNameWhiteList:
<init-param>
<param-name>FormNameWhiteList</param-name>
<param-value>
^[a-zA-Z0-9]+$
</param-value>
</init-param>
You could add something like this to the previously configured ParameterRules:
<init-param>
<param-name>ParameterRules</param-name>
<param-value>
^exec$:.*:deny
^action$:.*:deny
^[a-zA-Z0-9]+$:.*:allow
^.*$:.*:deny
</param-value>
</init-param>
This allows all requests with non-special character parameter names (except for exec and action), but block everything else.
It is possible to validate the form value, for a given form field, and block the request if it contains undesired values, just like with FormNameValueBlackList:
<init-param>
<param-name>FormNameValueBlackList</param-name>
<param-value>
isiwebuserid:root
isiwebpasswd:test
</param-value>
</init-param>
The same can be achieved with ParameterRules:
<init-param>
<param-name>ParameterRules</param-name>
<param-value>
^isiwebuserid$:root:deny
^isiwebpasswd$:test:deny
</param-value>
</init-param>
This blocks if the values root or test are entered.
To add input validation to the entered values of the given form parameters, like with FormNameValueWhiteList:
<init-param>
<param-name>FormNameValueWhiteList</param-name>
<param-value>
isiwebuserid:^[a-zA-Z]*$
isiwebpasswd:^[a-zA-Z0-9]*$
</param-value>
</init-param>
You could achieve the same (combined with the forbidden values) with ParameterRules:
<init-param>
<param-name>ParameterRules</param-name>
<param-value>
^isiwebuserid$:root:deny
^isiwebpasswd$:test:deny
^isiwebuserid$:[a-zA-Z]+$:allow
^isiwebpasswd$:[a-zA-Z0-9]+$:allow
^isiweb.+:.*:deny
</param-value>
</init-param>