While handling large requests, such as a file upload, certain requests can be blocked with a 413 Request Entity Too Large message.
NSX Advanced Load Balancer can trigger an alert or block uploads for requests such as the following:
File size exceeding the limit set under the Client Max Body Size field in the virtual service HTTP profile.
Random match of
System-Default-Policyrules for binary upload data, which will result in WAF blocking or flagging the request based on the mode.Exceeding the regex match limit with rules running too long on the input, which will result in WAF terminating the execution.
Large requests (such as a regular file upload) are handled differently, as these requests will be processed partially, as explained below.
Parameters Handling Large Uploads
The following two configuration parameters are considered for large file uploads:
Client Max Body Size: In NSX Advanced Load Balancer UI, navigate to to configure the HTTP policy. Under the DDoS tab, the Client Max Body Size field defines the maximum body size of a client request. This value limits the size of a client POST as a part of a single HTTP request. In the case of a WAF bypass rule, this value is overridden and not considered. Otherwise, if the value configured is lesser than the Client Max Complete Header Size configured under WAF Profile, the buffering will fail with a 413 error message in the proxy before reaching the WAF. To mitigate this, update the value configured under Client Max Header Field Size to be higher than the value configured under Client Max Complete Header Size.
Note:If the Client Max Body Size is set to a default value of zero, which refers to no-limit, then this value will always be greater than the Client Max Complete Header Size.
Client Max Complete Header Size: In NSX Advanced Load Balancer UI, navigate to to configure a WAF Profile. Under the section, the Client Max Complete Header Size field defines the maximum allowed size for the client request body to be scanned by WAF. If the client request size is larger than the value configured in this field, then the partial body is scanned through WAF as allowed per the defined size.
If WAF rejects the request due to a
System-Default-Policyrule match, the rest of the request body is discarded. If WAF allows the request, the rest of the body is streamed in the backend.Ensure that the check box for Ignore request body parsing errors due to partial scanning is selected to avoid any errors triggered by partial scanning.
This is supported for both HTTP 1.0 and HTTP 2.0.
This is supported only for
content-lengthrequest and not for chunked encoded POST.If WAF is activated in detection mode and a chunked encoded POST is received, then that POST will be rejected if the size of the POST is greater than the Client Max Complete Header Size defined under WAF profile.
Examples
The following are the examples for specific uploads and the corresponding WAF log entries:
Example 1:
Request is denied with a 413 message as the client request size exceeds the maximum value configured in HTTP profile.
As WAF did not inspect the request, WAF status is PASSED.
This error can be mitigated by increasing the value of Client Max Body Size.
Example 2:
Size limit has been increased and so no limit was hit.
Request is denied with a 403 message.
Coincidentally, as parts of the PDF matched the WAF CRS rules, the request is rejected and the status is REJECTED.
Bypassing WAF
You can bypass certain large requests or particular upload requests from going through WAF. Few file extensions are bypassed from the WAF check, as they are static content. For more information on configuring static extensions, see Configuring WAF Profile.
You can also bypass uploads completely using the Modsec bypass rules, as explained in the section below.
Modsec Bypass Rules
The following are a few examples of modsec bypass rules. It is recommended to configure these using URLs. The ID should either be within the local range of 0 to 99.999 or a private reserved range, as explained in the ModSecurity Handbook. The numbers are chosen here to illustrate the example. Ensure unique rule IDs in your deployment.
Single URL:
SecRule REQUEST_URI "@rx /app/upload/" id:90001,phase:1,t:none,nolog,pass,ctl:ruleEngine=off
Multiple URLs:
SecRule REQUEST_URI "@rx /app/upload/|/app/upload_two/|/app/upload_three/" id:90002,phase:1,t:none,nolog,pass,ctl:ruleEngine=off
This rule can be altered using other OPERATORS such as @contains, @startwith.
By Content-Length:
SecRule REQUEST_HEADERS:Content-Length “@gt 1048576” phase:1,id:90003,nolog,pass,ctl:ruleEngine=off
It is recommended to configure rules using the URL, instead of Content-Length.
Effect on Malicious Uploads
These are cases where an attacker might want to smuggle a malicious upload onto a server. Such an upload might contain malware, ransomware, viruses, and other file-based exploits (pdf reader exploits), among many others. It is recommended to use a virus malware scanning tool on the upload directory of the application to detect the attacks and mitigate them.
Effect of Upload Bypass on Application Security
If large binary data bypass is configured with the right scope of uploading requests or URLs, then WAF will not be able to inspect the data and the impact will be minimal.
You can bypass certain large requests or particular upload requests from going through WAF. Few file extensions are bypassed from the WAF check, as they are static content.
Large uploads will be cached during traffic processing. Even when a part of the request is not needed and bypassed, it will be cached until other parts of that request have been inspected. Therefore, excluding only the upload parameter will not help achieve the best result.
