Modsecurity: GET request with application/json and valid JSON being returned trips 200002

[troykelly]

Making a GET request with Content-Type of application/json seems to trigger error 200002 even when the server response is valid JSON.

I feel like this could be related to https://github.com/SpiderLabs/ModSecurity/issues/1392 - but we are returning a valid JSON body

[victorhora]

@troykelly Which version of ModSecurity you are using? Please provide as much detail as possible so the community can better assist you. Thanks.

[troykelly]

@victorhora Thank you for getting back to me.
We are using v3 inside a container (from https://hub.docker.com/r/really/nginx-modsecurity/ )
Most everything works, it just seems that GET requests for JSON are triggering this rule.
The request is to https://sessions.reallyreally.io/token which when content-type is "application/json" returns JSON. Eg:

curl -X GET \
  https://sessions.reallyreally.io/token \
  -H 'Cache-Control: no-cache' \
  -H 'Content-Type: application/json' \
  -H 'origin: https://really.ai' \
  -H 'referer: https://really.ai/' \
  -H 'x-really-referer: https://really.ai/'

When we have ModSecurity enabled for that host - it triggers rule 200002.

[victorhora]

Hi @troykelly it seems like the behaviour between v2 and v3 are different even when compared to results of testing with at #1392. We will be looking into this.

In the meantime, I would suggest that you disable or change rule 200002 as a temporary workaround.

Thanks for reporting!

[johnfilo]

As a work around, would chaining rule 200001 like below exclude it from processing the request body on GET requests that FWR include the Content-Type: application/json header

BEFORE:
SecRule REQUEST_HEADERS:Content-Type "application/json" \
"id:'200001',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=JSON"

AFTER:
SecRule REQUEST_HEADERS:Content-Type "application/json" \
"chain,id:'200001',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=JSON"
SecRule REQUEST_METHOD "!^(GET)$"

I've tested it and it seems to work for me.

[troykelly]

I will have to see if I can do that from the nginx config (I'm new here - not so great at rules and configs) and give it a go.
We are trying to stick to a generic container with all rules - and then exceptions for specific paths/locations only.

[zimmerle]

Regression test to reproduce that issue: https://gist.github.com/zimmerle/7cd25538a7f2a1b7fa977d4b0b8dc5e3

[zimmerle]

I am not sure if that is a bug or a feature. After all, the header is telling ModSecurity that there is o JSON to come and it never came, so it naturally raise: _parse error: premature EOFx0a_. Similar to the scenario described on: #1392.

I think the suggestion given @johnfilo is valid and it has a semantic in the context of the application in question. Therefore, I am closing this as an issue, but, feel free to continue the discussion in case you have a different point of view.