Because you can write arbitrary classes in the output, which can then be called (since dispatch is dynamic, and the output object is assumably either untyped or typed as the equivalent of `Object`). If you know which classes are available you can arbitrarily choose one as an attacker. JSON is data only, no functionality.
That doesn't make the format insecure, it means it is possible to write an insecure deserializer (which is possible for any format); it's also possible to write a secure deserializer, or one that can be configured based on use-case to balance exposed functionality vs. security appropriately for the use case.
One-size-fits-all security-through-lack-of-functionality is not necessarily the ideal approach for all data transfer applications.
But you need constant vigilance to keep the deserialiser secure. In JSON, any change to the deserialiser requires checking for security holes and DoS attacks. With this, you also need to check every method in every class in the set of possible deserialisation targets. If you don't have any methods and it's all just pure data (which would ensure equal security to JSON), then why are you using this instead of JSON. It is _absolutely_ security through lack of functionality. You simply grant less powers to untrusted inputs, as well you should. If you're designing a programming language intended to be written by hostile actors, you would not include primitives for opening files, running applications or spinning infinite loops, since they are all security issues. That's security through restriction of functionality. JSON is trivially secure, this is not. You need to maintain its security.
reply