CWE-602: Client-Side Enforcement of Server-Side Security
Description
The product is composed of a server that relies on the client to implement a mechanism that is intended to protect the server.
Submission Date :
May 7, 2007, midnight
Modification Date :
2023-06-29 00:00:00+00:00
Organization :
MITRE
Extended Description
When the server relies on protection mechanisms placed on the client side, an attacker can modify the client-side behavior to bypass the protection mechanisms, resulting in potentially unexpected interactions between the client and server. The consequences will vary, depending on what the mechanisms are trying to protect.
Example - 1
This example contains client-side code that checks if the user authenticated successfully before sending a command. The server-side code performs the authentication in one step, and executes the command in a separate step.
CLIENT-SIDE (client.pl)
// # username/pass is valid, go ahead and update the info!//
writeSocket($sock, "CHANGE-ADDRESS $username $address\n";
print "ERROR: Invalid Authentication!\n";$server = "server.example.com";$username = AskForUserName();$password = AskForPassword();$address = AskForAddress();$sock = OpenSocket($server, 1234);writeSocket($sock, "AUTH $username $password\n");$resp = readSocket($sock);if ($resp eq "success") {}else {}
SERVER-SIDE (server.pl):
// # does not close the socket on failure; assumes the//
// # user will try again//
($username, $pass) = split(/\s+/, $args, 2);$result = AuthenticateUser($username, $pass);writeSocket($sock, "$result\n");
$res = UpdateDatabaseRecord($username, "address", $args);writeSocket($sock, "SUCCESS\n");
writeSocket($sock, "FAILURE -- address is malformed\n");if (validateAddress($args)) {}else {}$sock = acceptSocket(1234);($cmd, $args) = ParseClientRequest($sock);if ($cmd eq "AUTH") {}elsif ($cmd eq "CHANGE-ADDRESS") {}
The server accepts 2 commands, "AUTH" which authenticates the user, and "CHANGE-ADDRESS" which updates the address field for the username. The client performs the authentication and only sends a CHANGE-ADDRESS for that user if the authentication succeeds. Because the client has already performed the authentication, the server assumes that the username in the CHANGE-ADDRESS is the same as the authenticated user. An attacker could modify the client by removing the code that sends the "AUTH" command and simply executing the CHANGE-ADDRESS.
Example - 2
In 2022, the OT:ICEFALL study examined products by 10 different Operational Technology (OT) vendors. The researchers reported 56 vulnerabilities and said that the products were "insecure by design" [REF-1283]. If exploited, these vulnerabilities often allowed adversaries to change how the products operated, ranging from denial of service to changing the code that the products executed. Since these products were often used in industries such as power, electrical, water, and others, there could even be safety implications. Multiple vendors used client-side authentication in their OT products.
Related Weaknesses
This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined to give an overview of the different insight to similar items that may exist at higher and lower levels of abstraction.
CWE-290: Authentication Bypass by Spoofing
CWE-300: Channel Accessible by Non-Endpoint
CWE-471: Modification of Assumed-Immutable Data (MAID)
CWE-565: Reliance on Cookies without Validation and Integrity Checking
CWE-603: Use of Client-Side Authentication
CWE-693: Protection Mechanism Failure
CWE-836: Use of Password Hash Instead of Password for Authentication
Visit http://cwe.mitre.org/ for more details.