Page History

Sensitive operations must be protected by security manager checks. Refer to guideline ENV02-J. Create a secure sandbox using a Security Manager to learn about the importance of performing security checks and limiting code to a secure sandbox.

Noncompliant Code Example

This noncompliant code example instantiates a Hashtable and defines a removeEntry() method to allow the removal of its entries. However, the method is public and non-final, which leaves it susceptible to malicious callers.

class SensitiveHash {
  Hashtable<Integer,String> ht = new Hashtable<Integer,String>();

  public void removeEntry(Object key) {
    ht.remove(key);
  }
}

Compliant Solution

This compliant solution demonstrates how a security check can be installed to protect entries from being maliciously removed from the Hashtable instance. A SecurityException is thrown if the caller does not possess the java.security.SecurityPermission removeKeyPermission.

...

The SecurityManager.checkSecurityAccess() method determines whether the action controlled by the particular permission is allowed or not.

Noncompliant Code Example

This noncompliant code example uses the SecurityManager.checkRead() method to check whether the file schema.dtd can be read from the file system. The problem with the check*() methods is that lack support for fine grained access control is not possible, that is. For example, the result of the check can only be black and white. There is no way to enforce that check*() methods are insufficient to enforce a policy permitting read access to all files with the dtd extension are allowed to be read whereas access to others is blockedand forbidding read access to all other files. New code should rarely use the check*() APIs methods because the default implementations of the Java API libraries already use them these methods to protect sensitive operations.

SecurityManager sm = System.getSecurityManager();

if (sm != null) {  // check ifwhether file canmay be read
  sm.checkRead("/local/schema.dtd");
}

Compliant Solution

Two methods, J2SE 1.2 added two methods — checkPermission(Permission perm) and checkPermission(Permission perm, Object context), were added — to the SecurityManager class in J2SE 1.2. The motivations for this change were manifoldincluded:

• The checkPermission() methods eliminated the requirement of hardcoding Eliminating the necessity to hardcode names of the checks in the method namenames.
• They used only one copy of Encapsulating the complicated algorithms and code for examining the Java runtime by using in a common single checkPermission() method.
• Newer permissions for resources could be easily added by encapsulating them in a new Permission subclassSupporting introduction of additional permissions by subclassing the Permission class.

The single argument checkPermission() method uses the context of the currently executing thread environment to perform the checks. If the context has the permissions defined in the local policy file, the check succeeds, otherwise a SecurityException is thrown.

...

// Take the snapshot of the required context, store in acc and pass it to another context
AccessControlContext acc = AccessController.getContext();

// Accept acc in another context and invoke checkPermission() on it
acc.checkPermission(perm);

Risk Assessment

Failing to enforce security checks in code that performs sensitive operations can lead to malicious tampering of sensitive data.

Automated Detection

Identifying sensitive operations requires assistance from the programmer; fully-automated identification of sensitive operations is beyond the current state of the art.

Given knowledge of which operations are sensitive as well as which security checks must be enforced for those operations, an automated tool could reasonably enforce the invariant that the sensitive operations are invoked only from contexts where the security checks have been performed.

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this guideline on the CERT website.

Bibliography

\[[API 2006|AA. Bibliography#API 06]\]

...