Comment Re:Not a vulnerability in Java Commons Library (Score 1) 115
In an object oriented language an object is a combination of data and behavior (methods). If you want to transfer data across the wire with an object oriented system the natural place to put that data is into an object. Not trusting object serialization originates from a lack of knowledge on what is happening and you should educate yourself. Everything you want to know about serialization is here: https://docs.oracle.com/javase...
What you are doing by designing your own data formats is adding inherent whitelisting. Your reader/parser probably does a "new" on a specific set of classes. That prevents the type of vulnerability (arbitrary class loading) being discussed in the article but also requires you to reinvent the wheel for every data format.
You could have been using http://docs.oracle.com/javase/... to serialize data since that would give you an easy way to inspect the data type before recreating. You can even setup inspection/whitelisting with traditional object serialization if you wanted to: http://www.ibm.com/developerwo... .
Nowadays JSON is a pretty universal data format for wire transfers. You can deserialize JSON to trusted data-centric classes like Map, List, String, Integer, etc. That would give you universal encoding/decoding without arbitrary class loading. Unless you are required by a 2nd party to use some proprietary wire format there is no reason to roll-your-own encoding/decoding.