...
| Wiki Markup |
|---|
According to Joshua Block \[[Bloch 082008|AA. Java References#Bloch 08]\] |
...
Documented design intent is irrelevant when dealing with untrusted code , because an attacker can always chose to ignore the documentation.
...
This class definition does not violate guideline 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 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 external synchronization. This solution also complies with guideline LCK00-J. Use private final lock objects to synchronize classes that may interact with untrusted code.
...
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.
Rule Guideline | Severity | Likelihood | Remediation Cost | Priority | Level |
|---|---|---|---|---|---|
CON12 LCK05-J | low | probable | medium | P4 | L3 |
Automated Detection
TODO
Related Vulnerabilities
...
References
| Wiki Markup |
|---|
\[[API 062006|AA. Java References#API 06]\] \[[Bloch 082008|AA. Java References#Bloch 08]\] Item 67: "Avoid excessive synchronization" |
Issue Tracking
...
...