...
| Wiki Markup |
|---|
Consider two classes belonging to different protection domains; one is malicious, and estendsextends the other, which is trusted. Consider an object of the malicious subclass with a fully qualified invocation of a method defined by the trusted superclass, and not overridden by the malicious class. In this case, the trusted superclass's permissions are examined to execute the method, with the consequence that the malicious object gets the method invoked inside the protection domain of the trusted superclass. \[[Gong 2003|AA. Bibliography#Gong 03]\]. |
...
A method which receives an untrusted, non-final input argument must beware that other methods or threads might modify the input object. Some methods try to prevent modification by making a local copy of the input object. This does not provide sufficient protection, as a shallow copy of an object may still allow it to point to mutable sub-objects, which may still be modified by other methods or threads. Some methods go farther and perform a deep copy of the input object. This mitigates the problem of modifiable sub-objects, but the method might still be passed a mutable object that estends extends the input object class.
Noncompliant Code Example (BigInteger)
...
This malicious BigInteger class is clearly mutable, thanks to the setValue() method. Furthermore, the modPow() method is subject to precision loss (see NUM00-J. Detect or prevent integer overflow, NUM11-J. Check floating point inputs for exceptional values, NUM15-J. Ensure conversions of numeric types to narrower types do not result in lost or misinterpreted data and NUM17-J. Beware of precision loss when converting primitive integers to floating-point for more infoinformation). Any code that receives an object of this class, and assumes it is imutable immutable will have unexpected behavior. (The BigInteger.modPow() method has several useful cryptographic applications.)
...