CWE-566: Authorization Bypass Through User-Controlled SQL Primary Key

Description

The product uses a database table that includes records that should not be accessible to an actor, but it executes a SQL statement with a primary key that can be controlled by that actor.

When a user can set a primary key to any value, then the user can modify the key to point to unauthorized records. Database access control errors occur when:

Potential Impact

Confidentiality, Integrity, Access Control

Read Application Data, Modify Application Data, Bypass Protection Mechanism

Demonstrative Examples

The following code uses a parameterized statement, which escapes metacharacters and prevents SQL injection vulnerabilities, to construct and execute a SQL query that searches for an invoice matching the specified identifier [1]. The identifier is selected from a list of all invoices associated with the current authenticated user.

Bad

...
		  conn = new SqlConnection(_ConnectionString);
		  conn.Open();
		  int16 id = System.Convert.ToInt16(invoiceID.Text);
		  SqlCommand query = new SqlCommand( "SELECT * FROM invoices WHERE id = @id", conn);
		  query.Parameters.AddWithValue("@id", id);
		  SqlDataReader objReader = objCommand.ExecuteReader();
		  ...

The problem is that the developer has not considered all of the possible values of id. Although the interface generates a list of invoice identifiers that belong to the current user, an attacker can bypass this interface to request any desired invoice. Because the code in this example does not check to ensure that the user has permission to access the requested invoice, it will display any invoice, even if it does not belong to the current user.

Mitigations & Prevention

Implementation

Assume all input is malicious. Use a standard input validation mechanism to validate all input for length, type, syntax, and business rules before accepting the data. Use an "accept known good" validation strategy.

Implementation

Use a parameterized query AND make sure that the accepted values conform to the business rules. Construct your SQL statement accordingly.

Detection Methods

Automated Static Analysis High — Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then sea

Taxonomy Mappings

Software Fault Patterns: SFP25 — Tainted input to variable

Frequently Asked Questions

What is CWE-566?

CWE-566 (Authorization Bypass Through User-Controlled SQL Primary Key) is a software weakness identified by MITRE's Common Weakness Enumeration. It is classified as a Variant-level weakness. The product uses a database table that includes records that should not be accessible to an actor, but it executes a SQL statement with a primary key that can be controlled by that actor.

How can CWE-566 be exploited?

Attackers can exploit CWE-566 (Authorization Bypass Through User-Controlled SQL Primary Key) to read application data, modify application data, bypass protection mechanism. This weakness is typically introduced during the Architecture and Design, Implementation phase of software development.

How do I prevent CWE-566?

Key mitigations include: Assume all input is malicious. Use a standard input validation mechanism to validate all input for length, type, syntax, and business rules before accepting the data. Use an "accept known good" valida

What is the severity of CWE-566?

CWE-566 is classified as a Variant-level weakness (Low-Medium abstraction). Its actual severity depends on the specific context and how the weakness manifests in your application.