Question: class resolution behavior during ObjectInputStream deserialization

[yannaingtun]

I noticed that ClassLoaderObjectInputStream overrides ObjectInputStream.resolveClass() in the following file:
src/Platform_Core/org/lobobrowser/store/ClassLoaderObjectInputStream.java

The implementation resolves classes using Class.forName(...) with a custom ClassLoader, without additional validation or restrictions.

I was wondering whether this stream is ever used on data that could be influenced by untrusted sources (for example cached content, downloaded data, or extensions).

If so, would the project be open to adding some defensive safeguards (such as restricting which classes can be deserialized), or clarifying the intended usage and trust assumptions in the documentation?

[hrj]

Yes, I think it's a good idea to add defensive safeguards. Can definitely review / accept a PR.

If the changes are large or impact performance, please discuss your plans here first, so that we can be aligned.

[hrj]

I could think of a couple of strategies:

• Ensure the class being deserialized is the one that is expected by the loader, by specifying it in the constructor of ClassLoaderObjectInputStream
• Have a whitelist of classes that can be loaded. Could be a list of fully qualified class names, or alternatively, define an interface that all deserialized classes have to implement. (Can be combined with above strategy).
• Enforce each deserialized class to have a key that is unique to the user profile. After deserialization, check whether the key in the loaded class matches the expected one. Circumventing this check would require a highly targeted attack.

[yannaingtun]

@hrj
Thanks for the suggestions. To keep the change minimal and low-risk, I plan to start with the first approach: passing an expected base class or interface via the constructor and rejecting deserialization if the resolved class does not match it. This provides a clear guardrail without changing the serialization format or impacting performance.

If that sounds OK, I’ll go ahead and open a PR with this approach.

[hrj]

@yannaingtun Sounds good, please go ahead!