[HTTPCLIENT-2022] HttpCacheEntrySerializationException Message Unused

• Type: Bug
• Status: Resolved
• Priority: Minor
• Resolution: Fixed
• Affects Version/s: 4.5.10
• Fix Version/s: 4.5.11
• Component/s: HttpCache
• Flags: Patch
• Assignee: Unassigned
• Reporter: Olof Larsson
• Created: 06/Nov/19 07:16
• Updated: 06/Nov/19 17:49
• Resolved: 06/Nov/19 17:49

Description

In Short
The HttpCacheEntrySerializationException message is unused in one of the class constructors. This looks like an easily corrected coding mistake.

Further Explanation
DefaultHttpCacheEntrySerializer has a code section looking like this:

@Override
protected Class<?> resolveClass(final ObjectStreamClass desc) throws IOException, ClassNotFoundException {
    if (isProhibited(desc)) {
        throw new HttpCacheEntrySerializationException(String.format(
                "Class %s is not allowed for deserialization", desc.getName()));
    }
    return super.resolveClass(desc);
}

The constructor used looks like this:

public HttpCacheEntrySerializationException(final String message) {
    super();
}

This means the useful error message created using string format will actually never be displayed in an error stack trace.

User Case
When trying to upgrade from 4.5.8 to 4.5.10 one of my applications stopped working.

I have a custom implementation of persistent disk cache storage. It makes use of the DefaultHttpCacheEntrySerializer.

The stack trace did not tell me what was wrong (because the informative string is not passed along in the constructor)

...

Caused by: java.lang.RuntimeException: org.apache.http.client.cache.HttpCacheEntrySerializationException
    at com.looklet.net.httpclientwrapper.executor.RequestExecutorImpl.executeToResponse(RequestExecutorImpl.java:46)
    at com.looklet.net.httpclientwrapper.executor.RequestExecutorImpl.execute(RequestExecutorImpl.java:66)
    ... 63 more
Caused by: org.apache.http.client.cache.HttpCacheEntrySerializationException
    at org.apache.http.impl.client.cache.DefaultHttpCacheEntrySerializer$RestrictedObjectInputStream.resolveClass(DefaultHttpCacheEntrySerializer.java:107)
    at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1868)
    at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1751)

...

I had to use a debugger to figure out that the message was:
"Class [C is not allowed for deserialization"

Apparently this security patch forbids char arrays? (https://reverseengineering.stackexchange.com/questions/17429/b-symbol-in-java-bytecode)

On a side note maybe the whitelist could be expanded to allow all kinds of primitives and arrays of primitives?

Issue Links

• is related to: HTTPCLIENT-2023 Whitelist Char Array in DefaultHttpCacheEntrySerializer
• links to: GitHub Pull Request #169