CWE-807: Reliance on Untrusted Inputs in a Security Decision

Description:
The product uses a protection mechanism that relies on the existence or values of an input, but the input can be modified by an untrusted actor in a way that bypasses the protection mechanism.

Extended Description:
Developers may assume that inputs such as cookies, environment variables, and hidden form fields cannot be modified. However, an attacker could change these inputs using customized clients or other attacks. This change might not be detected. When security decisions such as authentication and authorization are made based on the values of these inputs, attackers can bypass the security of the software. 
             Without sufficient encryption, integrity checking, or other mechanism, any input that originates from an outsider cannot be trusted.

Affected languages: Not Language-Specific
Affected technologies: Not Technology-Specific, Web Based, Web Server
Parent weaknesses: CWE-693

Consequences:
  - Confidentiality: Bypass Protection Mechanism

Detection methods:
  - Manual Static Analysis: Since this weakness does not typically appear frequently within a single software package, manual white box techniques may be able to provide sufficient code coverage and reduction of false positives 
  - Automated Static Analysis - Binary or Bytecode: According to SOAR [REF-1479], the following detection techniques may be useful: 
                   
                      Cost effective for partial coverage: 
                         
             
  - Manual Static Analysis - Binary or Bytecode: According to SOAR [REF-1479], the following detection techniques may be useful: 
                   
                      Cost effective for partial coverage: 
                         
             
  - Dynamic Analysis with Automated Results Interpretation: According to SOAR [REF-1479], the following detection techniques may be useful: 
                   
                      Cost effective for partial coverage: 
                         
             

Mitigations:
  - [Architecture and Design] Store state information and sensitive data on the server side only. 
                   Ensure that the system definitively and unambiguously keeps track of its own state and user state and has rules defined for legitimate state transitions. Do not allow any application user to affect state directly
  - [Architecture and Design] Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. 
                   With a stateless protocol such as HTTP, use a framework that maintains the state for you. 
                   Examples include ASP.NET View
  - [Architecture and Design] For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. 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-s
  - [Operation] When using PHP, configure the application so that it does not use register_globals. During implementation, develop the application so that it does not rely on this feature, but be wary of implementing a register_globals emulation that is subject to weaknesses such as CWE-95, CWE-621, and similar iss

Demonstrative examples:
The following code excerpt reads a value from a browser cookie to determine the role of the user.

Cookie[] cookies = request.getCookies(); for (int i =0; i< cookies.length; i++) { Cookie c = cookies[i]; if (c.getName().equals("role")) { userRole = c.getValue(); } }

The following code could be for a medical records application. It performs authentication by checking if a cookie has been set.
The programmer expects that the AuthenticateUser() check will always be applied, and the "authenticated" cookie will only be set when authentication succeeds. The programmer even diligently specifies a 2-hour expiration for the cookie.
$auth = $_COOKIES['authenticated']; if (! $auth) { if (AuthenticateUser($_POST['user'], $_POST['password']) == "success") { // save the cookie to send out in future responses setcookie("authenticated", "1", time()+60*60*2); } else { ShowLoginScreen(); die("\n"); } } DisplayMedicalHistory($_POST['patient_ID']);

Real-world examples:
  - CVE-2009-1549: Attacker can bypass authentication by setting a cookie to a specific value.
  - CVE-2009-1619: Attacker can bypass authentication and gain admin privileges by setting an "admin" cookie to 1.
  - CVE-2009-0864: Content management system allows admin privileges by setting a "login" cookie to "OK."
  - CVE-2008-5784: e-dating application allows admin privileges by setting the admin cookie to 1.
  - CVE-2008-6291: Web-based email list manager allows attackers to gain admin privileges by setting a login cookie to "admin."