Empty body blocked if Content-type: text/xml

[dstrecker]

I have a client sending GET requests without a body but with Content-type: text/xml. They are blocked by rule 200002 (using the recommended config) with a 400 Bad Request.

I understand it makes no sense to send this header, but it also should do no harm. Other content types like application/json are not blocked.

What options do I have apart from disabling rule 200002 for this URI? I have no control over the client of course ...

Audit log entry:

---y6ONld7Y---A--
[06/Mar/2020:13:44:10 +0100] 158349865029.168568 194.209.121.33 56427 443
---y6ONld7Y---B--
GET /.../foo.json?key=value&key2=value2&key3=value3&key4=value4 HTTP/1.1
Host:
Accept: /
User-Agent:
Content-type: text/xml

---y6ONld7Y---D--

---y6ONld7Y---F--
HTTP/1.1 200

---y6ONld7Y---H--
ModSecurity: Access denied with code 200 (phase 2). Matched "Operator Eq' with parameter 0' against variable REQBODY_ERROR' (Value: 1' ) [file "/.../modsecurity.conf"] [line "61"] [id "200002"] [rev ""] [msg "Failed to parse request body."] [data "XML parsing error: XML: Failed parsing document."] [severity "2"] [ver ""] [maturity "0"] [accuracy "0"] [hostname ""] [uri ".../foo.json"] [unique_id "158349865029.168568"] [ref "v326,1"]

---y6ONld7Y---I--

---y6ONld7Y---J--

---y6ONld7Y---Z--

To Reproduce

curl -H "Content-type: text/xml" https://host.domain/path

Expected behavior

The request should not be blocked.

Server:

• ModSecurity v3.0.4
• WebServer: Apache 2.4
• OS (and distro): RHEL 7

Rule Set:

• CRS 3.2.0

[jeremyjpj0916]

GET requests without a body but with Content-type: text/xml

Pretty sure this that makes sense, GETs should not set a Content-type.

[martinhsv]

Hi @dstrecker ,

Your initial thought is basically correct: what you want to do in this situation is disable the rule. A safer way to do this can be to set your conditions as narrowly as possible based on whatever well-understood false positive that you are seeing.

For example, you could do something like this:

SecRule REQUEST_METHOD "@rx ^GET$" "id:100,phase:1,chain,pass,nolog,t:none"
    SecRule REQUEST_HEADERS:Content-Length "@streq 0" "chain"
    SecRule REQUEST_HEADERS:Content-Type "@streq text/xml" "t:none,ctl:ruleRemoveById=200002"

If this only occurs with a particular URI, you could add a test for that to the chained rule as well.