...
| Wiki Markup |
|---|
Consider two classes belonging to different protection domains: one is malicious and extends 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, not overridden by the malicious class. In this case, the trusted superclass's permissions are examined to execute the method, and, as a result, the malicious object gets the method invoked inside the protection domain of the trusted superclass \[[Gong 2003|AA. Bibliography#GongReferences#Gong 03]\]. |
One commonly suggested solution is to place code at each point where the superclass can be instantiated to ensure that the instance being created has the same type as the superclass. When the type is found to be that of a subclass rather than the superclass's type, the checking code performs a security manager check to ensure that malicious classes cannot misuse the superclass. This approach is insecure because it allows a malicious class to add a finalizer and obtain a partially initialized instance of the superclass. This attack is detailed in rule OBJ11-J. Be wary of letting constructors throw exceptions.
...
| Wiki Markup |
|---|
This noncompliant code example uses the {{java.math.BigInteger}} class. This class is non-final and consequently extendable. This can be a problem when operating on an instance of {{BigInteger}} that was obtained from an untrusted client. For example, a malicious client could construct a spurious mutable {{BigInteger}} instance by overriding {{BigInteger}}'s member functions \[[Bloch 2008|AA. Bibliography#BlochReferences#Bloch 08]\]. |
The following code example demonstrates such an attack.
...
| 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#SCGReferences#SCG 09]\]. It also compares class types, in compliance with rule [OBJ09-J. Compare classes and not class names]. |
...
| Wiki Markup |
|---|
The instances of nonfinal classes obtained from untrusted sources must be used with care because their methods might be overridden by malicious methods. This potential vulnerability can be mitigated by making defensive copies of the acquired instances prior to use. This compliant solution demonstrates this technique for a {{BigInteger}} argument \[[Bloch 2008|AA. Bibliography#BlochReferences#Bloch 08]\]. |
| 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;
}
|
...
| Wiki Markup |
|---|
This solution prevents the finalizer attack; it applies to Java SE 6 and later versions, where throwing an exception before the {{java.lang.Object}} constructor exits prevents execution of finalizers \[[SCG 2009|AA. Bibliography#SCGReferences#SCG 09]\]. |
| Code Block | ||
|---|---|---|
| ||
public class BigInteger {
public BigInteger(String str) {
// throws a security exception if not allowed
this(str, check(this.getClass()));
}
private BigInteger(String str, boolean securityManagerCheck) {
// regular construction goes here
}
private static boolean check(Class c) {
// Confirm class type
if (c != java.math.BigInteger.class) {
// Check the permission needed to subclass BigInteger
// throws a security exception if not allowed
securityManagerCheck();
}
return true;
}
}
|
...
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="84a5ad37d7886bcf-fb18a84e-44384804-8f9c8d13-2e908e0c953e8a13dc7ea40b"><ac:plain-text-body><![CDATA[ | [[API 2006 | AA. Bibliography#API References#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="8491c2599bca50b7-36516e42-4fe74ece-b41eaf48-df8812c3a77ea26ac6fc1494"><ac:plain-text-body><![CDATA[ | [[Bloch 2008 | AA. Bibliography#Bloch References#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="375a4b633f650fec-2a6a19cc-46944530-b7b0910e-9fa967b7ca823220f925663b"><ac:plain-text-body><![CDATA[ | [[Gong 2003 | AA. Bibliography#Gong References#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="231d888c92d06b2f-63acbbf3-4ef24768-80f59c58-7e1cdc3f9e88446719291e4d"><ac:plain-text-body><![CDATA[ | [[Lai 2008 | AA. Bibliography#Lai References#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="eb6abd2c53be9e72-67c045e3-4e5e414b-adce9f80-375e0eca03c7a571e6e3db4e"><ac:plain-text-body><![CDATA[ | [[McGraw 1999 | AA. Bibliography#McGraw References#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="558c8bf95cc0f830-dc598759-426c4784-b26cad97-93e51af0b7d3965985cac32f"><ac:plain-text-body><![CDATA[ | [[Ware 2008 | AA. Bibliography#Ware References#Ware 08]] | ]]></ac:plain-text-body></ac:structured-macro> |
...