Summary
A high-severity SQL injection vulnerability in the Online Reviewer Management System allows attacker-controlled input in the assessment deletion functionality to alter database queries. If the vulnerable endpoint is reachable and the test_id value is not safely handled, a remote attacker may access, modify, or delete database information.
Affected context
The vulnerability occurs in SourceCodester Online Reviewer Management System 1.0, specifically in the assessment deletion functionality under reviewer_0/admins/assessments/examproper/exam-delete.php. It becomes risky when the remotely supplied test_id parameter is incorporated into a database query without adequate parameterization or validation.
Exploit preconditions
- Attack surface: Remotely reachable web application endpoint
- Required access: Access sufficient to submit requests to the assessment deletion functionality; authentication requirements may depend on deployment configuration
- Trigger point: Processing of the
test_idrequest parameter - Why exploitation is possible: The parameter may influence a database query without being safely separated from SQL syntax
Why this happens
The underlying flaw is improper separation of application data from SQL commands. When a request parameter is concatenated into a query or otherwise interpreted as query syntax, attacker-controlled input can change the intended database operation. This maps primarily to CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') and is also related to CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component.
Potential impact
- An attacker may read sensitive database records
- An attacker could alter or delete application data
- The application may disclose database structure or operational details
- Database credentials or stored secrets may be exposed
- Data integrity and reviewer-management workflows may be disrupted
General mitigation guidance
Mitigation generally focuses on ensuring that database operations treat request values strictly as data rather than executable query syntax.
Common defensive patterns include:
- Using parameterized queries or prepared statements for all database access
- Applying allowlist validation for identifier values such as numeric IDs
- Avoiding dynamic SQL construction from request parameters
- Enforcing authorization checks independently of input validation
- Limiting database accounts to the minimum permissions required by the application
- Using consistent error handling that does not reveal database details
How teams detect issues like this
Organizations commonly detect SQL injection risks through:
- Static analysis rules for string concatenation or interpolation in database queries
- Code review checks for unparameterized query construction
- Dynamic application testing of request parameters at authorized test boundaries
- Web application firewall policies that identify suspicious query-manipulation patterns
- Database monitoring for anomalous queries, unexpected deletion activity, or unusual access volumes
- Automated security review tools that flag unsafe data-to-query flows
