Azure Load Testing - ERROR o.a.j.e.j.j.JSONPostProcessor: net.minidev.json.parser.ParseException: Malicious payload, having non natural depths.

Hi,

since yesterday evening I've started seeing the following exception

ERROR o.a.j.e.j.j.JSONPostProcessor: net.minidev.json.parser.ParseException: Malicious payload, having non natural depths

when running my Azure Load Tests. It only occurs for big responses, especially the ones including JSONs with multiple nesting levels. Previously everything was working fine and when I run my test locally this exception doesn’t occur. I've found an article - https://github.com/karatelabs/karate/issues/2277 saying that there were some limitations introduced to the library net.minidev.json which is used by this extractor. Also it is described in https://libraries.io/maven/net.minidev:json-smart

Please, kindly assist in resolving the issue.

3

There are 3 best solutions below

0
On

Today I faced exactly the same error. I use this json library with Spark to parse lots of data. The exception is thrown here. JsonParser keeps track of depth visited so far and because the depth is larger than 400, JsonParser consider it as malicious json. So your json might be too deep.

For me, my json is small and the root cause is JsonParser is not thread safe, and I have multiple threads use same JsonParser which causes the variable depth being modified concurrently. The fix for me is easy, just use thread local JsonParser. Hope this helps!

0
On

We had similar issue in our project, there are 3 cases which can cause it:

  1. JSON with more than 400 nested arrays or objects
  2. JSONParsers are not thread-safe, if you use them from multiple-threads, they can throw unexpected exceptions which cause "depth" to get increased with each call. After some time it will reach 400 limit
  3. Parsing malformed JSONs - as with thread-safety, if exception is thrown during parsing depth may stay increased and accumulate

To solve it, do not share JSONParsers between threads, and do not reuse them after parsing, unless you can guarantee valid JSONs as input

0
On

We had the same issue in our system when we upgraded to net.minidev:json-smart:2.4.9. This version has some bug and it caused this. After we downgraded the lib it was working fine.