Remove allowedPackages/classNames from JsonbPolymorphicType

[rmannibucau]

Ref: https://github.com/eclipse-ee4j/jsonb-api/blob/34327df5d7f0f5465a7b6eceaef60a50869106bf/api/src/main/java/jakarta/json/bind/annotation/JsonbPolymorphicType.java#L82

This configuration kind of enables to open the pandore box and inject vulnerable code. Since the JsonbPolymorphicType is designed to not need it we should dorp it before the first release of this API in favor of JsonbSubtype. More advanced cases can always use a deserializer/serializer or adapter which is the designed way to solve polymorphism in a general manner (JsonbPolymorphicType is just a default convenient way).

Similarl, classNames should be dropped.

[jansupol]

@rmannibucau Can you elaborate on the vulnerable code injection? How can the code be injected by an attacker?

[rmannibucau]

@jansupol without leaking too much data you just enable to instantiate any class so you are vulnerable to 0-day vulnerability. With JSON-B alone in the classpath it is not but you never have only JSON-B (you probably have at least the JRE ;)).

[jansupol]

@rmannibucau It sounds like you expect the allowedPackages to be set to {""} by the users, but the javadoc does not say the wildcards need to be supported, so the user sets the exact package, which is not in JRE. So the JSON-B implementation does not instantiate any* class, merely a class within the user package names. Correct?

[rmannibucau]

@jansupol strictly speaking it can be set to org,com but I also have in mind org.company.app.subpack.model case which still has this issue in most applications (as soon as you have an IoC or a framework with meta programming generally speaking and issue is not in these framework but serializers). Don't get me wrong, I would be very happy it is not the case - spent some night working on reported CVE of such a type and would have been happy to sleep instead ;).

[Verdent]

Dropped in #303