|
|
|
|
CWE-602 Individual Dictionary Definition (Draft 9)
Weakness ID
| Status: Draft 602 (Weakness Base) | | Description | Summary The client can be modified by an attacker in a way that bypasses protection mechanisms that are not
common to both the client and server. | | Weakness Ordinality | Primary (Weakness exists independent of other weaknesses) | | Enabling Factors for Exploitation | Consider a product that consists of two or more processes or nodes
that must interact closely, such as a client/server model. If the product uses protection schemes
in the client in order to defend from attacks against the server, and the server does not use the
same schemes, then an attacker could modify the client in a way that bypasses those schemes. This
is a fundamental design flaw that is primary to many weaknesses. | | Potential Mitigations | Protection schemes must be implemented on the server side; no interactions or inputs
from the client can be assumed to be safe. Some protection schemes can still be duplicated in
the client such as input validation, because they are frequently useful for general
error-checking. If some degree of trust is required between the two entities, then use integrity
checking and strong authentication to ensure that the inputs are coming from a trusted source.
Design the product so that this trust is managed in a centralized fashion, especially if there
are complex or numerous communication channels, in order to reduce the risks that the
implementor will mistakenly omit a check in a single code path. | Demonstrative
Examples | $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") {
# username/pass is valid, go ahead and update the info!
writeSocket($sock, "CHANGE-ADDRESS $username $address\n";
}
else {
print "ERROR: Invalid Authentication!\n";
} SERVER-SIDE (server.pl): $sock = acceptSocket(1234);
($cmd, $args) = ParseClientRequest($sock);
if ($cmd eq "AUTH") {
($username, $pass) = split(/\s+/, $args, 2);
$ex = AuthenticateUser($username, $pass);
writeSocket($sock, "$ex\n");
}
elsif ($cmd eq "CHANGE-ADDRESS") {
if (validateAddress($args)) {
$res = UpdateDatabaseRecord($username, "address", $args);
writeSocket($sock, "SUCCESS\n");
}
else {
writeSocket($sock, "FAILURE -- address is malformed\n");
}
} 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 commenting out the code that sends the "AUTH" command and
simply executing the CHANGE-ADDRESS. | | Observed Examples | | Reference | Description |
|---|
| CVE-2006-6994 | ASP program allows upload of .asp files by bypassing client-side checks. | | CVE-2007-0163, CVE-2007-0164 | steganography products embed password information in the carrier file, which can be
extracted from a modified client. | | CVE-2007-0100 | client allows server to modify client's configuration and overwrite arbitrary
files. |
| | Context Notes | "server-side enforcement of client-side security" is conceptually likely to occur, but
some architectures might have these strong dependencies as part of legitimate behavior, such as
thin clients. This is a design error, not implementation. | | Relationships | | | Applicable Platforms | All |
|
- Weakness
- Base
- Variant
- Class
- Chain
- Composite
- Category
- View
- Deprecated
