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.
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 Access Limit
Custom Access Policy
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
The WAF module scan sequence in 7.0.0 is shown as below for your reference:
WAF_SESSION_MANAGEMENT, //Client management
WAF_WEB_CACHE, // NOTE: it has to be placed before the modules which will modify the original packs
WAF_ROBOT_CHECK, // ML bot detection
WAF_BOT_CLIENT, // Biometric based bot detection
WAF_SERVER_PROTECTION_RULE, // Signature
WAF_BOT_CUSTOM_ACCESS, // Threshold based bot detection
WAF_MLEARNING, // Machine Learning framework
WAF_API_RECORD, // Machine Learning API discovery
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 enablein 7.0.1; FortiWeb will decode chunked response and convert it with Content-Length.
When configured as
set chunk encoding enableon 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.
Transfer-Encoding: chunkedheader 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 application chunk-decode-encode 7
diagnose debug enable
These are the web protection that depend on chunk decoding/encoding:
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 application cookie-security 7
# diagnose debug proxy svr-balance 7