Employee Management System 1.0 - 'admin_id' SQLi

Employee Management System 1.0 — 'admin_id' SQL Injection (CVE-2024-28595)

This article examines a SQL Injection vulnerability reported in Employee Management System v1.0 (CVE-2024-28595) that arises from unsafe handling of the admin_id parameter in update-admin.php. It explains the vulnerability class, potential impact, safe testing practices, detection methods, and practical remediation steps including secure code examples for PHP/MySQL applications.

Background and impact

SQL Injection (SQLi) occurs when user-supplied input is inserted into a SQL statement without proper validation or parameterization. Attackers can manipulate these inputs to alter queries, causing unauthorized data access, modification, bypass of authentication, or even execution of administrative actions on the database.

• Vulnerability: unsanitized admin_id parameter in update-admin.php leads to SQLi.
• Class: time-based blind SQL Injection was observed in reported testing, indicating the application executes attacker-supplied payloads within SQL logic.
• Potential impact: data disclosure (sensitive employee/admin records), privilege escalation, account takeover, or service disruption depending on database privileges.

Vulnerability details (high level)

In the vulnerable application, the admin_id value taken from a GET request is concatenated directly into a SQL query used to select or update administrator records. If the application does not use parameterized queries or otherwise validate and sanitize the input, an attacker can inject SQL syntax to change the intended query logic.

Time-based blind SQLi (as reported) is a technique attackers use to confirm and extract information when direct error messages or query results are not returned. It uses database functions that delay execution (sleep) to infer boolean conditions. This behavior confirms exploitable injection but should only be investigated in controlled environments.

Safe testing and responsible handling

• Only test systems you own or have explicit permission to assess (authorized penetration testing). Unauthorized testing or exploitation is illegal and unethical.
• Use non-destructive reconnaissance techniques and limit automated scanning to avoid service impacts.
• If you discover a vulnerability in a third-party product, follow responsible disclosure guidelines: report to the vendor, provide reproduction steps privately, and coordinate public disclosure.

Example of a vulnerable PHP pattern

<?php
// Vulnerable example: unsafe concatenation of user input into SQL
$admin_id = $_GET['admin_id']; // unsanitized input from a GET parameter
$sql = "SELECT * FROM admins WHERE id = '$admin_id'";
$result = mysqli_query($conn, $sql);
// ... process $result ...
?>

Explanation: This simplified example constructs a SQL string by directly inserting the GET parameter into the query. If an attacker controls admin_id and includes SQL syntax, they can manipulate the query. This pattern is the root cause of many SQLi vulnerabilities.

Secure fixes — parameterized queries and input controls

The recommended remediation is to use parameterized queries (prepared statements) and apply input validation (type casting or allowlists). Below are secure examples for PHP using MySQLi and PDO.

Secure MySQLi prepared statement (procedural)

<?php
// Secure example: use prepared statements and explicit type casting
$admin_id = isset($_GET['admin_id']) ? (int)$_GET['admin_id'] : 0; // cast to integer as an additional safeguard

$stmt = mysqli_prepare($conn, "SELECT id, username, email FROM admins WHERE id = ?");
mysqli_stmt_bind_param($stmt, "i", $admin_id); // "i" denotes integer
mysqli_stmt_execute($stmt);
$result = mysqli_stmt_get_result($stmt);
// ... process $result ...
mysqli_stmt_close($stmt);
?>

Explanation: This code casts the input to an integer to prevent non-numeric injection, prepares the SQL statement with a placeholder (?), binds the typed parameter, and executes the statement. The database treats the bound value strictly as data, not as SQL code, mitigating SQLi.

Secure PDO prepared statement (object-oriented)

<?php
// PDO example with exceptions and parameter binding
$admin_id = isset($_GET['admin_id']) ? (int)$_GET['admin_id'] : 0;

try {
    $pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
    $stmt = $pdo->prepare("SELECT id, username, email FROM admins WHERE id = :id");
    $stmt->execute([':id' => $admin_id]);
    $row = $stmt->fetch(PDO::FETCH_ASSOC);
    // ... process $row ...
} catch (PDOException $e) {
    // Log securely and return a generic error to the client
}
?>

Explanation: PDO prepared statements separate SQL logic from data by using named placeholders. The execute() call binds the provided parameter safely. Proper error handling prevents leakage of sensitive internals.

Additional mitigation strategies

• Least privilege: ensure the database user has minimum required privileges (avoid granting DROP/CREATE to the web-app user).
• Web Application Firewall (WAF): use carefully tuned WAF rules to detect and block common injection patterns.
• Input allowlists: where possible, accept only expected formats (e.g., numeric IDs) and reject everything else.
• Logging and monitoring: detect anomalous query patterns, slow queries, or repeated parameterized failures.
• Use ORMs: modern ORMs often encourage parameterized queries by default, though they are not a substitute for secure coding practices.
• Patch and update: use the latest vendor updates and apply security patches promptly.

Detection and testing recommendations

To safely detect SQLi in a controlled environment:

• Use application security scanners in a lab environment designed for testing (OWASP Juice Shop, DVWA, or dedicated test copies of the target application).
• Prefer non-intrusive checks first (static code review for direct concatenation of inputs into queries, automated SAST tools).
• When performing dynamic tests, use low-impact, non-destructive payloads that confirm behavior without modifying data. Do not perform exploitation on production systems without authorization.

Incident response and remediation steps

• Immediately restrict access if active exploitation is suspected; consider taking affected endpoints offline or applying emergency WAF rules.
• Identify the vulnerable code paths and deploy the prepared-statement fixes across all affected endpoints.
• Rotate database credentials used by the web application if there is any suspicion of compromise.
• Audit database contents for unauthorized access or modifications; restore from known-good backups if integrity is compromised.
• Notify stakeholders and follow legal/regulatory disclosure procedures where applicable.

Reference information

Attribute	Details
Product	Employee Management System v1.0
CVE	CVE-2024-28595
Vendor / Source	SourceCodester (example project distribution)

Conclusion

SQL Injection remains a critical vulnerability class because of its high impact and prevalence in codebases that interpolate user input into SQL. Fixing the admin_id flaw requires replacing string concatenation with parameterized queries, validating and casting inputs where appropriate, and enforcing operational mitigations like least privilege and monitoring. Apply fixes across the codebase, test in controlled environments, and follow responsible disclosure and incident response best practices.