Summary
A remotely reachable SQL injection vulnerability in SourceCodester Online Reviewer Management System 1.0 affects the assessment question-viewing function. An attacker may manipulate the ID parameter to alter database queries, potentially exposing or changing application data when the endpoint is accessible.
Affected context
The issue occurs in the assessment management area at
/reviewer_0/admins/assessments/examproper/questions-view.php. It becomes risky when the endpoint processes the ID parameter without adequately separating user-controlled input from SQL query structure. Exposure depends on the application's deployment, authentication controls, and database account privileges.
Exploit preconditions
- Attack surface: The remotely accessible assessment question-viewing endpoint
- Required access: Network access to the application; authentication requirements depend on deployment controls
- Trigger point: Processing of the
IDrequest parameter - Why exploitation is possible: User-controlled input may reach database query construction without sufficient parameterization or validation
- Disclosure status: The vulnerability has reportedly been publicly disclosed, increasing the importance of monitoring and defensive controls
Why this happens
The underlying bug is an injection flaw in which externally supplied input is incorporated into a database query as syntax rather than being treated strictly as data. This behavior maps to CWE-89: Improper Neutralization of Special Elements used in an SQL Command (SQL Injection). The related CWE-74 classification reflects the broader failure to neutralize special elements in an interpreted command or query context.
Potential impact
- An attacker may retrieve unauthorized application or user data
- Database records could be modified, deleted, or corrupted
- Authentication or authorization data may be exposed or affected
- Application behavior could be disrupted
- Impact could expand if the database account has excessive privileges
General mitigation guidance
Mitigation generally focuses on ensuring that request data cannot become executable SQL syntax.
Common defensive patterns include:
- Use parameterized queries or prepared statements for all database operations
- Apply allowlist validation for identifiers such as numeric record IDs
- Avoid constructing SQL statements through string concatenation
- Enforce least privilege for the application's database account
- Return generic database errors without exposing query details
- Add authorization checks so users can access only permitted assessment records
- Use secure-by-default data-access abstractions and centralized query handling
How teams detect issues like this
Organizations can look for this class of weakness through:
- Static analysis rules identifying SQL string concatenation with request parameters
- Code review checks for direct use of
GET,POST, or route parameters in database queries - Dynamic application testing that monitors input handling and database error behavior
- Web-application firewall or API policy rules for suspicious query-manipulation patterns
- Database audit logging for unusual read, update, or deletion activity
- Automated security review tools that flag missing parameterization and weak input validation
