This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "Unchecked Return Value: Missing Check against Null"
Weilin Zhong (talk | contribs) (Contents provided by Fortify.) |
m (Moved page into the right category. See Java space page for me details. Content has not been reviewed in this edit.) |
||
| (8 intermediate revisions by 3 users not shown) | |||
| Line 2: | Line 2: | ||
{{Template:Fortify}} | {{Template:Fortify}} | ||
| − | + | Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}''' | |
| − | + | [[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]] | |
==Description== | ==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. | 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. | ||
| Line 12: | Line 13: | ||
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. | 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. | 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. | ||
| Line 28: | Line 32: | ||
The traditional defense of this coding error is: | The traditional defense of this coding error is: | ||
| − | + | <pre> | |
| + | "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." | ||
| + | </pre> | ||
But attackers are skilled at finding unexpected paths through programs, particularly when exceptions are involved. | But attackers are skilled at finding unexpected paths through programs, particularly when exceptions are involved. | ||
| − | ==Related | + | ==Related [[Attacks]]== |
| + | |||
| + | * [[Attack 1]] | ||
| + | * [[Attack 2]] | ||
| + | |||
| + | |||
| + | ==Related [[Vulnerabilities]]== | ||
| + | |||
| + | * [[Ignored function return value]] | ||
| + | |||
| + | |||
| + | ==Related [[Controls]]== | ||
| + | |||
| + | * [[:Category:Input Validation]] | ||
| − | |||
| − | ==Related | + | ==Related [[Technical Impacts]]== |
| − | [[ | + | * [[Technical Impact 1]] |
| + | * [[Technical Impact 2]] | ||
| − | |||
| − | + | ==References== | |
| − | + | TBD | |
[[Category:Input Validation Vulnerability]] | [[Category:Input Validation Vulnerability]] | ||
| Line 50: | Line 70: | ||
[[Category:Code Snippet]] | [[Category:Code Snippet]] | ||
[[Category:Implementation]] | [[Category:Implementation]] | ||
| + | [[Category:Vulnerability]] | ||
| + | [[Category:OWASP ASDR Project]] | ||
Latest revision as of 21:52, 10 November 2017
This is a Vulnerability. To view all vulnerabilities, please see the Vulnerability Category page.
- This article includes content generously donated to OWASP by
Last revision (mm/dd/yy): 11/10/2017
Vulnerabilities Table of Contents
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
