...
This malicious BigInteger class is clearly mutable because of the setValue() method. Furthermore, the modPow() method is subject to precision loss. (See rules "NUM00-J. Detect or prevent integer overflow," "NUM11NUM08-J. Check floating-point inputs for exceptional values," "NUM15NUM12-J. Ensure conversions of numeric types to narrower types do not result in lost or misinterpreted data," and "NUM17NUM13-J. Beware Avoid loss of precision loss when converting primitive integers to floating-point" for more information.) Any code that receives an object of this class and assumes that the object is immutable will have unexpected behavior. This is particularly important because the BigInteger.modPow() method has several useful cryptographic applications.
...
| Wiki Markup |
|---|
This noncompliant code example installs a security manager check in the constructor of the {{BigInteger}} class. The security manager denies access when it detects that a subclass without the requisite permissions is attempting to instantiate the superclass \[[SCG 2009|AA. Bibliography#SCG 09]\]. It also compares class types, in compliance with rule "[OBJ06-J. Compare classes and not class names|OBJ09-J. Compare classes and not class names]." |
...
| Code Block | ||
|---|---|---|
| ||
public static BigInteger safeInstance(BigInteger val) {
// create a defensive copy if it is not java.math.BigInteger
if (val.getClass() != java.math.BigInteger.class)
return new BigInteger(val.toByteArray());
return val;
}
|
The rules "FIO00OBJ06-J. Defensively copy mutable inputs and mutable internal components" and "OBJ08OBJ04-J. Provide mutable classes with copy functionality to allow passing instances to untrusted code safely" discuss defensive copying in great depth.
...
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="b494a962bab9159e-a75c388f-4bc94bfc-be25ada9-3e1d38748328bff733c5b074"><ac:plain-text-body><![CDATA[ | [[API 2006 | AA. Bibliography#API 06]] | Class BigInteger | ]]></ac:plain-text-body></ac:structured-macro> |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="a18d4d2b6434f206-c27f5077-42854a1e-94d6b178-d6d733761ad1ea343302d4bb"><ac:plain-text-body><![CDATA[ | [[Bloch 2008 | AA. Bibliography#Bloch 08]] | Item 1: "Consider static factory methods instead of constructors" | ]]></ac:plain-text-body></ac:structured-macro> |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="22ec7243fa04056d-b47d0f21-40fa42b3-88808358-b4f58759e3bf153e1f18d66a"><ac:plain-text-body><![CDATA[ | [[Gong 2003 | AA. Bibliography#Gong 03]] | Chapter 6: "Enforcing Security Policy" | ]]></ac:plain-text-body></ac:structured-macro> |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="a34868d28272ca5a-067711f7-42e945b5-9b4d871c-f354f369338a9e4bb8406fcc"><ac:plain-text-body><![CDATA[ | [[Lai 2008 | AA. Bibliography#Lai 08]] | Java Insecurity: Accounting for Subtleties That Can Compromise Code | ]]></ac:plain-text-body></ac:structured-macro> |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="8e43d26de21d7a65-519a56b2-4157466a-89ec826a-59ad57c13c5de7b671de5c40"><ac:plain-text-body><![CDATA[ | [[McGraw 1999 | AA. Bibliography#McGraw 99]] | Chapter Seven Rule 3: "Make Everything Final, Unless There's a Good Reason Not To" | ]]></ac:plain-text-body></ac:structured-macro> |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="fec9764718ce66b2-0ab77df7-4acc4781-9e2f97c2-67bf097c206fd095728df282"><ac:plain-text-body><![CDATA[ | [[Ware 2008 | AA. Bibliography#Ware 08]] | ]]></ac:plain-text-body></ac:structured-macro> |
...