Summary
PHPOK versions in the affected range contain an SQL injection vulnerability in the project API's sort parameter. An unauthenticated attacker may manipulate query ordering logic and cause database errors that disclose sensitive information when the parameter is incorporated into SQL without adequate validation.
PHPOK versions in the affected range contain an SQL injection vulnerability in the project API's sort parameter. An unauthenticated attacker may manipulate query ordering logic and cause database errors that disclose sensitive information when the parameter is incorporated into SQL without adequate validation.
Affected context
The vulnerability occurs in the PHPOK project API endpoint when the sort GET parameter is accepted from unauthenticated requests and used to construct an ORDER BY clause. Deployments are at greater risk when this endpoint is internet-accessible, query parameters are not constrained to approved sort fields, and database errors are returned to clients.
The vulnerability occurs in the PHPOK project API endpoint when the sort GET parameter is accepted from unauthenticated requests and used to construct an ORDER BY clause. Deployments are at greater risk when this endpoint is internet-accessible, query parameters are not constrained to approved sort fields, and database errors are returned to clients.
Exploit preconditions
- Attack surface: The project API endpoint at
/api.php?c=project&f=index - Required access: No authentication may be required when the endpoint is publicly reachable
- Trigger point: Processing of the user-controlled
sortparameter - Why exploitation is possible: The parameter may influence SQL query structure without strict allowlisting or safe query construction, enabling database expression manipulation and error-based information disclosure
- Attack surface: The project API endpoint at
/api.php?c=project&f=index - Required access: No authentication may be required when the endpoint is publicly reachable
- Trigger point: Processing of the user-controlled
sortparameter - Why exploitation is possible: The parameter may influence SQL query structure without strict allowlisting or safe query construction, enabling database expression manipulation and error-based information disclosure
Why this happens
The underlying bug is insufficient separation between untrusted request data and SQL query structure. When a user-controlled sorting value is concatenated into an ORDER BY clause or otherwise passed to a database query without selecting from a fixed set of permitted fields, an attacker can alter query behavior. This behavior maps to CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection').
The underlying bug is insufficient separation between untrusted request data and SQL query structure. When a user-controlled sorting value is concatenated into an ORDER BY clause or otherwise passed to a database query without selecting from a fixed set of permitted fields, an attacker can alter query behavior. This behavior maps to CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection').
Potential impact
- An attacker may retrieve sensitive database information through query errors or other observable responses.
- Database contents, schema details, or application metadata could be disclosed.
- Crafted requests could degrade application availability or affect query performance.
- If database permissions are excessive, exploitation could enable broader data modification or access.
- An attacker may retrieve sensitive database information through query errors or other observable responses.
- Database contents, schema details, or application metadata could be disclosed.
- Crafted requests could degrade application availability or affect query performance.
- If database permissions are excessive, exploitation could enable broader data modification or access.
General mitigation guidance
Mitigation generally focuses on ensuring that request parameters cannot control SQL syntax.
Common defensive patterns include:
- Map sorting requests to a fixed allowlist of server-defined column names and directions.
- Avoid concatenating user input into SQL statements, using parameterized queries where supported.
- Validate types, lengths, and permitted values before database access.
- Return generic application errors rather than database diagnostics or stack traces.
- Apply least-privilege permissions to the application database account.
- Place administrative or sensitive API functionality behind appropriate authentication and network controls.
- Treat client-controlled sorting and filtering values as untrusted even when they appear non-sensitive.
Mitigation generally focuses on ensuring that request parameters cannot control SQL syntax.
Common defensive patterns include:
- Map sorting requests to a fixed allowlist of server-defined column names and directions.
- Avoid concatenating user input into SQL statements, using parameterized queries where supported.
- Validate types, lengths, and permitted values before database access.
- Return generic application errors rather than database diagnostics or stack traces.
- Apply least-privilege permissions to the application database account.
- Place administrative or sensitive API functionality behind appropriate authentication and network controls.
- Treat client-controlled sorting and filtering values as untrusted even when they appear non-sensitive.
How teams detect issues like this
High-level detection can include:
- Static analysis for string concatenation or interpolation of request parameters into SQL query construction.
- Code review checks for dynamic
ORDER BY, filtering, and pagination clauses that lack allowlists. - Runtime monitoring for repeated malformed query parameters, database error responses, and unusual requests to public API endpoints.
- Web application firewall or API gateway policies that constrain sorting parameters to documented values.
- Automated security testing that verifies invalid sort values are rejected without exposing database errors.
- Database audit logging to identify unexpected query patterns or access to sensitive tables.
High-level detection can include:
- Static analysis for string concatenation or interpolation of request parameters into SQL query construction.
- Code review checks for dynamic
ORDER BY, filtering, and pagination clauses that lack allowlists. - Runtime monitoring for repeated malformed query parameters, database error responses, and unusual requests to public API endpoints.
- Web application firewall or API gateway policies that constrain sorting parameters to documented values.
- Automated security testing that verifies invalid sort values are rejected without exposing database errors.
- Database audit logging to identify unexpected query patterns or access to sensitive tables.
