Versions Compared

Key

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

If When security checks are based on untrusted sources, it becomes possible to bypass them. It is recommended to defensively copy the those sources could be compromised in such a way that the security check could be bypassed. The untrusted object or parameter should be defensively copied before the security check is carried out. For this purpose deep copies must be created as opposed to using The copy operation must be a deep copy; the implementation of the clone() method to create shallow copiesmay produce a shallow copy, which could still be compromised. Further, the implementation of the clone() method may be provided by the attacker. See guidelines MET08-J. Do not use the clone method to copy untrusted method parameters and FIO00-J. Defensively copy mutable inputs and mutable internal components for more information.

...

Security checks should not be based on untrusted sources. This compliant solution ensures that the java.io.File object cannot be untrusted. This is achieved by declaring can be trusted, because:

  • Our reference to it is declared to be final. Thus, we know that the attacker cannot modify the reference and substitute a different object.
  • We create our own new java.io.File

...

  • object using the standard java.io.File constructor. This ensures that any methods we invoke on the File object are the standard library methods rather than overriding methods potentially provided by the attacker.

File object is created in the openFile() method. Note that using the clone() method instead of the openFile() method would copy the attacker's class, which is not desirable. (Refer to guideline MET08-J. Do not use the clone method to copy untrusted method parameters.)

...