Summary
A SQL injection vulnerability in AWS CDK Redshift custom resource handlers allows construct property values to influence database statements without adequate query separation. If an attacker can control affected user names, comments, or passwords, they may execute SQL with Amazon Redshift superuser privileges, potentially changing access grants.
A SQL injection vulnerability in AWS CDK Redshift custom resource handlers allows construct property values to influence database statements without adequate query separation. If an attacker can control affected user names, comments, or passwords, they may execute SQL with Amazon Redshift superuser privileges, potentially changing access grants.
Affected context
The issue occurs in deployments using the AWS CDK @aws-cdk/aws-redshift-alpha module and its database-query custom resource handlers. Risk increases when untrusted or insufficiently validated values can flow into construct properties that are later incorporated into SQL statements, particularly for database users, comments, or passwords.
The issue occurs in deployments using the AWS CDK @aws-cdk/aws-redshift-alpha module and its database-query custom resource handlers. Risk increases when untrusted or insufficiently validated values can flow into construct properties that are later incorporated into SQL statements, particularly for database users, comments, or passwords.
Exploit preconditions
- Attack surface: AWS CDK Redshift custom resource database-query handlers
- Required access: Ability to influence relevant construct property values or the deployment inputs that populate them
- Trigger point: Processing of database user, comment, password, or related properties during custom resource execution
- Why exploitation is possible: User-controlled values are incorporated into SQL without reliable parameterization or context-aware escaping, allowing SQL syntax to be altered
- Attack surface: AWS CDK Redshift custom resource database-query handlers
- Required access: Ability to influence relevant construct property values or the deployment inputs that populate them
- Trigger point: Processing of database user, comment, password, or related properties during custom resource execution
- Why exploitation is possible: User-controlled values are incorporated into SQL without reliable parameterization or context-aware escaping, allowing SQL syntax to be altered
Why this happens
The underlying flaw is a failure to separate SQL code from data when constructing database statements from configurable values. This insecure pattern allows specially formed input to change the meaning of a query rather than remaining a literal value. It maps to CWE-89: Improper Neutralization of Special Elements used in an SQL Command (SQL Injection).
The underlying flaw is a failure to separate SQL code from data when constructing database statements from configurable values. This insecure pattern allows specially formed input to change the meaning of a query rather than remaining a literal value. It maps to CWE-89: Improper Neutralization of Special Elements used in an SQL Command (SQL Injection).
Potential impact
- An attacker may execute unauthorized SQL statements
- Database objects, users, or permissions could be modified
- Access may be granted broadly to cluster users or PUBLIC
- Sensitive data could be exposed, altered, or destroyed
- Redshift operations could be disrupted
- Superuser-level database actions could enable broader compromise of dependent workloads
- An attacker may execute unauthorized SQL statements
- Database objects, users, or permissions could be modified
- Access may be granted broadly to cluster users or PUBLIC
- Sensitive data could be exposed, altered, or destroyed
- Redshift operations could be disrupted
- Superuser-level database actions could enable broader compromise of dependent workloads
General mitigation guidance
Mitigation generally focuses on preserving a strict separation between SQL commands and input data.
Common defensive patterns include:
- Use parameterized queries or trusted database APIs instead of string concatenation
- Apply context-aware escaping only as a supplementary control, not as the primary defense
- Validate construct properties against restrictive allowlists and expected formats
- Minimize the database privileges available to custom resource handlers
- Avoid granting permissions to PUBLIC unless explicitly required
- Review existing table and schema grants for unintended broad access
- Treat deployment configuration and construct properties as untrusted until validated
- Add tests covering metacharacters, delimiters, and unexpected values in every SQL-bearing property
Mitigation generally focuses on preserving a strict separation between SQL commands and input data.
Common defensive patterns include:
- Use parameterized queries or trusted database APIs instead of string concatenation
- Apply context-aware escaping only as a supplementary control, not as the primary defense
- Validate construct properties against restrictive allowlists and expected formats
- Minimize the database privileges available to custom resource handlers
- Avoid granting permissions to PUBLIC unless explicitly required
- Review existing table and schema grants for unintended broad access
- Treat deployment configuration and construct properties as untrusted until validated
- Add tests covering metacharacters, delimiters, and unexpected values in every SQL-bearing property
How teams detect issues like this
Detection can combine source analysis, deployment review, and database auditing:
- Search for SQL statements assembled through string interpolation, concatenation, or formatting with construct properties
- Flag database APIs that receive dynamically built SQL rather than bound parameters
- Review custom resource handlers for user-controlled values reaching query execution
- Use code review checks requiring parameterization and explicit input validation
- Audit Redshift query history and permission changes for unexpected grants or administrative statements
- Enforce policy checks that identify broad grants, especially permissions assigned to PUBLIC
- Use automated static analysis or software composition review tools to identify SQL injection patterns
Detection can combine source analysis, deployment review, and database auditing:
- Search for SQL statements assembled through string interpolation, concatenation, or formatting with construct properties
- Flag database APIs that receive dynamically built SQL rather than bound parameters
- Review custom resource handlers for user-controlled values reaching query execution
- Use code review checks requiring parameterization and explicit input validation
- Audit Redshift query history and permission changes for unexpected grants or administrative statements
- Enforce policy checks that identify broad grants, especially permissions assigned to PUBLIC
- Use automated static analysis or software composition review tools to identify SQL injection patterns
Sources
| Source | Link |
|---|---|
| aws. | aws.amazon.com/ |
| github. | github.com/ |
| github. | github.com/ |
