Select to view content in your preferred language

Publishing from ArcGIS Pro triggers Azure WAF mandatory rule.

2693
4
Jump to solution
04-18-2021 09:07 PM
HéctorMeléndez
Esri Contributor

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

0 Kudos
1 Solution

Accepted Solutions
HéctorMeléndez
Esri Contributor

Update Esri support referred me to these bugs - BUG-000109582 , BUG-000132154 

View solution in original post

0 Kudos
4 Replies
HéctorMeléndez
Esri Contributor

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}

 

HéctorMeléndez_1-1619063914558.png

This is how the WAF allows the request to go through:

 

multipart/form-data; charset=UTF-8; boundary=588ECA44-A34E-4798-B4A2-9AA511C17A46

 

HéctorMeléndez_0-1619063877959.png

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

 

HéctorMeléndez
Esri Contributor

Update Esri support referred me to these bugs - BUG-000109582 , BUG-000132154 

0 Kudos
NirmalOjha1
Occasional Contributor

@HéctorMeléndez 

Is there any chance you can share the WAF exceptions?

Nirmal

0 Kudos
DavidHoy
Esri Contributor
0 Kudos