Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: added normative text. tweaked some grammar for better exposition

Methods that both can modify a static field and also can be invoked from untrusted code to modify a static field must synchronize access to that the static field. That is necessary because there is no guarantee that untrusted clients will externally synchronize when accessing the field. Because a Even when client-side locking is a specified requirement of the method, untrusted clients can fail to synchronize (whether inadvertently or maliciously). Because the static field is shared by all clients, untrusted clients may violate the contract by failing to provide suitable locking.

...

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

Code Block
bgColor#FFCCCC
/** This class is not thread-safe */
public final class CountHits {
  private static int counter;

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

This class definition does not violate complies with rule VNA02-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 because untrusted code can purposely fail to externally synchronize access to the field.

...

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

Code Block
bgColor#ccccff
/** 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 Failure to internally synchronize access to static fields that may can be modified by untrusted code will result in incorrectly synchronized code, if risks incorrect synchronization, because the author of the untrusted code chooses to can ignore the synchronization policy (whether inadvertently or maliciously).

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

LCK05-J

low

probable

medium

P4

L3

...

TODO

Related Vulnerabilities

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

...

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="9aa5b8e89ca318aa-1709d92d-4e5a4fe8-8ee1844b-5a1be25154c9dfe8b537d991"><ac:plain-text-body><![CDATA[

[[API 2006

AA. Bibliography#API 06]]

 

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

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="b23f8ff5751f6307-b1a00497-45cf4a4e-8896abc9-32e99f55584b498060b35586"><ac:plain-text-body><![CDATA[

[[Bloch 2008

AA. Bibliography#Bloch 08]]

Item 67: "Avoid excessive synchronization"

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

...