Reported by David Jorm:
A remote attacker could use this flaw to trigger the execution of the deserialization methods in any serializable class deployed on the server. This could lead to a variety of security impacts depending on the deserialization logic of these classes.
This might sound innocuous at first, but it is surprisingly common for classes to implement their own deserialization methods which are not secure when an attacker can call them with an arbitrary crafted instance of the object. This article provides a good explanation of the issue, and a solution to it:
Reported by David Jorm:
A remote attacker could use this flaw to trigger the execution of the deserialization methods in any serializable class deployed on the server. This could lead to a variety of security impacts depending on the deserialization logic of these classes.
This might sound innocuous at first, but it is surprisingly common for classes to implement their own deserialization methods which are not secure when an attacker can call them with an arbitrary crafted instance of the object. This article provides a good explanation of the issue, and a solution to it:
http://www.ibm.com/developerworks/library/se-lookahead/
The text was updated successfully, but these errors were encountered: