Difference between revisions of "Unchecked Return Value: Missing Check against Null"

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__
 +
 
 +
[[ASDR Table of Contents]]
 +
 
  
 
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
 
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
  
[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
 
  
[[ASDR Table of Contents]]
+
[[Category:FIXME|This is the text from the old template. This needs to be rewritten using the new template.]]
__TOC__
+
  
  
Line 79: Line 81:
 
[[Category:Code Snippet]]
 
[[Category:Code Snippet]]
 
[[Category:Implementation]]
 
[[Category:Implementation]]
 +
[[Category:Vulnerability]]
 +
[[Category:OWASP ASDR Project]]

Revision as of 08:54, 9 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.


Contents


ASDR Table of Contents


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


Description

Ignoring a method's return value can cause the program to overlook unexpected states and conditions.

Just about every serious attack on a software system begins with the violation of a programmer's assumptions. After the attack, the programmer's assumptions seem flimsy and poorly founded, but before an attack many programmers would defend their assumptions well past the end of their lunch break.

Two dubious assumptions that are easy to spot in code are "this function call can never fail" and "it doesn't matter if this function call fails". When a programmer ignores the return value from a function, they implicitly state that they are operating under one of these assumptions.


Risk Factors

TBD

Examples

The following code does not check to see if the string returned by getParameter() is null before calling the member function compareTo(), potentially causing a null dereference.

	String itemName = request.getParameter(ITEM_NAME);
	if (itemName.compareTo(IMPORTANT_ITEM)) {
		...
	}
	...

The traditional defense of this coding error is:

"I know the requested value will always exist because ... If it does not exist, the program
cannot perform the desired behavior so it doesn't matter whether I handle the error or simply 
allow the program to die dereferencing a null value."

But attackers are skilled at finding unexpected paths through programs, particularly when exceptions are involved.


Related Attacks


Related Vulnerabilities


Related Controls


Related Technical Impacts


References

TBD