Versions Compared

Key

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

Sensitive operations must be protected by security manager checks. Refer to ENVxx-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 remove() method to allow the removal of its entries. However, the method is public and non-final which leaves it susceptible to malicious callers.

Code Block
bgColor#FFcccc
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 fine grained access control is not possible, that is, the result of the check can only be black and white. There is no way to enforce that all files with the dtd extension are allowed to be read whereas access to others is blocked. New code should rarely use the check*() APIs because the default implementations of the Java API already use them to protect sensitive operations.

Code Block
bgColor#FFcccc
SecurityManager sm = System.getSecurityManager();

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

Compliant Solution

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 manifold:

...

Code Block
bgColor#ccccff
// 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.

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

SEC36- J

high

probable

medium

P12

L1

Automated Detection

TODO

Related Vulnerabilities

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

References

Wiki Markup
\[[API 06|AA. Java References#API 06]\]

...