|
Status: Draft Weakness ID: 687 (Weakness Variant)Description Summary The software calls a function, procedure, or routine, but the caller specifies an argument that contains the wrong value, leading to resultant weaknesses. Weakness Ordinalities Primary (where the weakness exists independent of other weaknesses) Detection Factors This might require an understanding of intended program behavior or design to determine whether the value is incorrect. Potential Mitigations Use the function, procedure, routine as specified. Demonstrative Examples This Perl code intends to record whether a user authenticated successfully or not, and to exit if the user fails to authenticate. However, when it calls ReportAuth(), the third argument is specified as 0 instead of 1, so it does not exit. Perl Example: sub ReportAuth { my ($username, $result, $fatal) = @_; PrintLog("auth: username=%s, result=%d", $username, $result); if (($result ne "success") && $fatal) { die "Failed!\n"; } } sub PrivilegedFunc { my $result = CheckAuth($username); ReportAuth($username, $result, 0); DoReallyImportantStuff(); }
Other Notes When primary, this weakness is most likely to occur in rarely-tested code, since the wrong value can change the semantic meaning of the program's execution and lead to obviously-incorrect behavior. It can also be resultant from issues in which the program assigns the wrong value to a variable, and that variable is later used in a function call. In that sense, this issue could be argued as having chaining relationships with many implementation errors in CWE. Relationships
Taxonomy Mappings
Time of Introduction ImplementationContent History Modifications Eric Dalci. Cigital. 2008-07-01. (External) updated Potential_Mitigations CWE Content Team. MITRE. 2008-09-08. (Internal) updated Detection_Factors, Relationships, Other_Notes, Weakness_Ordinalities CWE Content Team. MITRE. 2008-11-24. (Internal) updated Relationships, Taxonomy_Mappings |
|
|
|||