Difference between revisions of "Member Field Race Condition"

From OWASP
Jump to: navigation, search
 
Line 1: Line 1:
 
{{Template:Vulnerability}}
 
{{Template:Vulnerability}}
 
{{Template:Fortify}}
 
{{Template:Fortify}}
<br>
 
 
[[ASDR Table of Contents]]
 
 
[[Category:FIXME|This is the text from the old template. This needs to be rewritten using the new template.]]
 
  
 
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
 
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
  
 +
[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
  
 
==Description==
 
==Description==

Latest revision as of 20:37, 20 February 2009

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: