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
ch::nevis::isiweb4::filter::validation::InputValidationFilter
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. |
| SQL-Injection | Deprecated This attribute is deprecated. Use the attribute ModSecurity-SQLInjections instead.Checks for SQL-injection attacks. |
| XSS | Deprecated This attribute is deprecated. Use the attribute ModSecurity-XSSAttacks instead.Checks for XSS (cross-site scripting) attacks. |
| XSS-MAX | Deprecated This attribute is deprecated. Use the attribute ModSecurity-XSSAttacks instead.The XSS-MAX profile implements the PHP-IDS ruleset (PHP Intrusion Detection System). The decoding rule 'PHPIDS_decode' has to be configured when using this profile. |
| XSS-Stricter | Deprecated This attribute is deprecated. Use the attribute ModSecurity-XSSAttacks instead.Checks for XSS attacks using a stricter. |
| 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, basic; default: 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, basic; default: allow all | Defines the allowed HTTP methods (GET, POST, HEAD, ...). If not configured, all HTTP methods are allowed. |
| BlockOnError | boolean; optional, basic; 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 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, basic; default: 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. |
| 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> (optional, default: 403): status code returned if a request is blocked. Note that 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 rewrite filter (see the chapter "ReadOnlySessionFilter") are used: Condition: [<SOURCE>]:<VARIABLE>:<regexp>; CIDR example: REMOTE_ADDR:CIDR/10.4.12.0/22/ |
| ParameterRules | list of request parameter rules; optional, advanced; default: allow all; supported Pragmas: continue (default), break | Defines rules for request parameters (body and query parameters). This parameter uses the following syntax:[Condition: [<SOURCE>]:<VARIABLE>:<regexp> CIDR example: REMOTE_ADDR:CIDR/10.4.12.0/22/ [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. - 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: [<SOURCE>]:<VARIABLE>:<regexp> CIDR example: REMOTE_ADDR:CIDR/10.4.12.0/22/ [RuleID:<ruleId>:]<cookie-name-regexp>:<cookie-value-regexp>:allow, required, drop, deny [:log, silent[:<status-code>]] |
| 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 has to 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 | 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 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 | 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, basic; default: 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 / daily / monthly |
| 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. |
| FormNameBlackList | list of form parameter name rules optional, advanced default: allow all | Fading outThis parameter is fading out. For new setups, use the parameter ParameterRules instead. In existing setups, switch to the ParameterRules parameter if possible.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 | Fading outThis parameter is fading out. For new setups, use the parameter ParameterRules instead. In existing setups, switch to the ParameterRules parameter if possible.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 | Fading outThis parameter is fading out. For new setups, use the parameter ParameterRules instead. In existing setups, switch to the ParameterRules parameter if possible.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 | Fading outThis parameter is fading out. For new setups, use the parameter ParameterRules instead. In existing setups, switch to the ParameterRules parameter if possible.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 | Fading outThis parameter is fading out. For new setups, use the parameter ParameterRules instead. In existing setups, switch to the ParameterRules parameter if possible.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 | Fading outThis parameter is fading out. For new setups, use the parameter ParameterRules instead. In existing setups, switch to the ParameterRules parameter if possible.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 | Skip 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, |
| HeaderBlackList | list of header value rules optional, advanced default: allow all | DeprecatedThis attribute is deprecated. Use the attributeRequestHeaderRulesinstead.Defines rules on the header values for blocking the request. A header rule has the following format:<header name>:<regexp for value>You can only use one rule at a time per header-- the other rules will be silently dropped. If not configured, all header values are allowed (if not blocked by the white list). |
| HeaderWhiteList | list of header value rules optional, advanced default: allow all | DeprecatedThis attribute is deprecated. Use the attributeRequestHeaderRulesinstead.The rules that header values have to fulfill for the request to be passed. A header rule has the following format:<header name>:<regexp for value>You can only use one rule at a time per header-- the other rules are then silently dropped. If not configured, all header values are allowed (if not blocked by the black list). |
| RegexpType | enum: POSIX, PCREoptional default: POSIX | Deprecated This parameter is deprecated. Only PCRE is supported. Defines the type of regexp syntax to be used. PCRE Regexps are mostly the same as Perl Regexps. |