Member Field Race Condition

From OWASP
Jump to: navigation, search

This is a Vulnerability. To view all vulnerabilities, please see the Vulnerability Category page.


This article includes content generously donated to OWASP by Fortify.JPG.

Last revision (mm/dd/yy): 02/20/2009

Vulnerabilities Table of Contents

Description

Servlet member fields may allow one user to see another user's data.

Many Servlet developers do not understand that, unless a Servlet implements the SingleThreadModel interface, the Servlet is a singleton; there is only one instance of the Servlet, and that single instance is used and re-used to handle multiple requests that are processed simultaneously by different threads.

A common result of this misunderstanding is that developers use Servlet member fields in such a way that one user may inadvertently see another user's data. In other words, storing user data in Servlet member fields introduces a data access race condition.

Risk Factors

  • Talk about the factors that make this vulnerability likely or unlikely to actually happen
  • Discuss the technical impact of a successful exploit of this vulnerability
  • Consider the likely [business impacts] of a successful attack


Examples

The following Servlet stores the value of a request parameter in a member field and then later echoes the parameter value to the response output stream.

	public class GuestBook extends HttpServlet {
	
	   String name;
	
	   protected void doPost (HttpServletRequest req,
						   HttpServletResponse res) {
		 name = req.getParameter("name");
		 ...
		 out.println(name + ", thanks for visiting!");
	   }
	}

While this code will work perfectly in a single-user environment, if two users access the Servlet at approximately the same time, it is possible for the two request handler threads to interleave in the following way:

 Thread 1: assign "Dick" to name
 Thread 2: assign "Jane" to name
 Thread 1: print "Jane, thanks for visiting!"
 Thread 2: print "Jane, thanks for visiting!"

Thereby showing the first user the second user's name.

Related Attacks


Related Vulnerabilities


Related Controls


Related Technical Impacts


References

Note: A reference to related CWE or CAPEC article should be added when exists. Eg: