We have a base ArcGIS Enterprise deployment behind an Azure Application Gateway with WAF enabled using the OWASP 3.1 ruleset. We have run this in detection mode for a few months while we build the exceptions for valid requests. We have managed to build the exceptions for all of our valid requests except one that is triggers when publishing a hosted feature layer from ArcGIS Pro or ArcMap. The only way of overcoming this is by turning body inspection off in the WAF which defeats the purpose of having a WAF in the first place.
This is the WAF log for the mandatory rule.
OperationName | ApplicationGatewayFirewall |
requestUri_s | /portal/sharing/rest/content/users/<redactedemail>/addItem |
Message | Mandatory rule. Cannot be disabled. Failed to parse request body. |
ruleSetType_s | OWASP_CRS |
ruleSetVersion_s | 3.1.0 |
ruleId_s | 200002 |
action_s | Blocked |
site_s | Global |
details_message_s | Access denied with code 400 (phase 2). Match of \"eq 0\" against \"REQBODY_ERROR\" required. |
details_data_s | Multipart: Invalid boundary in C-T (characters). |
details_file_s | \"/etc/nginx/modsec/<redacted>/modsecurity.conf |
details_line_s | 72 |
Solved! Go to Solution.
Update Esri support referred me to these bugs - BUG-000109582 , BUG-000132154
Troubleshooting this issue further we where able to capture the offending request using Fiddler and troubleshoot it using Postman to change the request. We found that the issue appears to be how ArcGIS Pro formats the boundary in the Content-Type header. The curly brackets in the boundary cause the WAF to block the request. If we removed the brackets from both the Content-Type boundary and the body of the request the WAF does not block the request and Portal for ArcGIS returns "success":true.
This is how ArcGIS Pro formats the Content-Type request that gets blocked by the WAF:
multipart/form-data; Charset=UTF-8; boundary={588ECA44-A34E-4798-B4A2-9AA511C17A46}
This is how the WAF allows the request to go through:
multipart/form-data; charset=UTF-8; boundary=588ECA44-A34E-4798-B4A2-9AA511C17A46
Reading the W3C standard for the content type https://www.w3.org/Protocols/rfc1341/4_Content-Type.html It appears that it is limited to alphanumerical and the following special characters:
tspecials := "(" / ")" / "<" / ">" / "@" ; Must be in / "," / ";" / ":" / "\" / <"> ; quoted-string, / "/" / "[" / "]" / "?" / "." ; to use within / "=" ; parameter values
Update Esri support referred me to these bugs - BUG-000109582 , BUG-000132154
wow - fixed at Pro 2.9
BUG-000109582: When publishing from ArcGIS Pro, the client sets inv.. (esri.com)