Add `max_object_properties` parameter for `json_decode()`

[dktapps]

Description

Currently, json_decode() is vulnerable to HashTable supercolliding, when integers are used as property names in assoc mode, or perhaps when strings with some known hashes are used. This can be trivially exploited to cause major performance issues in applications which accept JSON payloads from a client.

While this is obviously a tough issue to solve globally, I think allowing users of json_decode() to limit the max number of object properties would mostly eliminate the problem for JSON handling, since most use cases should know or be able to predict what the max reasonable size of an object should be. I think this should probably be fairly easy to implement.

A precedent for this does exist: max_input_vars was implemented to mitigate HashDoS for query parameters over a decade ago, so I don't think this is a crazy idea.

Disclaimer: I did already report a security issue for this and was told to create a feature request, so here it is.

[cmb69]

Yeah, it probably makes sense to add some additional constrainability (neither strlen() nor $depth may be sufficient), but I'm not sure if an additional parameter is a good idea.

@bukka, thoughts?

[dktapps]

Yeah, length and depth aren't sufficient for this - in an application I develop, we can often see valid JWT of several MB where the vast majority of the data is occupied by just a couple of property values in base64. (I don't control the source).

[bukka]

I will repeat my comment in the security issue as it wasn't public.

Interestingly I'm just starting to look to native support for JsonSchema which could resolve this in a bit cleaner way as extra properties can be prohibited by "additionalProperties": false or with features from draft 6, you can explicitly define pattern in propertyNames or even do exactly what you propose for a single object with maxProperties.

Going forward we could also introduce mapping on specific classes so we could potentially allow some sip hash based object but that's really long shot.

I think JsonSchema could give us a bit more control. The question is if we would still need the specific option like this done on function level. There might be some use case for it so I will leave this open. Definitely something worth to think about.

[dktapps]

I think json-schema is an overkill solution for this. That would require a significant amount of work by users to seal up this problem, whereas an extra parameter would be a very trivial stopgap.