Difference between revisions of "Member Field Race Condition"

From OWASP
Jump to: navigation, search
Line 2: Line 2:
 
{{Template:Fortify}}
 
{{Template:Fortify}}
  
[[Category:FIXME|This is the text from the old template. This needs to be rewritten using the new template.]]
+
__TOC__
  
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
+
[[ASDR Table of Contents]]
  
[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
+
[[Category:FIXME|This is the text from the old template. This needs to be rewritten using the new template.]]
  
[[ASDR Table of Contents]]
+
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
__TOC__
+
  
  
Line 119: Line 118:
 
[[Category:Implementation]]
 
[[Category:Implementation]]
 
[[Category:Code Snippet]]
 
[[Category:Code Snippet]]
 +
[[Category:Vulnerability]]

Revision as of 15:18, 2 November 2008

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.

ASDR Table of Contents

Last revision (mm/dd/yy): 11/2/2008


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: