Our REST APIs hosted in Azure API Management (internal VNET mode) are only accessible from internet via Azure App Gateway (WAF v2 SKU), with OWASP CRS 3.1 rules enabled in the WAF. However, there has been a penetration testing observation that hackers can bypass the WAF rules by calling a POST API with Content-Type header as "application/xml", but still sending malicious JSON payload in the request body. In such case, the request is not being intercepted by the WAF and API returns HTTP 200, unlike the case when Content-Type is sent as "application/json" where the same malicious payload is blocked by WAF returning 403 (forbidden). Is there any way to block the malicious JSON payload at the App Gateway/WAF even when the request header Content-Type header is "application/xml"? Or does this validation, whether the incoming request has a Content-Type other than "application/json", need to be taken care at the API side?
Asked
Active
Viewed 1,182 times
0

Tanmoy Sengupta
- 406
- 4
- 18
-
1I got a solution from the answer below, although looks like this solution will result in blocking all XML requests at WAF level, which may not be an optimal solution in all cases. I have added a follow-up question in the comment to the answer. Otherwise, this can be addressed at APIM with policy to block any content-type other than "application/json" and the policy will be applied to only those specific APIs which expect only JSON payload. – Tanmoy Sengupta Nov 29 '21 at 14:32
-
You can add this as an answer and accept it so that it can be helpful to other community members who may face the same problem. – Ecstasy Nov 30 '21 at 03:45
1 Answers
1
If it's strictly an issue of the header, you could create a custom rule that either only allows application/json
or just blocks application/xml
.
Modifying the example from that page, this would block anything that doesn't contain application/json
:
{
"customRules": [
{
"name": "requirejson",
"ruleType": "MatchRule",
"priority": 2,
"action": "Block",
"matchConditions": [
{
"matchVariable": "RequestHeaders",
"Selector": "Content-Type",
"Operator": "Contains",
"NegationConditon": true,
"matchValues": [
"application/json"
]
}
]
}
]
}
Setting the negation condition to true
turns it from a ==
to a !=
rule, as in if Content-Type does not contain application/json
. Although keep in mind that this would work for "properly set" headers, this rule would still allow further processing if the header was set to anything that simply contains the matching string.
Full explanation of the payload is here.

mherzig
- 1,528
- 14
- 26
-
1
-
Jus wondering if it is possible to block a malicious payload (containing something like ), without entirely blocking all requests with Content-Type as application/xml? We might have some valid use cases where application/xml based requests should be allowed. – Tanmoy Sengupta Nov 04 '21 at 16:45
-
In the [Match Variable](https://learn.microsoft.com/en-us/azure/web-application-firewall/ag/custom-waf-rules-overview#match-variable-required) section it shows that `PostArgs` and `RequestBody` are match options, although it doesn't work (today, at least) for JSON or XML payloads. This is where you would want to make sure you are confident in your XML parser, that it's robust and up to date so this gets filtered out at the application level just like any other potential injection or XSS attack. – mherzig Nov 05 '21 at 17:46
-
Sorry for coming back a little late. Yes you are right, RequestBody match option does not work for JSON or XML payloads (https://docs.microsoft.com/en-us/azure/web-application-firewall/ag/custom-waf-rules-overview#fields-for-custom-rules). So it looks like it is not possible to block the malicious payload at WAF level without entirely blocking all XML requests. Is it possible to block such malicious JSON content with Azure APIM policies such as validate-content policy? If not, can we apply a validate-header policy at APIM to prevent all content-type request header with value 'application/xml'? – Tanmoy Sengupta Nov 15 '21 at 22:46