Page History

...

Documented design intent is irrelevant when dealing with untrusted code, because an attacker can always chose to ignore the documentation.

Noncompliant Code Example

This noncompliant code example does not synchronize access to the static counter field.

...

This class definition does not violate CON02-J. Ensure that compound operations on shared variables are atomic, which only applies to classes that promise thread-safety. However, this class has a mutable static counter field that is modified by the publicly accessible incrementCounter() method. Consequently, this class cannot be used securely by trusted client code, if untrusted code can purposely fail to externally synchronize access to the field.

Compliant Solution

This compliant solution uses a static private final lock to protect the counter field and, consequently, does not depend on any external synchronization. This solution also complies with CON07-J. Use private final lock objects to synchronize classes that may interact with untrusted code.

/** This class is thread-safe */
public final class CountHits {
  private static int counter;
  private static final Object lock = new Object();

  public void incrementCounter() {
    synchronized (lock) {
      counter++;
    }
  }
}

Risk Assessment

Failing to internally synchronize access to static fields that may be modified by untrusted code will result in incorrectly synchronized code, if the author of the untrusted code chooses to ignore the synchronization policy.

Automated Detection

TODO

Related Vulnerabilities

Any vulnerabilities resulting from the violation of this rule are listed on the CERT website.

References

\[[API 06|AA. Java References#API 06]\] 
\[[Bloch 08|AA. Java References#Bloch 08]\] Item 67: "Avoid excessive synchronization"

Issue Tracking

||Completed||Priority||Locked||CreatedDate||CompletedDate||Assignee||Name||

...