Page History

Methods that can both can modify a static field and also can be invoked from untrusted code must synchronize access to the static field. 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.unmigrated-wiki-markup

According to Joshua Bloch \[ [Bloch 2008|AA. Bibliography#Bloch 08]\]]:

If a method modifies a static field, you must synchronize access to this field, even if the method is typically used only by a single thread. It is not possible for clients to perform external synchronization on such a method because there can be no guarantee that unrelated clients will do likewise.

...

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

/** This class is not thread-safe */
public final class CountHits {
  private static int counter;

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

This class definition complies with rule VNA02-J. Ensure that compound operations on shared variables are atomic, which applies 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, because 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 , 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.

/** 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

Failure to internally internally synchronize access to static fields that can be modified by by untrusted code risks incorrect synchronization , because the author of the untrusted code can inadvertently or maliciously ignore the synchronization policy (whether inadvertently or maliciously).

Related Vulnerabilities

...

Automated Detection

Related Guidelines

Bibliography

...

[

[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="2832084c-0e2a-4257-aef4-e718ae6844c4"><ac:plain-text-body><![CDATA[

[[Bloch 2008

AA. Bibliography#Bloch 08]]

Item 67: "Avoid excessive synchronization"

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

Issue Tracking

...

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

...

Image Added Image Added Image Removed      08. Locking (LCK)