...
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 "OBJ05OBJ11-J. Prevent access to partially initialized objects."Be wary of letting constructors throw exceptions.
For non-final classes, the method that performs the security manager check must be invoked as an argument to a private constructor to ensure that the security check is performed before any superclass's constructor can exit.
...
Unfortunately, throwing an exception from the constructor of a non-final class is insecure because it allows a finalizer attack. (See rule "OBJ05OBJ11-J. Prevent access to partially initialized objects."Be wary of letting constructors throw exceptions.)
Compliant Solution (Final)
...
This compliant solution invokes a security manager check as a side-effect of computing the Boolean value passed to a private constructor (as seen in rule "OBJ05OBJ11-J. Prevent access to partially initialized objects"Be wary of letting constructors throw exceptions). The rules for order of evaluation require that the security manager check must execute before invocation of the private constructor. Consequently, the security manager check also executes before invocation of any superclass's constructor. Note that the security manager check is made without regard to whether the object under construction has the type of the parent class or the type of a subclass (whether trusted or not).
...
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="c4f597cc97a7a5de-13c47cb8-426e4a96-96e492ed-0c7071a392c0f2b1458ae04b"><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="367b6c7efc32e77c-e59dc116-411f472c-9372aee0-36bf4ece420a54c8da1be005"><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="7ac233c73b3788c3-e8063106-49734aba-9e9fbf23-a9df0a824b50aae5a22073dd"><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="93d1fd956b8f490b-128fc260-42cc4d3c-bfe8bd7f-1a1c5a97f7fd7edd47e72d28"><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="4d18d01e5f48d492-97e788c8-449d42af-a799b66e-34266255e74894d6121064f1"><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="2e817f027e2cbb9b-c5d08b32-435a45fe-8e7b85e3-892d49992d11340026cf64dd"><ac:plain-text-body><![CDATA[ | [[Ware 2008 | AA. Bibliography#Ware 08]] | ]]></ac:plain-text-body></ac:structured-macro> |
...