Summary
CoreShop through version 1.5.5 contains an unauthenticated SQL injection vulnerability in the api/Good/GetGoodsPageList endpoint. An attacker may manipulate the unvalidated order parameter to influence database queries and use blind techniques to retrieve sensitive member and order information.
CoreShop through version 1.5.5 contains an unauthenticated SQL injection vulnerability in the api/Good/GetGoodsPageList endpoint. An attacker may manipulate the unvalidated order parameter to influence database queries and use blind techniques to retrieve sensitive member and order information.
Affected context
The issue occurs in CoreShop deployments where the goods page-list API accepts an order parameter and appends it to an ORDER BY clause without sufficiently restricting the allowed fields or expressions. Risk is increased when the endpoint is publicly reachable and the backing database contains member accounts, orders, or other sensitive application data.
The issue occurs in CoreShop deployments where the goods page-list API accepts an order parameter and appends it to an ORDER BY clause without sufficiently restricting the allowed fields or expressions. Risk is increased when the endpoint is publicly reachable and the backing database contains member accounts, orders, or other sensitive application data.
Exploit preconditions
- Attack surface: The publicly exposed
api/Good/GetGoodsPageListAPI endpoint - Required access: No authentication may be required when the endpoint is accessible anonymously
- Trigger point: Processing of the client-controlled
orderparameter - Why exploitation is possible: The parameter is incorporated into database query ordering without effective allowlisting or neutralization, potentially allowing query logic to be influenced and inferred through response or timing behavior
- Attack surface: The publicly exposed
api/Good/GetGoodsPageListAPI endpoint - Required access: No authentication may be required when the endpoint is accessible anonymously
- Trigger point: Processing of the client-controlled
orderparameter - Why exploitation is possible: The parameter is incorporated into database query ordering without effective allowlisting or neutralization, potentially allowing query logic to be influenced and inferred through response or timing behavior
Why this happens
The underlying defect is the use of unvalidated request data in SQL query construction. Treating the order parameter as a trusted SQL fragment allows input to affect an ORDER BY clause, which maps to CWE-89: Improper Neutralization of Special Elements used in an SQL Command, commonly known as SQL injection. Application-level field checks are insufficient when they do not constrain the complete expression to a fixed, approved set of identifiers and directions.
The underlying defect is the use of unvalidated request data in SQL query construction. Treating the order parameter as a trusted SQL fragment allows input to affect an ORDER BY clause, which maps to CWE-89: Improper Neutralization of Special Elements used in an SQL Command, commonly known as SQL injection. Application-level field checks are insufficient when they do not constrain the complete expression to a fixed, approved set of identifiers and directions.
Potential impact
- An attacker may retrieve sensitive member account information
- An attacker could disclose order and transaction-related records
- Database contents may be inferred through boolean-based or timing-based behavior
- Application availability could be affected by expensive or abusive queries
- Broader database compromise may occur if excessive database privileges are available
- An attacker may retrieve sensitive member account information
- An attacker could disclose order and transaction-related records
- Database contents may be inferred through boolean-based or timing-based behavior
- Application availability could be affected by expensive or abusive queries
- Broader database compromise may occur if excessive database privileges are available
General mitigation guidance
Mitigation generally focuses on reducing trust in query-shaping input and preventing request data from becoming executable SQL syntax.
Common defensive patterns include:
- Mapping client-provided sort fields and directions to a fixed server-side allowlist
- Rejecting unknown, compound, or expression-based ordering values
- Using framework query APIs that separate data values from SQL structure where supported
- Applying strict input validation before query construction
- Exposing only the minimum database privileges required by the application
- Limiting anonymous access to data endpoints where business requirements permit
- Avoiding detailed database errors and timing differences in API responses
Mitigation generally focuses on reducing trust in query-shaping input and preventing request data from becoming executable SQL syntax.
Common defensive patterns include:
- Mapping client-provided sort fields and directions to a fixed server-side allowlist
- Rejecting unknown, compound, or expression-based ordering values
- Using framework query APIs that separate data values from SQL structure where supported
- Applying strict input validation before query construction
- Exposing only the minimum database privileges required by the application
- Limiting anonymous access to data endpoints where business requirements permit
- Avoiding detailed database errors and timing differences in API responses
How teams detect issues like this
Detection can include static analysis for request parameters concatenated into SQL or query-builder fragments, especially around ORDER BY, filtering, and pagination logic. Code review should examine whether sort fields and directions are selected from server-side allowlists rather than passed through from clients. Runtime monitoring can look for unusual ordering values, repeated response-timing probes, database error patterns, and abnormal data-enumeration behavior. CI policy checks and automated application security testing may help identify unsafe query construction before deployment.
Detection can include static analysis for request parameters concatenated into SQL or query-builder fragments, especially around ORDER BY, filtering, and pagination logic. Code review should examine whether sort fields and directions are selected from server-side allowlists rather than passed through from clients. Runtime monitoring can look for unusual ordering values, repeated response-timing probes, database error patterns, and abnormal data-enumeration behavior. CI policy checks and automated application security testing may help identify unsafe query construction before deployment.
