The product calls a function, procedure, or routine with arguments that are not correctly specified, leading to always-incorrect behavior and resultant weaknesses.
There are multiple ways in which this weakness can be introduced, including: the wrong variable or reference; an incorrect number of arguments; incorrect order of arguments; wrong type of arguments; or wrong value.
Threat Mapped score: 0.0
Industry: Finiancial
Threat priority: Unclassified
CVE: CVE-2006-7049
The method calls the functions with the wrong argument order, which allows remote attackers to bypass intended access restrictions.
N/A
N/A
| Phase | Note |
|---|---|
| Implementation | N/A |
Intro: The following PHP method authenticates a user given a username/password combination but is called with the parameters in reverse order.
function authenticate($username, $password) { // authenticate user ... } authenticate($_POST['password'], $_POST['username']);Intro: 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.
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(); }Intro: In the following Java snippet, the accessGranted() method is accidentally called with the static ADMIN_ROLES array rather than the user roles.
private static final String[] ADMIN_ROLES = ...; public boolean void accessGranted(String resource, String user) { String[] userRoles = getUserRoles(user); return accessGranted(resource, ADMIN_ROLES); } private boolean void accessGranted(String resource, String[] userRoles) { // grant or deny access based on user roles ... }