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
 
(2 intermediate revisions by the same user not shown)
Line 1: Line 1:
{{Template:Vulnerability}}
+
{{template:CandidateForDeletion}}
{{Template:Fortify}}
+
 
 +
#REDIRECT [[Failure to follow guideline/specification]]
  
[[Category:FIXME|This is the text from the old template. This needs to be rewritten using the new template.]]
 
  
 
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]]
 
__TOC__
 
  
  
Line 61: Line 56:
 
==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]]
 

Latest revision as of 23:28, 7 April 2009

Template:CandidateForDeletion

#REDIRECT Failure to follow guideline/specification


Last revision (mm/dd/yy): 04/7/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