Create support to t:jsonDecode

[zimmerle]

trafficstars

Should be very interesting to have such functionality. One utility will be to deal with JSON values in cookies...

Further information: https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/46

[sakalajuraj]

+1

... and to deal with standard parameters with JSON values ...

[zoltan-fedor]

+1

[adrianbn]

I'm looking forward to this too. I'm dealing with some applications that use form-url-enconded as the content-type but some of the arguments are then a JSON string. The current parser doesn't handle this well.

[alaa-ahmed]

I'm looking forward to this too. I'm dealing with an application that sends a lot of arguments including json parameters. I guess the need of this "t:jsonDecode" will increase. is the only solution available now is to exclude the json ARGS from a triggering rules target ?

[linhart1]

Hello, how is the state of this issue today? We want to activate mod_security but with the frameworks like ExtJS etc. the applications are using JSON objects in a huge amount, so there is the question, how to modify the rules they still protect before SQL injection and similar attacks but allow the JSON objects to be passed without problems. It there any workaround until this issue will be implemented? I'm sorry if I ask stupid question, but I am a newbie to mod_security and all this stuff...

[P-a-d-r-a-i-g]

I'm also interested in finding out about this. Has any progress been make on working with JSON encoded parameters?

[zimmerle]

Hi @padraigdoran,

Most likely it will be implemented as part of ModSecurity version 3, (aka libmodsecurity).

[P-a-d-r-a-i-g]

Hi again, just wondering what's the progress since last time I commented on this back in July 2016?

With modsecurity v2.9.2 there are still a lot of false positives when you have a Content-Type "application/x-www-form-urlencoded" post with some of the ARGS being JSON data.

The general Content-Type "application/json" with ctl:requestBodyProcessor=JSON works fine.

[martinhsv]

There is likely to be broad agreement that there would be value in having broader support for JSON parsing within ModSecurity.

One of the challenges with the t:jsonDecode solution is that it defies the standard expectation of what transformations do. The general pattern for a transformation is to take a single string and to modify it somehow and produce a different single string.

In contrast, to get the most usefulness out of JSON parsing, it needs to take a single string and produce, as output a set of key-value pairs, rather than a single modified item.

If we were to support something like this:

SecRule ARGS:a02 "@rx ^{" "id:1,phase:1,t:none,t:jsonDecode,block,log"

... and the input is:

GET /testget.php?a01=1&a02={"b1" : "mmm", "b2" : "nnn"}

Should we continue the rule processing against two different values? But what if the rule writer only wants to test one of the two? A big part of the value of JSON parsing should be that one can indeed focus on exactly the JSON key that one cares about. (This could also be an unwelcome performance hit if multiple rules have to parse the same JSON object.)

t:jsonDecode may still be worth considering but I think it has some fundamental problems.

We might want to think about other solutions such as:

A separate action (perhaps parseJson) that engages the JSON parser for a particular value relevant to that SecRule. Under this model a single rule such as

SecRule ARGS:a02 "@rx ^{" "id:1,phase:1,parseJson,pass,nolog"

... could populate the ARGS collection with both key-value pairs (for both "b1" "b2"). And one or more later rules could limit their application to the specific JSON keys of interest. And the subsequent substantive rules would not need to re-parse the same JSON blob.