Delete deprecated method Base64.decodeToObject() and related methods #444
Description
At of the last official ESAPI release (2.1.0.1), I had marked Base64.decodeToObject() as deprecated and changed it so that in order for it to be used, the System property "org.owasp.esapi.enableUnsafeSerialization" had to be set to true in order to use it. (The current default is to throw an UnsupportedOperationException if that property is not set to true.) This behavior was chosen to prevent Base64.decodeToObject() as being used to facilitate a remote code injection attacks based on non-validated Java deserialization. This was all documented in GitHub issue #354 and referenced as part of the last set of release notes.
The Javadoc for this deprecated Base64.decodeToObject() method clearly states that
Because of security issues, this method will be removed from ESAPI in a future release and no substitute is planned.
However, if we delete the previously deprecated Base64.decodeToObject(), I think it makes little sense to keep either of the 2 Base64.encodeObject() methods (since they were all intended to work together), but the downside of that is I previously failed to mark those two Base64.encodeObject() as deprecated in the last 2.1.0.1 release! (Oops!)
While I definitely am planning of deleting deprecated Base64.decodeToObject(), I am on the fence about how to approach the two Base64.encodeObject() methods.
So, given the above situation, for our upcoming ESAPI release that we are preparing, which do you think is the best approach?
- Delete the two
Base64.encodeObject()methods even though they had not previously been deprecated. - Make no changes now for those 2 methods except marking the 2
encodeObject()methods as deprecated with the idea that we wait until the next release (hopefully not another 3 years) until we do the actual deletion of those methods.
I'd prefer to take option 1, and it seems generally safe because it seems very unlikely that an application is using either of the Base64.encodeObject() methods without also using the Base64.decodeToObject() method, but it is possible. E.g., one application could be invoking the Base64.encodeOjbect() method and storing the base64-encoded results into a DBMS and another application extracting the base64-encoded string from the DBMS and invoking Base64.decodeToObject() method (either with an older version of ESAPI or using 2.1.0.1 and setting the System property "org.owasp.esapi.enableUnsafeSerialization" to true. Breaking the code of the latter application is more or less fair game since it would have to be ignoring the deprecation warnings about Base64.decodeToObject().