CWE-602: Client-Side Enforcement of Server-Side Security

How it's found

Client-Side Enforcement of Server-Side Security describes a general pattern rather than a single fixed bug. Testers use a mix of static analysis and manual code review to find where a target's code matches this pattern, then confirm exploitability by hand.

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.

Vulnerable vs. safe

# 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") {}

# 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 {}

Consequences

• Bypass Protection Mechanism, DoS: Crash, Exit, or Restart: Client-side validation checks can be easily bypassed, allowing malformed or unexpected input to pass into the application, potentially as trusted data. This may lead to unexpected states, behaviors and possibly a resulting crash.
• Bypass Protection Mechanism, Gain Privileges or Assume Identity: Client-side checks for authentication can be easily bypassed, allowing clients to escalate their access levels and perform unintended actions.

Mitigations

• Architecture and Design: For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server. Even though client-side checks provide minimal benefits with respect to server-side security, they are still useful. First, they can support intrusion detection. If the server receives input that should have been rejected by the client, then it may be an indication of an attack. Second, client-side error-checking can provide helpful feedback to the user about the expectations for valid input. Third, there may be a reduction in server-side processing time for accidental input errors, although this is typically a small savings.
• Architecture and Design: 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 implementer will mistakenly omit a check in a single code path.

Where this fits in a TurboPentest engagement

This weakness is not covered by the automated black-box pentest. IntegSec pentesters cover it in a manual engagement.

Frequently asked questions

Related CWEs

• Pillar weakness
  CWE-693: Protection Mechanism Failure
• Base weakness
  CWE-290: Authentication Bypass by Spoofing
• Class weakness
  CWE-300: Channel Accessible by Non-Endpoint
• Class weakness
  CWE-20: Improper Input Validation
• Class weakness
  CWE-77: Command Injection
• Base weakness
  CWE-79: Cross-site Scripting