Methods return values to signify failure or success or, at other times, to update the caller's objects or fields. Security risks can arise if return values are simply ignored or if suitable action is not taken on their receipt. Return values may be ignored intentionally or even unintentionally. For example, when getter methods are named after an action (such as ProcessBuilder.redirectErrorStream(boolean redirectErrorStream)
), a programmer may not realize that a return value is expected. It is important to check the API documentation so that return values are not ignored.
This noncompliant code example attempts to delete a file, but does not check that the operation succeeds.
File someFile = new File("someFileName.txt"); // do something with someFile someFile.delete(); |
In the compliant solution, the (boolean
) value returned by the delete()
method is checked and, if necessary, the error is handled.
File someFile = new File("someFileName.txt"); // do something with someFile if (!someFile.delete()) { // handle the fact that the file has not been deleted } |
This noncompliant code example ignores the return value while making use of the String.replace
method. As a result, the original string is not updated even though it seems otherwise. The String.replace()
method does not modify the state of the String
but instead, returns a reference to a new String
object with the replacements in place.
public class Ignore { public static void main(String[] args) { String original = "insecure"; original.replace( 'i', '9' ); System.out.println(original); } } |
This compliant solution correctly updates the original
String
object by assigning to it the return value.
public class DoNotIgnore { public static void main(String[] args) { String original = "insecure"; original = original.replace( 'i', '9' ); System.out.println(original); } } |
Another source of coding bugs caused by ignoring return values is detailed in FIO02-J. Keep track of bytes read and account for character encoding while reading data.
Ignoring method return values may lead to unanticipated program behavior.
Rule |
Severity |
Likelihood |
Remediation Cost |
Priority |
Level |
---|---|---|---|---|---|
EXP02- J |
medium |
probable |
medium |
P8 |
L2 |
TODO
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
This rule appears in the C Secure Coding Standard as EXP12-C. Do not ignore values returned by functions.
This rule appears in the C++ Secure Coding Standard as EXP12-CPP. Do not ignore values returned by functions or methods.
\[[API 06|AA. Java References#API 06]\] method [delete()|http://java.sun.com/javase/6/docs/api/java/io/File.html#delete()] \[[API 06|AA. Java References#API 06]\] method [replace()|http://java.sun.com/javase/6/docs/api/java/lang/String.html#replace(char,%20char)] \[[Green 08|AA. Java References#Green 08]\] ["String.replace"|http://mindprod.com/jgloss/gotchas.html] \[[Pugh 09|AA. Java References#Pugh 09]\] misusing putIfAbsent \[[MITRE 09|AA. Java References#MITRE 09]\] [CWE ID 252|http://cwe.mitre.org/data/definitions/252.html] "Unchecked Return Value" |
EXP01-J. Ensure a null pointer is not dereferenced 04. Expressions (EXP) EXP03-J. Do not compare String objects using equality or relational operators