Faculty Evaluation System v1.0 - SQL Injection

Faculty Evaluation System v1.0: A Deep Dive into SQL Injection Vulnerabilities

Security flaws in web applications often stem from poor input validation and improper handling of user-supplied data. One such critical vulnerability exists in the Faculty Evaluation System v1.0, a PHP-based application available on SourceCodester. This system, designed for academic institutions to manage faculty evaluations, contains two exploitable SQL Injection (SQLi) vulnerabilities in key components: edit_evaluation and view_faculty.php. These flaws allow attackers to bypass authentication, extract sensitive data, or even manipulate database records — all without proper authorization.

Understanding SQL Injection in Web Applications

SQL Injection occurs when an application fails to sanitize user input before using it in a database query. Malicious input can alter the intended SQL command, enabling attackers to execute arbitrary queries. In the context of the Faculty Evaluation System, this vulnerability arises due to direct concatenation of $_GET['id'] into SQL statements without proper escaping or parameterization.

$qry = $conn->query("SELECT * FROM ratings where id = ".$_GET['id'])->fetch_array();

This line in edit_evaluation is a textbook example of unsafe SQL query construction. The $_GET['id'] parameter is directly inserted into the query string. An attacker can exploit this by submitting crafted input such as 1 OR 1=1, which would result in a query like:

SELECT * FROM ratings where id = 1 OR 1=1

Since 1=1 is always true, the query returns all records from the ratings table — exposing sensitive evaluation data, potentially including student feedback, instructor scores, or personal identifiers.

Exploitation Scenario: View Faculty Data

The second vulnerability lies in view_faculty.php, where a similar unsafe query is used:

$qry = $conn->query("SELECT *,concat(firstname,' ',lastname) as name FROM faculty_list where id = ".$_GET['id'])->fetch_array();

Here, the id parameter is again directly injected into the query. An attacker can use payloads like 1 UNION SELECT username,password FROM users to extract credentials from a different table, assuming the database schema allows such unions.

For instance, if the database contains a users table with credentials, the following payload would be effective:

1 UNION SELECT username, password FROM users

Resulting in a query that returns faculty data along with user credentials — a catastrophic breach in a system intended for educational management.

Exploitation with SQLMap: Automated Detection and Exploitation

Security researchers and penetration testers can leverage tools like sqlmap to automate the detection and exploitation of SQL Injection vulnerabilities. The provided exploit uses a real-world test case:

sqlmap -r test.txt --threads 1 --dbms=mysql --fingerprint

By using a captured HTTP request (saved in test.txt), sqlmap performs automated fingerprinting to identify the backend database. In this case, it confirms the system uses MySQL (version >= 5.7), with additional evidence pointing to MariaDB as a possible variant.

During the fingerprinting process, sqlmap executes comment injection tests (e.g., /* */), which are known to be effective on MySQL and MariaDB. The tool also performs fork fingerprinting, which helps distinguish between MySQL and its derivatives.

Impact and Risk Assessment

Severity	CVSS Score	Impact
High	8.1 (CVSS v3.1)	Unauthorized access to sensitive data, data manipulation, potential full database compromise

The vulnerability allows attackers to:

• Extract all faculty and evaluation records via OR 1=1 payloads.
• Retrieve user credentials through UNION SELECT injection.
• Modify or delete records if the application allows write operations via injection.
• Perform blind SQL injection if the response is not directly visible.

Fixing the Vulnerability: Best Practices

These vulnerabilities can be easily mitigated with modern secure coding practices. The key solution is to use prepared statements instead of direct string concatenation.

$stmt = $conn->prepare("SELECT * FROM ratings WHERE id = ?");
$stmt->bind_param("i", $_GET['id']);
$stmt->execute();
$result = $stmt->get_result()->fetch_array();

This corrected code uses a parameterized query, where ? acts as a placeholder for the id value. The bind_param function ensures the input is treated as a numeric value and never interpreted as part of the SQL syntax.

Similarly, for view_faculty.php:

$stmt = $conn->prepare("SELECT *, concat(firstname, ' ', lastname) as name FROM faculty_list WHERE id = ?");
$stmt->bind_param("i", $_GET['id']);
$stmt->execute();
$result = $stmt->get_result()->fetch_array();

By adopting prepared statements, the application becomes immune to SQL Injection attacks, regardless of input type.

Additional Security Recommendations

Beyond SQL Injection, the Faculty Evaluation System should also implement:

• Input validation to ensure id is numeric and within expected range.
• Authentication checks before accessing sensitive data.
• Role-based access control to limit access to faculty records based on user roles.
• Logging and monitoring of suspicious queries to detect potential attacks.

These measures collectively enhance the system's resilience against both known and emerging threats.

Conclusion

The Faculty Evaluation System v1.0 exemplifies how simple coding mistakes can lead to severe security breaches. While the application may serve a legitimate educational purpose, its exposure to SQL Injection renders it vulnerable to exploitation by attackers with minimal technical expertise. Security professionals must prioritize input sanitization, use prepared statements, and conduct regular penetration testing to ensure such vulnerabilities are not introduced in production systems.