Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

This compliant solution avoids the TOCTOU vulnerability by copying the mutable input and performing all operations on the copy. Consequently, an attacker's changes to the mutable input cannot affect the copy. Acceptable techniques include using a copy constructor or implementing the java.lang.Cloneable interface and declaring a public clone method (for classes not declared as final). In cases like HttpCookie where the mutable class is declared final — that is, it cannot provide an accessible copy method — perform a manual copy of the object state within the caller. See rule OBJ04-J. Provide mutable classes with copy functionality to allow passing instances to untrusted code safely for more information. Note that any input validation must be performed on the copy and not on the original object.

...

Some copy constructors and clone() methods perform a shallow copy of the original instance. For example, invocation of clone() on an array results in creation of an array instance whose elements have the same values as the original instance. This shallow copy is sufficient for arrays of primitive types , but fails to protect against TOCTOU vulnerabilities when the elements are references to mutable objects, such as an array of cookies. In this case, a deep copy must be performed that also duplicates the reference elements.

...

Some objects appear to be immutable because they have no mutator methods. For example, the java.lang.CharacterSequence interface describes an immutable sequence of characters. Note, however, that a variable of type CharacterSequence is a reference to an underlying object of some other class that implements the CharacterSequence interface; that other class may be mutable. When the underlying object changes, the CharacterSequence changes. Essentially, the java.lang.CharacterSequence interface omits methods that would permit object mutation through that interface, but lacks any guarantee of true immutability. Such objects must still be defensively copied before use. For the case of the java.lang.CharacterSequence interface, one permissible approach is to obtain an immutable copy of the characters by using the toString() method. Mutable fields should not be stored in static variables. When there is no other alternative, create defensive copies of the fields to avoid exposing them to untrusted code.

...

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="c435a2cd1c8525e8-2ce3bc39-40e246db-a8ff8498-8b41069531322446de428ccc"><ac:plain-text-body><![CDATA[

[[Bloch 2008

AA. Bibliography#Bloch 08]]

Item 39: Make defensive copies when needed

]]></ac:plain-text-body></ac:structured-macro>

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="9bcf9bf13c583cd1-d9a7f4f5-4049454a-83f48511-2a17f2b564aa0f40ce1de237"><ac:plain-text-body><![CDATA[

[[Pugh 2009

AA. Bibliography#Pugh 09]]

Returning references to internal mutable state

]]></ac:plain-text-body></ac:structured-macro>

...