Select which action the FortiWeb appliance will take when it detects a violation of the rule:

• Alert — Accept the connection and generate an alert email and/or log message.

• Alert & Deny — Block the request (reset the connection) and generate an alert and/or log message.

  You can customize the web page that FortiWeb returns to the client with the HTTP status code. See Customizing error and authentication pages (replacement messages).

• Period Block — Block subsequent requests from the client for a number of seconds. Also configure Block Period.

  You can customize the web page that FortiWeb returns to the client with the HTTP status code. See Customizing error and authentication pages (replacement messages).

  Note: If FortiWeb is deployed behind a NAT load balancer, when using this option, you must also define an X-header that indicates the original client’s IP (see Defining your proxies, clients, & X-headers). Failure to do so may cause FortiWeb to block all connections when it detects a violation of this type.

The default value is Alert.

Caution: This setting will be ignored if Monitor Mode is enabled.

Note: Logging and/or alert email will occur only if enabled and configured. See Logging and Alert email.

Note: If you will use this rule set with auto-learning, you should select Alert. If Action is Alert & Deny, or any other option that causes the FortiWeb appliance to terminate or modify the request or reply when it detects an attack attempt, the interruption will cause incomplete session information for auto-learning.

Type the number of seconds that you want to block subsequent requests from the client after the FortiWeb appliance detects that the client has violated the rule.

This setting is available only if Action is set to Period Block. The valid range is from 1 to 3,600 (1 hour). The default value is 60. See also Monitoring currently blocked IPs.

When rule violations are recorded in the attack log, each log message contains a Severity Level (severity_level) field. Select which severity level the FortiWeb appliance will use when it logs a violation of the rule:

• Low
• Medium
• High

The default value is High.

Enable to check for illegal characters in the Host: line of the HTTP header, such as null characters or encoded characters.

For example, characters such as 0x0 or %00* will be considered illegal.

Attack log messages contain Illegal Host Name when this feature detects an invalid host name.

Enable to check for invalid HTTP version numbers. Currently, the only valid version strings are HTTP/0.9, HTTP/1.0 or HTTP/1.1.

Attack log messages contain Illegal HTTP Version when this feature detects an invalid HTTP version number.

Enable to check for invalid HTTP request methods according to RFC 2616 or RFC 4918. Any method not defined in these RFCs — including misspellings like GETT as well as other HTTP extension methods (e.g. CalDAV) like MKCALENDAR — are considered invalid.

Attack log messages contain Illegal HTTP Method when this feature detects an invalid HTTP request method.

Type the maximum acceptable length in bytes of the entire HTTP request, including both headers and body.

Attack log messages contain HTTP Request Length Exceeded when this feature detects an excessively large HTTP request.

Type the maximum acceptable length in bytes of the request body. Length is determined by comparing this limit with the value of the Content-Length: field in the HTTP header.

Attack log messages contain Content Length Exceeded when this feature detects a content length buffer overflow attempt.

Tip: RPC requests’ content length often do not match their own Content-Length: header. Attackers may also intentionally craft mismatching Content-Length: headers in an attempt to cloak buffer overflows. For those cases, use other limits instead or in addition, such as Body Length and Limiting file uploads.

Type the maximum acceptable size in bytes of the HTTP body.

For requests that use the HTTP POST method, this typically includes parameters from submitted by HTML form inputs. In the case of file uploads, this can normally be many megabytes. For most simple forms, however, the body should be only a few kilobytes in size at maximum.

Attack log messages contain Body Length Exceeded when this feature detects a body size buffer overflow attempt.

Type the maximum acceptable size in bytes of all HTTP header lines.

Attack log messages contain Total Size of All Headers Too Large when this feature detects a header size buffer overflow attempt.

Type the maximum acceptable size in bytes of each line in the HTTP header.

Attack log messages contain Header Line Too Large when this feature detects an attempted header line length buffer overflow.

Type the maximum acceptable number of lines in the HTTP header.

Attack log messages contain Too Many Headers when this feature detects a header line count buffer overflow attempt.

