1289
Scope Impact Likelihood
If the shared variable contains sensitive data, it may be
manipulated or displayed in another user session. If this
data is used to control the application, its value can be
manipulated to cause the application to crash or perform
poorly.
Detection Methods
Automated Static Analysis
Automated static analysis, commonly referred to as Static Application Security Testing (SAST),
can find some instances of this weakness by analyzing source code (or binary/compiled code)
without having to execute it. Typically, this is done by building a model of data flow and control
flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input)
with "sinks" (destinations where the data interacts with external components, a lower layer such
as the OS, etc.)
Effectiveness = High
Potential Mitigations
Phase: Implementation
Remove the use of static variables used between servlets. If this cannot be avoided, use
synchronized access for these variables.
Demonstrative Examples
Example 1:
The following code implements a basic counter for how many times the page has been accesed.
Example Language: Java (Bad)
public static class Counter extends HttpServlet {
static int count = 0;
protected void doGet(HttpServletRequest in, HttpServletResponse out)
throws ServletException, IOException {
out.setContentType("text/plain");
PrintWriter p = out.getWriter();
count++;
p.println(count + " hits so far!");
}
}
Consider when two separate threads, Thread A and Thread B, concurrently handle two different
requests:
• Assume this is the first occurrence of doGet, so the value of count is 0.
• doGet() is called within Thread A.
• The execution of doGet() in Thread A continues to the point AFTER the value of the count
variable is read, then incremented, but BEFORE it is saved back to count. At this stage, the
incremented value is 1, but the value of count is 0.
• doGet() is called within Thread B, and due to a higher thread priority, Thread B progresses to
the point where the count variable is accessed (where it is still 0), incremented, and saved.
After the save, count is 1.
• Thread A continues. It saves the intermediate, incremented value to the count variable - but
the incremented value is 1, so count is "re-saved" to 1.
At this point, both Thread A and Thread B print that one hit has been seen, even though two
separate requests have been processed. The value of count should be 2, not 1.
CWE Version 4.14
CWE-568: finalize() Method Without super.finalize()
CWE-568: finalize() Method Without super.finalize()