Difference between revisions of "Assigning instead of comparing"

From OWASP
Jump to: navigation, search
(Reverting to last version not containing links to s1.shard.jp)
 
(18 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 
{{Template:SecureSoftware}}
 
{{Template:SecureSoftware}}
 +
{{Template:Vulnerability}}
 +
<br>
 +
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
  
==Overview==
+
[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
  
In many languages the compare statement is very close in appearance to the assignment statement and are often confused.
 
  
==Consequences ==
+
==Description==
 +
In many languages, the ''compare'' statement is very close in appearance to the ''assignment'' statement and are often confused.
 +
 
 +
This bug is generally a result of a typo and usually should cause obvious problems with program execution. If the comparison is in an ''if'' statement, the ''if ''statement will always return the value of the right-hand side variable.
 +
 
 +
'''Consequences'''
  
 
Unspecified.
 
Unspecified.
  
==Exposure period ==
+
'''Exposure period'''
  
 
* Pre-design through Build: The use of tools to detect this problem is recommended.
 
* Pre-design through Build: The use of tools to detect this problem is recommended.
Line 15: Line 22:
 
* Implementation: Many logic errors can lead to this condition. It can be exacerbated by lack, or misuse, of mitigating technologies.  
 
* Implementation: Many logic errors can lead to this condition. It can be exacerbated by lack, or misuse, of mitigating technologies.  
  
==PlatforM ==
+
'''Platform'''
  
 
* Languages: C, C++
 
* Languages: C, C++
Line 21: Line 28:
 
* Operating platforms: Any
 
* Operating platforms: Any
  
==Required resources ==
+
'''Required resources'''
  
 
Any
 
Any
  
==Severity ==
+
'''Severity'''
  
 
High
 
High
  
==Likelihood  of exploit ==
+
'''Likelihood  of exploit'''
  
 
Low
 
Low
  
==Avoidance and mitigation ==
 
  
* Pre-design: Through Build: Many IDEs and static analysis products will detect this problem.
+
==Risk Factors==
 +
TBD
  
* Implementation: Place constants on the left. If one attempts to assign a constant with a variable, the compiler will of course produce an error.
 
 
==Discussion ==
 
 
This bug is generally as a result of a typo and usually should cause obvious problems with program execution. If the comparison is in an ''if'' statement, the ''if ''statement will always return the value of the right-hand side variable.
 
 
==Examples ==
 
  
 +
==Examples==
 
In C/C++/Java:
 
In C/C++/Java:
  
Line 58: Line 59:
 
</pre>
 
</pre>
  
==Related problems ==
 
  
[[Comparing instead of assigning]]
+
==Related [[Attacks]]==
 +
TBD
 +
* [[Attack 1]]
 +
* [[Attack 2]]
  
 +
==Related [[Vulnerabilities]]==
 +
* [[Comparing instead of assigning]]
  
[[Category:Vulnerability]]
+
==Related [[Controls]]==
 +
TBD
 +
* [[Control 1]]
 +
* [[Control 2]]
 +
* Pre-design: Through Build: Many IDEs and static analysis products will detect this problem.
 +
* Implementation: Place constants on the left. If one attempts to assign a constant with a variable, the compiler will of course produce an error.
  
[[Category:General Logic Error Vulnerability]]
 
  
[[Category:OWASP_CLASP_Project]]
+
==Related [[Technical Impacts]]==
 +
TBD
 +
* [[Technical Impact 1]]
 +
* [[Technical Impact 2]]
  
 +
 +
==References==
 +
TBD
 +
[[Category:FIXME|need 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:Vulnerability]]
 +
[[Category:General Logic Error Vulnerability]]
 +
[[Category:OWASP_CLASP_Project]]
 
[[Category:Implementation]]
 
[[Category:Implementation]]
 +
[[Category:OWASP ASDR Project]]

Latest revision as of 07:50, 3 June 2009

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



Last revision (mm/dd/yy): 06/3/2009

Vulnerabilities Table of Contents


Description

In many languages, the compare statement is very close in appearance to the assignment statement and are often confused.

This bug is generally a result of a typo and usually should cause obvious problems with program execution. If the comparison is in an if statement, the if statement will always return the value of the right-hand side variable.

Consequences

Unspecified.

Exposure period

  • Pre-design through Build: The use of tools to detect this problem is recommended.
  • Implementation: Many logic errors can lead to this condition. It can be exacerbated by lack, or misuse, of mitigating technologies.

Platform

  • Languages: C, C++
  • Operating platforms: Any

Required resources

Any

Severity

High

Likelihood of exploit

Low


Risk Factors

TBD


Examples

In C/C++/Java:

void called(int foo){
        if (foo=1)  printf("foo\n");
}

int main(){
        called(2);
        return 0;
}


Related Attacks

TBD

Related Vulnerabilities

Related Controls

TBD

  • Control 1
  • Control 2
  • Pre-design: Through Build: Many IDEs and static analysis products will detect this problem.
  • Implementation: Place constants on the left. If one attempts to assign a constant with a variable, the compiler will of course produce an error.


Related Technical Impacts

TBD


References

TBD