FAQ

Why cannot hidden fields work fine with offline mode?

One of the following two conditions must be met with offline mode.

1) The HTTP request and response is in the same TCP session.

2) The Session Key configured in offline profile (if not configured, ASPSESSIONID, PHPSESSIONID, or JSESSIONID) must be used in HTTP.

Why doesn’t a WAF protection module work?

Some modules can disable other modules, such as URL access. When a certain module does not work, we should think about this. Here are some examples.

1) When URL access action is Pass, it can disable all security features after Global Object White List & URL Access, please refer to the module sequence in the following FAQ item.

2) IP white list can disable all security features after IP List Check.

3) When matched known engine, WAF will disable some RBE related features and all modules that may cause false positives. These modules are listed as follows

HTTP Flood

HTTP Access Limit

Custom Access Policy

GEO IP

Malicious IP

HTTP_Protocol Constraints

Robot Check

Bot Deception

Biometrics Based Detection

Threshold Based Detection

4) Some OWA URLs will result in errors, so FortiWeb will disable these modules below.

All response followup modules are disabled

File Security

Webshell Detection

Chunk Decode

File Uncompress

Signature

URL Rewriting

File Compress

Machine Learning

What’s the sequence of WAF module scans?

Please refer to Sequence of scans.

How does Web Protection modules support Transfer-Encoding:chunked?

With chunked transfer encoding, the HTTP server sends data to the receiver in a series of chunks instead of waiting until the complete segment is available. This is important especially when fetching dynamic content with unknown content length.

Some web protection modules support handling chunked data in HTTP response, but the behavior is different between 7.0.2 and previous builds.

On 7.0.1 and previous builds, there is an option set chunk decoding enable/disable for each server policy.

• It’s enabled by default. FortiWeb will decode all the chunked responses, and convert it to body with a Content-Length header. In certain cases such as legacy clients only accept chunked responses, the clients will fail to process the response.

• If chunk decoding is disabled, the critical WAF modules that depend on the chunk decoded data will not be able to work.

From 7.0.2, FortiWeb replaced set chunk decoding enable/disable with set chunk encoding disable/enable.

• The default configuration is disabled, which equals to set chunk decoding enable in 7.0.1; FortiWeb will decode chunked response and convert it with Content-Length.

• When configured as set chunk encoding enable on 7.0.2, FortiWeb decodes and reassembles the chunked response, performs the WAF modules’ operations, and encodes the new content with chunked again, then sends it to the clients.

From 7.0.2, when set chunk encoding enable, instead of delaying sending packets to the client until all content is available, the server will:

• Send the response in chunks.

• Add a Transfer-Encoding: chunked header to the chunks.

• Apply markers within the content to indicate the length of each chunk and whether that particular chunk is the last chunk that the server is sending.

• Under some conditions, chunk decoding module will not take action:

  • No web protection profile is bound to a server policy;

  • No modules enabled in a web protection profile;

  • Modules that depend on chunk decoded data are not enabled in web protection profile (e.g. compress, xml validation);

  • When chunked response size exceeds max-cache-size, FortiWeb will not decode chunked content.
    

For purpose of troubleshooting chunk decoding/encoding issues, you can enable the diagnose log as below:

diagnose debug flow filter module-detail chunk-decode-encode 7

diagnose debug enable

These are the web protection that depend on chunk decoding/encoding:

• WAF_AJAX_BLOCK

• WAF_XML_VALIDATION

• WAF_WEB_ACCELERATION

• WAF_ROBOT_CHECK

• WAF_MLEARNING

• WAF_HIDDEN_FIELDS

• WAF_API_RECORD

• WAF_USER_TRACKING

• WAF_FILE_COMPRESS

• WAF_FILE_UNCOMPRESS

• WAF_URL_ENCRYPTION

• WAF_LINK_CLOAKING

• WAF_URL_REWRITING_POLICY

• WAF_CSRF_CHECK

• WAF_SERVER_PROTECTION_RULE

• WAF_BOT_DECEPTION

• WAF_BOT_CLIENT

• WAF_MITB_CHECK

How does Cookie Security work when persistence types that may change cookies are used in Server Pool?

If both Cookie Security policy and cookie related Persistence types are enabled in one server-policy, there might be conflicts when both modules are trying to change the cookie values. The Cookie Security module will not handle cookies in some situations to avoid such conflicts.

With Persistence Types as below on 7.0.1 and earlier builds:

• PHP Session ID, ASP Session ID, JSP Session ID: Cookie Security handling will be bypassed;

• Insert Cookie/Rewrite Cookie/Embedded Cookie: Cookie Security handling will be bypassed;

• Persistent Cookie: Cookie Security check/set works

With Persistence Types as below on 7.0.2 and later builds:

• PHP Session ID, ASP Session ID, JSP Session ID: Cookie Security check/set works;

• Insert Cookie/Rewrite Cookie/Embedded Cookie: Cookie Security handling will be bypassed; (the same as before)

• Persistent Cookie: Cookie Security check/set works (the same as before)

When the behavior is different from your expectation, you can enable diagnose commands as below for troubleshooting:

# diagnose debug flow filter module-detail cookie-security 7

# diagnose debug proxy svr-balance 7