Type the total maximum total acceptable size in bytes of all parameters in the URL and/or, for HTTP POST requests, the HTTP body.

Question mark ( ? ), ampersand ( & ), and equal ( = ) characters are not included.

Attack log messages contain Total URL and Body Parameters Length Exceeded when this feature detects a total parameter size buffer overflow attempt.

Type the total maximum acceptable length in bytes of all parameters, including their names and values, in the URL. Parameters usually appear after a ?, such as:

/url?parameter1=value1&parameter2=value2

It does not include parameters in the HTTP body, which can occur with HTTP POST requests. For those, configure Total URL and Body Parameters Length or Body Length instead.

Attack log messages contain Total URL Parameters Length Exceeded when this feature detects a URL parameter line length buffer overflow attempt.

Type the maximum number of parameters in the URL. The maximum number is 104.

It does not include parameters in the HTTP body, which can occur with HTTP POST requests.

Attack log messages contain Too Many Parameters in Request when this feature detects a URL parameter count buffer overflow attempt.

Type the maximum acceptable number of cookies in an HTTP request.

Attack log messages contain Too Many Cookies in Request when this feature detects a cookie count buffer overflow attempt.

Type the maximum acceptable number of Range: lines in each HTTP header. The default value is 5.

Attack log messages contain Too Many Range Headers when this feature detects too many Range: header lines.

Tip: Some versions of Apache are vulnerable to a denial of service (DoS) attack on this header, where a malicious client floods the server with many Range: headers. The default value is appropriate for un-patched versions of Apache 2.0 and Apache 2.1.

Enable to inspect the request for:

• syntax errors
• exceeding the maximum buffer size allowed by FortiWeb’s HTTP parser

Errors and buffer overflows can cause problems in web servers that do not handle them gracefully. Such problems can lead to security vulnerabilities.

Attack log messages contain Too Many Parameters or Too Many Flash Parameters or another message that indicates the specific cause when this feature detects a request with parser errors or a FortiWeb buffer overflow attempt.

Caution: Fortinet strongly recommends to enable this option unless large requests/parameters are required by the web application. If part of a request is too large for its scan buffer, FortiWeb cannot scan it for attacks. It also cannot perform rewrites. Unless you configure it to block, FortiWeb will allow oversized requests to pass through without scanning or rewriting. This could allow padded attacks to pass through, and rewriting to be skipped.

If feasible, instead of disabling this option:

• Enlarge the scan buffer for each parameter (see http-cachesize in the FortiWeb CLI Reference). Requests larger than the buffer will be flagged as potentially malformed by FortiWeb’s parser, causing FortiWeb to block normal requests (i.e. false positives). For more buffer specifications, see Buffer hardening.
• Disable this setting only for URLs that require oversized parameters (see Configuring HTTP protocol constraint exceptions)

Enable to apply this HTTP constraint exception only to HTTP requests for specific web hosts. Also configure Host.

Disable to apply the exceptions to all web hosts.

Select the IP address or fully qualified domain name (FQDN) of the protected host to which this exception applies.

This setting is available only if Host Status is enabled.

Depending on your selection in the Request Type field, enter either:

• the literal URL, such as /index.php, that the HTTP request must contain in order to match the input rule. The URL must begin with a backslash ( / ).
• a regular expression, such as ^/*.php, matching all and only the URLs to which the input rule should apply. The pattern does not require a slash ( / ); however, it must at match URLs that begin with a slash, such as /index.cfm.

Do not include the domain name, such as www.example.com, which is configured separately in the Host drop-down list.

To create and test a regular expression, click the >> (test) icon. This opens the Regular Expression Validator window where you can fine-tune the expression (see Regular expression syntax).

Enable to omit the constraint on the maximum acceptable number of Range: lines in an HTTP header.

Tip: Some versions of Apache are vulnerable to a denial of service (DoS) attack on this header, where a malicious client floods the server with many Range: headers. If your web servers do not run Apache and are not vulnerable to this attack, mark this check box to omit it from the scan and improve performance.