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 "Dead Code: Expression is Always True"

From OWASP
Jump to: navigation, search
Line 1: Line 1:
{{Template:Vulnerability}}
+
{{template:CandidateForDeletion}}
{{Template:Fortify}}
+
 
 +
#REDIRECT [[Failure to follow guideline/specification]]
 +
 
  
 
__TOC__
 
__TOC__
Line 7: Line 9:
  
 
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
 
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
 
 
[[Category:FIXME|This is the text from the old template. This needs to be rewritten using the new template.]]
 
  
  
Line 61: Line 60:
 
==References==
 
==References==
 
TBD
 
TBD
[[Category:FIXME|add links
 
 
In addition, one should classify vulnerability based on the following subcategories: Ex:<nowiki>[[Category:Error Handling Vulnerability]]</nowiki>
 
 
Availability Vulnerability
 
 
Authorization Vulnerability
 
 
Authentication Vulnerability
 
 
Concurrency Vulnerability
 
 
Configuration Vulnerability
 
 
Cryptographic Vulnerability
 
 
Encoding Vulnerability
 
 
Error Handling Vulnerability
 
 
Input Validation Vulnerability
 
 
Logging and Auditing Vulnerability
 
 
Session Management Vulnerability]]
 
 
__NOTOC__
 
 
 
[[Category:OWASP ASDR Project]]
 
[[Category:Code Quality Vulnerability]]
 
[[Category:Java]]
 
[[Category:Implementation]]
 
[[Category:Code Snippet]]
 
[[Category:Vulnerability]]
 

Revision as of 10:10, 14 February 2009

Template:CandidateForDeletion

#REDIRECT Failure to follow guideline/specification


ASDR Table of Contents

Last revision (mm/dd/yy): 02/14/2009


Description

This expression will always evaluate to true; the program could be rewritten in a simpler form. The nearby code may be present for debugging purposes, or it may not have been maintained along with the rest of the program. The expression may also be indicative of a bug earlier in the method.


Risk Factors

TBD

Examples

The following method never sets the variable secondCall after initializing it to true. (The variable firstCall is mistakenly used twice.) The result is that the expression firstCall || secondCall will always evaluate to true, so setUpForCall() will always be invoked.

	public void setUpCalls() {
	  boolean firstCall = true;
	  boolean secondCall = true;
	
	  if (fCall < 0) {
		cancelFCall();
		firstCall = false;
	  }
	  if (sCall < 0) {
		cancelSCall();
		firstCall = false;
	  }
	
	  if (firstCall || secondCall) {
		setUpForCall();
	  }
	}

Related Attacks

Related Vulnerabilities

Related Controls

Related Technical Impacts


References

TBD