Posting well formed JSON document incorrectly triggering ASM SQL-INJ violation

Hi,

we've an SQL-INJ violation - 200002149 - being raised on ASM that I don't see a way to suppress nicely. The thing is the parameter name is being taken to be the first 50 characters or so of the JSON document that's being posted, so it's being interpreted at the wrong level as I see it. Given that I can't provide a specific parameter to match against, I'd have to presumably disable the vioaltion at URI level, which seems pretty unappealing, especially as it's a very valid check I'd like to keep in place.

The violation looks like this:

ContextParameter

Parameter LevelGlobal

Wildcard Parameter Name*

Actual Parameter Name{

"call": 0x9{ 0x9"callIdentifier":1636565498724567890123, 0x9"contactCentreIdentifier":"B", 0x9"employeeIdentifier":"000274", 0x9"lineOfBusinessIdentifier":TEST", 0x9"lineOfBusinessDescriptor":"T0x20E0x20S0x20T", 0x9"teamIdentifier":"TT1", 0x9"callType":"I", 0x9"callerTy

Parameter Value

Detected Keywords

So clearly the parameter name is junk, and there's not even any value extracted, so I'm a little lost how to get a hold of it.

update

Our devs have now find that the violation goes away if they remove a slash from the data way way down the list, changing "04/05" to just "0405" in the middle of a string of arbitrary english text.

We've avoided the issue by disabling that signature on the relevant URI but it feels like a horrible way to "fix" the issue.

This is all on 10.2.4 BTW, we were looking to upgrade to 11.2 to benefit from JSON inspection but other limitations prevent that.