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 2: Line 2:
 
{{Template:Fortify}}
 
{{Template:Fortify}}
  
==Abstract==
+
[[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}}'''
 +
 
 +
[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
 +
 
 +
[[ASDR Table of Contents]]
 +
__TOC__
  
This expression will always evaluate to true.
 
  
 
==Description==
 
==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.
  
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.
 
  
==Examples ==
+
==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.
 
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.
  
Line 34: Line 42:
 
</pre>
 
</pre>
  
==Related Threats==
+
==Related [[Attacks]]==
 +
* [[Attack 1]]
 +
* [[Attack 2]]
 +
 
 +
==Related [[Vulnerabilities]]==
 +
* [[Vulnerability 1]]
 +
* [[Vulnerabiltiy 2]]
 +
 
 +
==Related [[Controls]]==
 +
* [[Control 1]]
 +
* [[Control 2]]
 +
 
 +
==Related [[Technical Impacts]]==
 +
* [[Technical Impact 1]]
 +
* [[Technical Impact 2]]
 +
 
 +
 
 +
==References==
 +
TBD
 +
[[Category:FIXME|add links
  
==Related Attacks==
+
In addition, one should classify vulnerability based on the following subcategories: Ex:<nowiki>[[Category:Error Handling Vulnerability]]</nowiki>
  
==Related Vulnerabilities==
+
Availability Vulnerability
  
==Related Countermeasures==
+
Authorization Vulnerability
  
==Categories==
+
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:Code Quality Vulnerability]]
 
 
[[Category:Java]]
 
[[Category:Java]]
 
 
[[Category:Implementation]]
 
[[Category:Implementation]]
 
 
[[Category:Code Snippet]]
 
[[Category:Code Snippet]]

Revision as of 22:11, 23 September 2008

This is a Vulnerability. To view all vulnerabilities, please see the Vulnerability Category page.

This article includes content generously donated to OWASP by MicroFocus Logo.png

Last revision (mm/dd/yy): 09/23/2008

Vulnerabilities Table of Contents

ASDR Table of Contents


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